EDITAR: Si se encuentra con este problema, agradeceríamos su ayuda en la resolución de problemas. Estoy actualizando este comentario para mejorar la visibilidad de los pasos de solución de problemas.

Solución de problemas

El primer paso para solucionar este problema es determinar si el problema está relacionado con las credenciales o con la CLI. Para probar esto, intente usar estas credenciales en otros SDK de AWS (javascript, ruby, java, etc.). Para ayudar con esto, he creado un script de prueba que usa el AWS SDK para python y javascript que está disponible aquí: https://github.com/jamesls/aws-creds-test . Después de la clonación, simplemente ejecute make install , make test . Le solicitará las credenciales (similar a la CLI) y realizará una llamada API a sts.GetCallerIdentity .

/tmp $ mkdir /tmp/repro-cli-602
/tmp $ cd /tmp/repro-cli-602/
/tmp/repro-cli-602 $ git clone git://github.com/jamesls/aws-creds-test
Cloning into 'aws-creds-test'...
...
/tmp/repro-cli-602 $ cd aws-creds-test/
/tmp/repro-cli-602/aws-creds-test (master u=) $ make install
npm install
[email protected] /private/tmp/repro-cli-602/aws-creds-test
├─┬ [email protected]
...
pip install -r requirements.txt
Requirement already satisfied: botocore<2.0.0,>=1.5.0 in /usr/local/lib/python2.7/site-packages (from -r requirements.txt (line 1))
...



/tmp/repro-cli-602/aws-creds-test (master u=) $ make test
./test-creds.sh
Testing python...
Access Key:
Secret Access Key:
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20

SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Successfuly made an AWS request with the provided credentials.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20


SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Sucessfully made an AWS request with the provided credentials.

Para las personas que se encuentran con este problema, ejecuten el script de prueba y compartan el resultado.

Esto debería darnos una mejor idea de dónde está ocurriendo este problema:

• Si el script anterior pasa tanto para python como para javascript, pero falla al usar la CLI, es probable que se deba a un problema de CLI.
• Si el script falla para python pero pasa para javascript, es probable que haya un problema con botocore (que usa la CLI).
• Si el script anterior falla tanto para python como para javascript, es probable que haya un problema con las credenciales reales.

Gracias de antemano a cualquier persona que pueda ayudarnos a solucionar este problema. Avísame si tienes alguna pregunta.

Así es como esto luce:

thomas<strong i="6">@iMac</strong>:~ $ echo $AWS_ACCESS_KEY_ID
AKIAXXXXXXXXXXXXXXXX
thomas<strong i="7">@iMac</strong>:~ $ echo $AWS_SECRET_ACCESS_KEY
abcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa+0
thomas<strong i="8">@iMac</strong>:~ $ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
              env    AWS_ACCESS_KEY_ID
              env    AWS_SECRET_ACCESS_KEY
    region                eu-west-1              env    AWS_DEFAULT_REGION

¿Alguna actualización sobre este tema? También me encuentro con este error y mi archivo de credenciales no ha cambiado.

Tengo un problema similar. El complemento Jenkins s3 puede colocar un objeto con mis credenciales, pero aws-cli me da los siguientes errores.

aws s3 cp s3://my-bucket/folder/test.txt test.txt
A client error (Forbidden) occurred when calling the HeadObject operation: Forbidden Completed 1 part(s) with ... file(s) remaining

aws s3api get-object --bucket my-bucket --key folder/test.txt test.txt
A client error (SignatureDoesNotMatch) occurred when calling the GetObject operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

Me encuentro con el mismo problema. Si invento un secreto, me da un error diferente (AuthFailure).

[[email protected]]]$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************AMKA              env    AWS_ACCESS_KEY_ID
secret_key     ****************jPU2              env    AWS_SECRET_ACCESS_KEY
    region                us-west-2              env    AWS_DEFAULT_REGION

Esto me está deteniendo por completo. Puedo hacer algunas cosas con las utilidades ec2-blah-stuff especificando certificados x509, pero la ayuda dice que está obsoleto, por lo que no quiero depender de él. Cualquier ayuda para la resolución de problemas o lo que sea realmente sería muy apreciada.

El primer paso sería asegurarse de que sus claves de acceso / secretas sean realmente válidas. Algunas cosas para probar:

• ¿Funcionan estas mismas credenciales de acceso / clave secreta con otras herramientas? (¿El SDK de java / javascript / ruby ​​/ python?)
• ¿Otros comandos además de "aws s3" funcionan para usted? ¿Sigue generando errores de autenticación "las instancias de descripción de aws ec2"?

No funcionan con otras herramientas (ec2-describe-instance, por ejemplo).

Creo que tengo los derechos adecuados ya que el uso de certificados funciona. Para asegurarme de que no sea una estación de trabajo, construí una instancia de Amazon Linux y estoy usando la versión awscli que viene con ella, pero obteniendo el mismo mensaje.

También es un problema para mí. Lo estoy usando en un contenedor Docker, construido con el mismo Dockerfile.
Funciona bien cuando se construye en un EC2, pero no funciona cuando se construye localmente en una caja vagabunda de Coreos.

Parece que el problema está en las credenciales. Lo he comprobado dos veces y no puedo reproducir este problema. Verifique las credenciales en la página de credenciales de seguridad . Si alguien puede proporcionar un conjunto exacto de pasos que demuestren el problema, me complacerá echar otro vistazo.

Me acababa de pasar esto y fue el resultado de que el tiempo de mi sistema se retrasó demasiado a pesar de que no informó eso. Ejecuté ntpdate contra pool.ntp.org y me solucionó este problema.

Si recibe este error cuando se configuran cred usando la variable env, intente sudo

Si está en una máquina virtual, asegúrese de que la hora del sistema operativo host coincida con la hora del sistema operativo invitado. Si este no es el caso, se encontrará con el error que describió.

Se produce un error muy similar para mí con buenas credenciales, mientras enumero un depósito que tiene un _lote_ de claves. Aquí está el error:

A client error (SignatureDoesNotMatch) occurred when calling the ListObjects operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

Aquí está mi salida de aws configure list

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************4UNA shared-credentials-file
secret_key     ****************MNOG shared-credentials-file
    region                <not set>             None    None

Tenga en cuenta que estas credenciales funcionan bien con otras invocaciones aws y, de hecho, esta operación list ejecuta durante mucho tiempo (más de una hora) antes de rescatar con este error. Tengo un archivo con más de 82,000 líneas de salida del comando que finalmente falló.

He tenido este problema, y ​​si solo duermo mi guión por un segundo y lo intento de nuevo, se procesa. Es casi como si se acelerara y devolviera el error incorrecto o algo así.

También puedo informar de este problema. Al intentar cargar un archivo de 11 GB usando aws cp foo s3: // mybucket / foo / bar obtengo varios errores como:

A client error (SignatureDoesNotMatch) occurred when calling the UploadPart operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

y

Max retries exceeded with url: /***REDACTED***?partNumber=196&uploadId=B2viwGFF4Lmq5itbs8ipqwBExx0BWGRm3gkG_D5EYTiU8uEO_tmUT.d.i7BcgPnP5npZa.OW7yMfJ3ZhhLJD61zP7EVv.5.ZftCJQbKNdkEBeijGBqWlrxz4vMx3B05Q (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known)

He comprobado que la hora de mi sistema es correcta. También noté una lentitud considerable (en el nivel de tiempo de espera de las solicitudes http) en el mismo sistema durante la carga, por lo que este es un problema de aceleración que suena razonable. También funciona bien para cargar archivos pequeños con las mismas credenciales y usando la consola web desde la misma máquina, por lo que parece ser un problema de aws-cli.

Esto me sucedió también con aws-cli 1.5.5, la actualización de aws-cli a 1.6.2 lo resolvió.

Me pasa con 1.6.2

Esto me pasó hoy. Esto es nuevo para mi. He estado usando awl-cli durante unos meses sin problema y sin cambios en las credenciales AFAIK.

$ aws configure --profile ye list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                       ye           manual    --profile
access_key     ****************ERMQ shared-credentials-file    
secret_key     ****************E8Id shared-credentials-file    
    region                us-east-1      config-file    ~/.aws/config

Creo que este problema ahora se solucionó a través de https://github.com/boto/botocore/pull/388 y estará disponible en la próxima versión de AWS CLI.

@jamesls confirmado arreglado en la versión awscli 1.6.4 . Estaba usando 1.5.4 . ¡Gracias!

Recibo este problema en un sistema ubuntu nuevo.

A client error (SignatureDoesNotMatch) occurred when calling the PutObject operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

Instalado aws-cli a través de pip

$ pip list
ansible (1.5.4)
apt-xapian-index (0.45)
argparse (1.2.1)
awscli (1.6.5)
bcdoc (0.12.2)
botocore (0.76.0)
chardet (2.0.1)
Cheetah (2.4.4)
cloud-init (0.7.5)
colorama (0.2.5)
configobj (4.7.2)
docutils (0.11)
html5lib (0.999)
httplib2 (0.8)
Jinja2 (2.7.2)
jmespath (0.5.0)
jsonpatch (1.3)
jsonpointer (1.0)
Landscape-Client (14.01)
MarkupSafe (0.18)
mercurial (2.8.2)
oauth (1.0.1)
PAM (0.4.2)
Pillow (2.3.0)
pip (1.5.4)
prettytable (0.7.2)
pyasn1 (0.1.7)
pycrypto (2.6.1)
pycurl (7.19.3)
Pygments (1.6)
pyinotify (0.9.4)
pyOpenSSL (0.13)
pyserial (2.6)
python-apt (0.9.3.5)
python-dateutil (2.3)
python-debian (0.1.21-nmu2ubuntu2)
PyYAML (3.10)
requests (2.2.1)
roman (2.0.0)
rsa (3.1.2)
setuptools (3.3)
six (1.5.2)
Sphinx (1.2.2)
ssh-import-id (3.21)
Twisted-Core (13.2.0)
urllib3 (1.7.1)
wsgiref (0.1.2)
zope.interface (4.0.5)

¿Alguna idea de cómo arreglarlo?

Mi solución fue dormir unos segundos y luego intentarlo de nuevo, pero
Parece que puede haber una actualización de la herramienta que también lo corrige.

El martes 2 de diciembre de 2014 a las 3:38 a.m., Mark Wolfe [email protected] escribió:

Recibo este problema en un sistema ubuntu nuevo.

Se produjo un error de cliente (SignatureDoesNotMatch) al llamar a la operación PutObject: la firma de solicitud que calculamos no coincide con la firma que proporcionó. Verifique su clave y método de firma.

Instalado aws-cli a través de pip

lista de $ pip
ansible (1.5.4)
apt-xapian-index (0,45)
argparse (1.2.1)
awscli (1.6.5)
bcdoc (0.12.2)
botocore (0,76,0)
chardet (2.0.1)
Guepardo (2.4.4)
inicio en la nube (0,7,5)
colorama (0,2,5)
configobj (4.7.2)
docutils (0,11)
html5lib (0,999)
httplib2 (0.8)
Jinja2 (2.7.2)
jmespath (0.5.0)
jsonpatch (1.3)
jsonpointer (1.0)
Paisaje-Cliente (14.01)
Marcado seguro (0,18)
mercurial (2.8.2)
oauth (1.0.1)
PAM (0,4,2)
Almohada (2.3.0)
pepita (1,5,4)
bonita mesa (0.7.2)
pyasn1 (0,1,7)
pycrypto (2.6.1)
pycurl (7.19.3)
Pigmentos (1.6)
pyinotify (0.9.4)
pyOpenSSL (0,13)
pyserial (2.6)
python-apt (0.9.3.5)
python-dateutil (2.3)
python-debian (0.1.21-nmu2ubuntu2)
PyYAML (3.10)
solicitudes (2.2.1)
romano (2.0.0)
rsa (3.1.2)
herramientas de configuración (3.3)
seis (1.5.2)
Esfinge (1.2.2)
ssh-import-id (3.21)
Núcleo trenzado (13.2.0)
urllib3 (1.7.1)
wsgiref (0.1.2)
zope.interface (4.0.5)

¿Alguna idea de cómo arreglarlo?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/aws/aws-cli/issues/602#issuecomment -65198065.

@wolfeidau y sí, hablé demasiado pronto. El pip instalado localmente awscli está dando los errores SignatureDoesNotMatch nuevamente. ¡Ay!

A client error (SignatureDoesNotMatch) occurred when calling the DeregisterInstancesFromLoadBalancer operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The Canonical String for this request should have been
'POST
/

host:elasticloadbalancing.us-east-1.amazonaws.com
user-agent:aws-cli/1.6.5 Python/2.7.8 Darwin/13.4.0
x-amz-date:20141203T015747Z

host;user-agent;x-amz-date
1d9dafbf4bfa9b1225d91bdbf99d8645503484d174b9094e4c3af637e6664b5b'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20141203T015747Z
20141203/us-east-1/elasticloadbalancing/aws4_request
5a56d12a4920502f4124e37a92aad475c36edda93d9865871e6a4fe1e49045c3'

¿Este problema ocurre solo cuando se vuelve a intentar una solicitud? ¿O esto sucede cada vez que ejecuta el comando deregister-instances-from-load-balancer?

@jamesls sucede cada vez ahora :(

Sé que este problema está cerrado, pero quería compartir que puede ver este error cuando se ejecuta en una máquina virtual que hiberna. En tales casos, el reloj del sistema no se pone al día constantemente si está usando Ubuntu. Simplemente actualice la hora para corregir (es decir, sudo ntpdate -s time.nist.gov).

hola, ¿hay alguna solución final a esto?

+1

Al usar la versión 1.7.8 de la CLI, estaba viendo el mismo error SignatureDoesNotMatch al intentar lo siguiente:
$ aws iam list-users

Y obteniendo un AuthFailure para esto:
$ aws ec2 describe-security-groups

Después de eliminar mis claves y probar otras nuevas, ambos comandos funcionan.

Esta es la antigua clave de acceso secreta que puede haber sido la causa de mis problemas, tenga en cuenta los caracteres de porcentaje, más y barra inclinada: H2J7 / oT3Fib15SwFVB1s3EnTCmg + SC7wF7qoP + dw%

: +1: @gsterndale. Mi clave de acceso con % no funcionó. Tuve que generar nuevas claves.

También he experimentado este problema varias veces. Cada vez que regeneraba la clave hasta que obtenía una sin ningún carácter especial en ella (en particular, estaba teniendo problemas con el signo + en el secreto) lo solucionaba.

A decir verdad, todos mis problemas de claves de firma desaparecieron cuando cambié de ejecutar el comando en una máquina ubuntu en lugar de una instalación local de Mac Homebrew.

Soy muy nuevo en AWS, enfrenté este problema de inmediato en el nodo js

              ^

SignatureDoesNotMatch: la firma de la solicitud que calculamos no coincide con la firma que proporcionó. Verifique su clave de acceso secreta de AWS y el método de firma. Consultar el s
vice documentación para más detalles.

La cadena canónica para esta solicitud debería haber sido
'CORREO
/

anfitrión: email.us-west-2.amazonaws.com
x-amz-content-sha256: 89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39
x-amz- fecha: 20150809T053346Z

host; x-amz-content-sha256; x-amz-date
89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39 '

El String-to-Sign debería haber sido
'AWS4-HMAC-SHA256
20150809T053346Z
20150809 / us-west-2 / ses / aws4_request
0b908b0248bae550b814b37629a418707742416377816b5a5e78e1897b72293e '

+1

Tengo este problema para todos los comandos aws s3 (awscli 1.8.6 en ubuntu 14.04 LTS).
¿Existen soluciones conocidas? Intenté eliminar mi archivo de credenciales y ejecutar aws configure, reiniciar y reinstalar awscli.

@mcobzarenco , ¿has probado nuevas claves?

@gsterndale Vi el comentario anterior sobre tener barras inclinadas en las claves antiguas, pero ese no es el caso y mis claves se generaron recientemente (en junio de 2015). Solo tengo este problema en AWS Ubuntu 14.04 LTS. En mi computadora portátil (14.04) awscli (misma versión) funciona bien.

@mcobzarenco No creo que sea la edad de las teclas, sino los caracteres especiales en ellas. Cuando creé originalmente las claves, tenían el porcentaje, el signo más y los caracteres de barra diagonal. Mientras depuraba el problema, intenté eliminar y crear nuevas claves. Estos nuevos afortunadamente no tenían ninguno de estos personajes y funcionan.

acabo de encontrar este problema en ubuntu. Cuando ingresé las claves a través de cli, las almacenó en ~ / .aws / config, pero eliminó el carácter '+'. La edición manual del archivo para agregar el '+' me permitió conectarme.

@gsterndale Gracias por el consejo, puedo confirmar que generar una nueva clave que no contiene + funcionó para mí. La solución de @stebl es buena si es inconveniente reemplazar las claves.

Enfrenté el mismo problema al usar AWS SDk con el nodo js. Para resolver este problema, seguí exactamente los mismos pasos que se mencionan aquí.
http://aws.amazon.com/developers/getting-started/nodejs/

Creo que AWS SDK está desarrollado con una versión particular del nodo js, ​​la falta de coincidencia en el nodo js resultará en problemas como este.

Tengo el mismo problema y sí, se resolvió usando una tecla sin símbolos especiales (el + en mi caso específico)

Encontramos este error (donde una máquina podría describir instancias usando awscli pero la otra obtuvo un error de acceso denegado con la misma clave de acceso. En la última máquina, iam list-users dio este error SignatureDoesNotMatch). Se resuelve corrigiendo la hora del reloj del sistema en la máquina con el problema.

Como dijo @tukaaa , hay un error si la clave de acceso secreta contiene un carácter no alfabético (como +). Creo que es una mala escapada a alguna parte ;-(

@ebuildy ¿Puede confirmar en qué versión de la CLI está viendo esto ( aws --version )? Si este es un motivo para la versión de la CLI, seguiré adelante y reabriré este problema.

Recibo esto en aws-cli/1.9.1 Python/3.5.0 Windows/7 botocore/1.1.8

Estaba teniendo el mismo problema en una caja de Windows, usando una clave sin caracteres no alfa. Verifiqué que no era un error de copiar / pegar usando el mismo búfer de pegado en otro cuadro. Desinstalar / reinstalar la cli de AWS y eliminar las credenciales / archivos de configuración, luego volver a ejecutar la configuración de AWS lo solucionó.

Acabo de ver esto en aws-cli/1.10.3 Python/2.7.10 Darwin/14.5.0 botocore/1.3.25 .

La regeneración de una clave sin caracteres especiales lo solucionó. FWIW en mi caso, el carácter especial era / y estaba usando un archivo INI.

Ok reapertura, profundizaremos en esto.

@ Puedo confirmar que tengo el mismo problema que describe @gsterndale .

aws --version
aws-cli/1.10.6 Python/2.7.11 Linux/3.10.0-327.4.5.el7.x86_64 botocore/1.3.28

Pero mi clave no contiene ningún símbolo especial.

Recibo el mismo error al usar el módulo de nodo s3-cli. Mi clave secreta contiene un [ .

Finalmente descubrí lo que estaba mal. Agregué accidentalmente varios caracteres a las teclas. Esa es la razón.

Me enfrentaba a este problema con el siguiente escenario; tanto en rhel7 como en ubuntu. Creo que tiene algo que ver con los caracteres no alfabéticos, como han mencionado otros.

• Cubo s3 protegido para un solo rol
• La instancia ec2 con dicho rol debe asumir el mismo rol antes de acceder al depósito s3 protegido

aws sts assume-role --role-arn <role_name> --role-session-name default --output json --query Credentials > credentials.json
export AWS_ACCESS_KEY_ID=`sed -n 's/.*"AccessKeyId": "\(.*\)"/\1/p' credentials.json`
export AWS_SECRET_ACCESS_KEY=`sed -n 's/.*"SecretAccessKey": "\(.*\)",/\1/p' credentials.json`
export AWS_SESSION_TOKEN=`sed -n 's/.*"SessionToken": "\(.*\)",/\1/p' credentials.json`

Creo que algo con la consulta estaba estropeando las credenciales. Al ejecutar los comandos manualmente y copiar y pegar los valores; luego, estableciendo las variables de entorno, parecía funcionar bien.

Tuve el mismo problema al ejecutar awscli versión 1.10 en Mac (instalado a través de pip) versus Ubuntu (imagen de Amazon) awscli versión 1.2.9. aws configure --profile user produce dos configuraciones diferentes bajo cada una. La versión 1.10 produjo dos archivos: config y credentials. La versión 1.2.9 acaba de producir un archivo de configuración (pero con la información de la credencial). Cuando eliminé las credenciales y el archivo de configuración producido por la versión 1.10 y copié el archivo de configuración producido por la versión 1.2.9, todo funcionó, incluso con caracteres especiales y ejecutando awscli versión 1.10. El archivo de configuración producido por la versión 1.2.9 es

[profile FOO0]
aws_secret_access_key = FOO1
aws_access_key_id = FOO2
output = FOO3
region = FOO4

Puede confirmar que se debe a caracteres no alfanuméricos.

Tengo el mismo problema con una clave secreta que contiene un +. Sin embargo, no soy el propietario de la cuenta S3 y no puedo crear una nueva fácilmente. ¿Alguien ha encontrado alguna solución que no sea la de crear una nueva clave sin caracteres especiales?

tl; dr Solución: vuelva a crear repetidamente las credenciales HASTA que su aws_secret_access_key NO contenga caracteres no alfanuméricos ... en mi caso, aws_secret_access_key contenía un + (signo más)

Acabo de hacer una nueva instalación ... el mismo problema ... esto es en Ubuntu ... no es un problema del sistema operativo local, es un problema de la API de Amazon, así que ignore otros comentarios que dicen que dejar OSX lo soluciona

aws ec2 describir-instancias

Se produjo un error (AuthFailure) al llamar a la operación DescribeInstances: AWS no pudo validar las credenciales de acceso proporcionadas

------------------------------------------------

aws ec2 describe-security-groups

Se produjo un error (AuthFailure) al llamar a la operación DescribeSecurityGroups: AWS no pudo validar las credenciales de acceso proporcionadas

------------------------------------------------

aws ecr get-login

Se produjo un error (InvalidSignatureException) al llamar a la operación GetAuthorizationToken: la firma de solicitud que calculamos no coincide con la firma que proporcionó. Verifique su clave de acceso secreta de AWS y el método de firma. Consulte la documentación de servicio para obtener más detalles.

La cadena canónica para esta solicitud debería haber sido
'CORREO
/

tipo de contenido
anfitrión: ecr.us-east-1.amazonaws.com
x-amz- fecha: 20160615T182955Z
x-amz- target: AmazonEC2ContainerRegistry_V20150921.GetAuthorizationToken

tipo de contenido; host; x-amz-date; x-amz-target
44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a '

El String-to-Sign debería haber sido
'AWS4-HMAC-SHA256
20160615T182955Z
20160615 / us-east-1 / ecr / aws4_request
86c2e3c850acd6765a1ca6aa626c6e9a6c85284f3954f45e170f51b5b89961c7 '

------------------------------------------------

aws iam lista-usuarios

Se produjo un error (SignatureDoesNotMatch) al llamar a la operación ListUsers: La firma de solicitud que calculamos no coincide con la firma que proporcionó. Verifique su clave de acceso secreta de AWS y el método de firma. Consulte la documentación de servicio para obtener más detalles.

La cadena canónica para esta solicitud debería haber sido
'CORREO
/

anfitrión: iam.amazonaws.com
x-amz- fecha: 20160615T183516Z

anfitrión; x-amz-date
b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2 '

El String-to-Sign debería haber sido
'AWS4-HMAC-SHA256
20160615T183516Z
20160615 / us-east-1 / iam / aws4_request
ad9f7581f0bf25ecae56355a6c96b60f3dc3188efbbdb3d0d4806e9f2c5cf8a9 '

------------------------------------------------

aws --versión
aws-cli / 1.10.38 Python / 2.7.11 + Linux / 4.4.0-22-genérico botocore / 1.4.28

------------------------------------------------

cat /root/.aws/credentials
[defecto]
aws_access_key_id = AKIAJ7FCEUVVSGX7KZGQ
aws_secret_access_key = inCv47xj + eGE2C9crwilZJmKZg6vN / 3JTh5LDaNb

    Notice the plus sign ( + ) in above aws_secret_access_key   !!!!

   aws only works when aws_secret_access_key does NOT contain non-alpha chars

------------------------------------------------

SOLUCION:
Después de eliminar y crear nuevas credenciales
donde aws_secret_access_key NO tenía el signo más (+) todo estaba bien arriba, los comandos comenzaron a funcionar bien

Yo tuve el mismo problema. Re-crear credenciales hasta que no tuviera caracteres especiales funcionó para mí.

Descubrí que cuando copié y pegué las credenciales, tenían ^ M caracteres al final, lo que estaba causando el error.

Obtener una clave secreta sin + arregló también ...

Nota: si ve este problema en la ventana acoplable (boot2docker VM'd), es posible que el reloj de la máquina virtual no esté sincronizado.
Ver: http://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host

Tengo el mismo problema. ¿Qué pasa si no tengo permisos para volver a generar las credenciales ... alguna posible solución utilizando otras formas?

ACTUALIZACIÓN: arreglé esto ejecutando rm -rf .aws/cli/cache/

Ahora también tengo este problema. Al intentar asumir el rol

Versión:
aws-cli/1.11.17 Python/2.7.10 Darwin/16.1.0 botocore/1.4.74

Editar: Intenté actualizar también nuevamente ahora, el mismo problema:
aws-cli/1.11.18 Python/2.7.12 Darwin/16.1.0 botocore/1.4.75

Producción:

Assuming role arn:aws:iam::XXXXXXXX:role/XXXX-staging using profile default

An error occurred (SignatureDoesNotMatch) when calling the AssumeRole operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The Canonical String for this request should have been
'POST
/

host:sts.amazonaws.com
x-amz-date:20161118T102600Z

host;x-amz-date
41db88384d54dc0783e616aa0662ebffce8832b35025195052029a5dc0e33c0e'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20161118T102600Z
20161118/us-east-1/sts/aws4_request
786b3d624f5aeea9ffcb2b802b177a4c2aebbfed608a2464ee684c6972bc6bc6'

El mismo problema sigue existiendo con la última versión (actualizada) de AWS CLI también. Acabo de actualizar mi CLI 1.8.3 a 1.11.19, y no pude ejecutar ningún comando con un nuevo usuario / claves que he creado. Tuve que reciclar alrededor de 5 claves antes de obtener un par en el que la clave secreta no tenía ningún carácter no alfabético. Una vez que me topé con ese par, CLI funciona bien.

Muy molesto: desearía que Amazon no generara claves no válidas que no pueden procesar ...

@ mpopova-yottaa ¿intentaste borrar por completo el caché de awe-cli? Intente eliminar todo el directorio ~/.aws (haga una copia de sus archivos de configuración / credenciales)

aws ec2 describe-instances ejecuta para mí, pero al intentar crear una pila de formación de nubes:

`` `Excepción en el hilo" main "com.amazonaws.services.cloudformation.model.AmazonCloudFormationException: La firma de solicitud que calculamos no coincide con la firma que proporcionó. Verifique su clave de acceso secreta de AWS y el método de firma. Consulte la documentación de servicio para obtener más detalles.

La cadena canónica para esta solicitud debería haber sido
'CORREO
/

amz-sdk-invocation-id: 18d13b66-80ae-f676-c0cf-dbf875edb1aa
amz-sdk- reintento: 3/345/470
anfitrión: cloudformation.us-west-1.amazonaws.com
agente de usuario
x-amz- fecha: 20161127T194448Z

amz-sdk-invocation-id; amz-sdk-retry; host; user-agent; x-amz-date
aca0973fb4ac4029ec038d9c80b4afa23b6d305822b10e6bc32751ee1bd311d5 '

El String-to-Sign debería haber sido
'AWS4-HMAC-SHA256
20161127T194448Z
20161127 / us-west-1 / cloudformation / aws4_request
cb0286a8727afcc465171ab991accde0aaa7210e160a9ba3196e2a5e4305f428 '(Servicio: AmazonCloudFormation; Código de estado: 403; Código de error: SignatureDoesNotMatch; Id. de solicitud: f52abbd4-b4d9-11e6-b98509-d5ec3b989)

config details:

`$: aws --version`           >>       `aws-cli/1.11.21 Python/2.7.12 Darwin/14.5.0 botocore/1.4.78`

`$: aws configure list`     >>
```   Name                Value                Type     Location
      ----                   -----                  ----        --------
profile                    not set>             None    None
access_key     ****************RTSA                env
secret_key     ****************UC3r                  env
region                us-west-1              env       AWS_DEFAULT_REGION

La clave secreta solo contiene caracteres alfanuméricos, así que estoy atascado.

@ aebrow4 Está en la memoria caché de awe-cli. Intente eliminar: .aws/cli/cache/

@cultavix no hay directorio cli dentro de .aws

Recibí este error al ejecutar aws glacier upload-archive con --archive-description "`date`" . Cuando uso --archive-description "`date +%Y/%m/%d`" funciona bien, por lo que parece haber algún problema de escape.

Estaba teniendo un problema similar:

λ aws s3 sync s3://foo-bar-assets/ . --exclude "*/*.mp4" --exclude "*.mp4" fatal error: An error occurred (SignatureDoesNotMatch) when calling the ListObjects operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

Intenté sincronizar la hora con un servidor NTP (con éxito), pero esto no resolvió el problema. Regenerando claves hasta que tuve un conjunto sin caracteres especiales lo arregló.

λ aws --version aws-cli/1.11.16 Python/2.7.9 Windows/8 botocore/1.4.73

Tengo el mismo problema al usar awscli y código de muestra de Python (boto3).
Tenga en cuenta que estoy usando IBM Object Storage S3 compatible con la API, puedo enumerar los depósitos y su contenido, pero no puedo cargar (tanto para el código Pyhton como para la CLI).
Probé el escenario con ruby aws-sdk y funciona bien (cargar / descargar).
- configuración
aws-cli/1.2.9 Python/3.4.3 Linux/3.19.0-33-generic

Acabo de empezar a tener este mismo problema con un script que he estado usando durante meses para depositar cargas de varias partes en Glacier. Todavía se puede depositar bien a través de aws cli, por lo que las credenciales aún funcionan, pero el script que usa boto3 falla con:

"botocore.exceptions.ClientError: se produjo un error (InvalidSignatureException) al llamar a la operación InitiateMultipartUpload: la firma de la solicitud que calculamos no coincide con la firma que proporcionó. Verifique su clave de acceso secreta de AWS y el método de firma. Consulte la documentación del servicio para obtener detalles".

aws --versión es
aws-cli / 1.11.38 Python / 2.7.10 Darwin / 15.6.0 botocore / 1.5.1

(sí, actualicé todo pensando que podría solucionar el problema ... no tuve tanta suerte).

obtener un nuevo par de llaves sin ningún carácter especial (era + en mi caso) solucionó el problema para mí

otra confirmación aquí del manejo incorrecto de + en la clave secreta.

Hola a todos, aquí hay un script que he usado para intentar reproducir este problema: https://gist.github.com/jamesls/00ef7fcc0ac39ba8b06956d165c42f6d . Esto es lo que hace el guión:

• Crea un nuevo par access_key / secret_key a través de aws iam create-access-key en un bucle hasta que encuentra credenciales que tienen un carácter + o / .
• Crea un nuevo perfil "testcreds" con estas credenciales recién generadas
• Intenta invocar varios comandos de la AWS CLI para garantizar que estas credenciales funcionen

Hace esto en un bucle infinito hasta que falla una llamada a la API. Hasta ahora no he podido hacer que falle. Las claves secretas que tienen + y / me funcionan.

En este punto, hemos confirmado que definitivamente es posible usar claves_secretas que tienen + o / así que no creo que la causa raíz sea algo tan sencillo como un error en nuestro código de firma. que se rompe cuando + está presente. Al releer los comentarios en este hilo, podría ser un problema con la forma en que se ingresan las credenciales en el archivo ~/.aws/config o ~/.aws/credentials . Quizás hay algo específico de la plataforma que está alterando caracteres que contienen + o / .

Entonces, para cualquier persona que todavía tenga este problema, sería realmente útil si pudiera proporcionar información adicional:

1. ¿Cómo obtiene las credenciales (copiar / pegar desde la consola, aws iam create-access-key , archivo CSV desde la consola, etc.)?
2. ¿Cómo está configurando la CLI para usar estas credenciales? ¿Está ejecutando aws configure e ingresando los valores cuando se le solicite? ¿Está haciendo esto programáticamente ejecutando aws configure set ? ¿Está editando manualmente ~/.aws/config y / o ~/.aws/credentials ? ¿Configurando las diversas variables AWS_* env?

Cosas extra que serían aún más útiles si fuera posible:

1. Si usa otros SDK, ¿estas credenciales que no funcionan en la CLI funcionan en otros SDK de AWS?
2. Si tiene una cuenta de prueba o un usuario de IAM de prueba, ¿la ejecución del script que estoy usando para probar alguna vez falla?

Cualquier información adicional que pueda ayudarnos a reprogramar este problema por nuestra parte sería genial.

Sigo teniendo este problema. Para responder tu pregunta:
Credenciales creadas en la consola de Amazon y cortar / pegar en ~ / .aws / credentials (editadas con emacs en una mac)

Según la solución de problemas que he realizado hasta ahora (y soy un novato en esto ...), la 'Cadena canónica' es correcta, pero la 'Cadena a firmar' es incorrecta, ya que tiene una última línea diferente. Es decir, cuando imprimo el valor de retorno de auth.py string_to_sign, el número producido a partir de 'sha256 (canonical_request.encode (' utf-8 ')). Hexdigest ())' es diferente al número informado en el error devuelto "The String -to-Sign debería haber sido ".

No hay caracteres especiales en mis credenciales, y funcionan cuando utilizo otras herramientas, por ejemplo, CrossFTP (¡que no quiero usar!)

¡¡Cualquier idea sería muy apreciada!!

@ samato88 que parece ser un problema diferente allí. Si pudiera compartir cualquier información de depuración (asegurándose de eliminar cualquier información confidencial) eso ayudaría.

El string_to_sign no está influenciado por el secret_access_key. Cuando firmamos una solicitud, tomamos la solicitud HTTP que estamos a punto de enviar, la convertimos en una cadena (es decir, la cadena ot sign) y luego, usando la clave secreta, firmamos esa cadena con la clave secreta (omitiendo algunas detalles aquí). Por lo tanto, cualquier problema con la cadena a firmar estaría separado de este problema.

¿Podría abrir otro problema y proporcionar la salida --debug (o incluir la solicitud completa y el mensaje de error del servicio)? Estaremos encantados de investigar esto por usted.

Gracias jamesls. Abrí una edición separada en:
https://github.com/aws/aws-cli/issues/2474

Cualquier idea muy apreciada.

Si el tiempo de su sistema tiene un retraso de más de 5 minutos, no podrá usar la CLI

solo ejecuta ... sudo ntpdate -s time.nist.gov

vuelva a intentarlo

Tuve el mismo problema, mi clave secreta contiene el signo "+". Eliminé mi archivo .aws / credentials y volví a ejecutar aws configure. Después de eso, mi consulta a la cola de sqs para recibir el mensaje funcionó.

Gracias @ AlexParra03 . Tuve el mismo problema y tus comentarios me ayudaron a resolverlo .... :-)

@robotzero ¿recuerdas cómo ingresaste tus credenciales? ¿Ejecutó aws configure y luego copió / pegó los valores de la consola web?

Sí, ejecuté aws configure y copié y pegué los valores.

Sí, tenía un + en mi secreto, lo que aún causaba este error. Hacer nuevas claves sin caracteres especiales solucionó el problema.

aws --versión
aws-cli / 1.11.78 Python / 3.6.1 Darwin / 15.6.0 botocore / 1.5.41

Tenía un + y un / en mi secreto. Los secretos sin estos me resolvieron el problema.

También tuve este problema.

$ aws --version
aws-cli/1.11.44 Python/3.5.3 Linux/4.10.0-19-generic botocore/1.5.7

$ lsb_release -sd 
Ubuntu 17.04

Tenía un "+" en las credenciales. Se resolvió regenerando la clave de acceso sin ellos. Como nota: "/" es un buen carácter para tener.

@adityanatraj @shwetapurushe @damienrj ¿ Pueden todos responder estas preguntas aquí ? En este punto, estamos tratando de obtener más información sobre su entorno y cómo está ingresando las credenciales. Como se mencionó en ese comentario, generar una clave secreta con + no nos reprocha el problema, por lo que posiblemente esté relacionado con una combinación de su entorno y / o cómo está ingresando las credenciales.

En otras palabras, necesitamos más información de las personas para poder solucionar lo que está sucediendo.

@jamesls

1. ¿Cómo obtuve las credenciales?

Obtuve las credenciales copiándolas desde la consola web.

1. ¿Cómo configuro CLI para usarlos?

Creé manualmente los dos archivos:

~ / .aws / config

[default]
region = us-east-1
output = json

~ / .aws / credenciales

[default]
aws_access_key_id = ACCESS_KEY_HERE 
aws_secret_access_key = SECRET_ACCESS_KEY_THAT_BREAKS_WITH_A_+_SIGN

Lo siento, no puedo ayudar con las preguntas adicionales, ya que eliminé mis claves de acceso que contienen los signos "+", por lo que el problema no aparece.

@adityanatraj gracias, todo ayuda.

El siguiente paso que nos ayudaría a solucionar problemas es averiguar si se trata de un problema solo con la CLI o un problema con las credenciales mismas. Para cualquiera que todavía tenga este problema, sería muy útil si pudiera probar estas credenciales en otros SDK de AWS. Para ayudar con esto, he creado un repositorio / script de muestra que lo hace fácil si no desea configurarlo usted mismo: https://github.com/jamesls/aws-creds-test . Simplemente clone el repositorio y ejecute make install , make test .

/tmp $ mkdir /tmp/repro-cli-602
/tmp $ cd /tmp/repro-cli-602/
/tmp/repro-cli-602 $ git clone git://github.com/jamesls/aws-creds-test
Cloning into 'aws-creds-test'...
...
/tmp/repro-cli-602 $ cd aws-creds-test/
/tmp/repro-cli-602/aws-creds-test (master u=) $ make install
npm install
[email protected] /private/tmp/repro-cli-602/aws-creds-test
├─┬ [email protected]
...
pip install -r requirements.txt
Requirement already satisfied: botocore<2.0.0,>=1.5.0 in /usr/local/lib/python2.7/site-packages (from -r requirements.txt (line 1))
...



/tmp/repro-cli-602/aws-creds-test (master u=) $ make test
./test-creds.sh
Testing python...
Access Key:
Secret Access Key:
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20

SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Successfuly made an AWS request with the provided credentials.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20


SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Sucessfully made an AWS request with the provided credentials.

Para las personas que se encuentran con este problema, ejecuten el script de prueba y compartan el resultado.

Esta misma excepción me sucedió en una solicitud PutObject (C #), siempre que los metadatos del objeto tenían caracteres Unicode.

Tuve el mismo problema. Las nuevas claves secretas con + y / no funcionan. Genere nuevas claves sin esos personajes y funcionan bien.
Su secuencia de comandos de prueba es para Linux y estoy ejecutando Windows.
Pegué mis credenciales usando Control-C y Control-V usando Windows shell y _aws configure_
y solo estaba usando _aws cp_

También probé esto, y funciona bien siempre que la clave secreta no tenga símbolos, como se mencionó anteriormente.

Espero ver que esto se resuelva pronto, ¡es un dolor tener que seguir regenerando credenciales hasta que obtenga una que funcione!

Ayer presenté un ticket de soporte a AWS y hoy parece estar resuelto

He probado varias veces y + y / ¿ambos parecen funcionar ahora? Ya no puedo reproducir este error.

Tuve el mismo problema en mi Pi.
Con el awscli más nuevo (aws-cli / 1.11.85 Python / 3.4.2 Linux / 4.9.24-v7 + botocore / 1.5.48) todavía tenía el problema:

root @ pi : ~ # aws s3 ls s3: //
Se produjo un error (SignatureDoesNotMatch) al llamar a la operación ListBuckets: La firma de solicitud que calculamos no coincide con la firma que proporcionó.
Verifique su clave de acceso secreta y el método de firma. Para obtener más información, consulte Autenticación REST y Autenticación SOAP para obtener más detalles.

Incluso con una clave secreta que no tenía caracteres especiales (+ o /), el acceso no funcionaba. El tiempo siempre estuvo sincronizado, desafortunadamente este tampoco fue el problema.

En el archivo ".aws / config" agregué una región válida (solo para probar ...) y de repente funcionó. Como estoy usando almacenamiento s3 compatible (no s3 de Amazon)

[defecto]
aws_secret_access_key = MI CLAVE
aws_access_key_id = MYID
region = us-east-1 <- antes había un valor "ficticio".

Como parece, la región debe tener un valor "correcto". Cuando lo cambio de nuevo a algo diferente como "dummyvalue", aparece el mismo error que se mencionó anteriormente.
¡Ahora con el valor "us-east-1" funciona!
Espero que esto ayude a alguien.

También me encontré con esto. También parece haber un problema con un '+' en la clave secreta. Si tengo los créditos en las variables de entorno, aparece el error. Si los pongo en el archivo ~ / .aws / credentials (editando a mano) no obtengo el error.

[editar] Acabo de notar que las variables de entorno estaban en un archivo formateado para dos (ff = dos en vim). Fue esto porque acababa de tomar el archivo .csv tal como lo descargué y lo edité para cambiar las entradas en variables de entorno. Cuando volví a formatear el archivo en 'ff = unix' ya no recibí el error. La única diferencia entre los 2 es el retorno de línea, dos usa "CR-NL" mientras que unix es simplemente "NL". Supongo que fue en realidad ese carácter "CR" el problema.

yo también, y también confirmo el problema "+"

Si se encuentra con esto cuando usa Docker para Mac, simplemente reiniciar Docker solucionará la discrepancia de hora del sistema.

Estaba enfrentando el mismo problema.
Comprobé el secreto, y tenía + / en él.
Tuve que crear un nuevo par de ID sin un carácter especial para que funcionara

La creación de nuevos pares de claves hasta que obtuve uno sin caracteres especiales también lo resolvió para mí; los caracteres especiales (específicamente +) simplemente no funcionan en ~ / .aws / credentials.

La clave generada sin caracteres especiales (específicamente + ) solucionó el problema para mí también.

Formatear el archivo según el comentario de @eikenb también funciona.

Eliminar la clave y crear una nueva funcionó para mí.

Recién recibí este error. Se actualizó la hora del sistema, que parecía estar a más de 6 minutos de GMT. Se solucionó el problema de inmediato.

Fue tan extraño y complicado para mí.
Luché con este problema y muchas veces intenté resolverlo.
Por el momento ¡De repente funcionó! Me sorprendió, así que hice un nuevo cubo, pero no funcionó. Debido a que no había hecho nada más que cambiar el código, solo esperé durante horas. Finalmente, funcionó bien aunque no hice nada. No puedo creerlo ...

Usando aws configure en un shell bash en Windows 7 descubrí que tenía dos líneas aws_secret_access_key en mi .aws/credentials y la segunda línea era donde había escrito mal una carga de basura . Eliminó la segunda línea y todo funcionó.

aws-cli/1.11.119 Python/2.7.12 Linux/4.4.0-53-generic botocore/1.5.82

Viendo este problema en Linux Mint aquí, sin + en mi clave o secreto.

Salida del script de prueba:

/aws-creds-test $ make test
./test-creds.sh
Testing python...
Access Key: 
Secret Access Key: 
AKID   hash: 36b0df669bfc2fa232f31ada2b40e8f58ec152b0afee875f28b21e32e2d59a30
AKID length: 20

SAK    hash: 02b21158d3ab7d2691ceef468951c3b3551704a8eea19ad4a8f59c7be38378f6
SAK  length: 40
Error making AWS request: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 36b0df669bfc2fa232f31ada2b40e8f58ec152b0afee875f28b21e32e2d59a30
AKID length: 20


SAK    hash: 02b21158d3ab7d2691ceef468951c3b3551704a8eea19ad4a8f59c7be38378f6
SAK  length: 40
Error making AWS request
{ SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
    at Request.extractError (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/protocol/query.js:47:29)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
  message: 'The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.',
  code: 'SignatureDoesNotMatch',
  time: 2017-09-18T20:33:23.951Z,
  requestId: '9e62c6c2-9cb0-11e7-9856-a5fd5c3e417d',
  statusCode: 403,
  retryable: false,
  retryDelay: 60.66602455065775 }
Makefile:6: recipe for target 'test' failed
make: *** [test] Error 1

Después de actualizar awscli a aws-cli/1.11.154 Python/2.7.12 Linux/4.4.0-53-generic botocore/1.7.12 :

$ make test
./test-creds.sh
Testing python...
Access Key: 
Secret Access Key: 
AKID   hash: 0cdf83ac8cf800ca46738682ff5a0ab35d94891a568fc6fd9115ecf13dcce542
AKID length: 20

SAK    hash: 7ae856b46f3d5cd23b94f60765adbeb13215f6c226a2953ab93eed9e26d51694
SAK  length: 40
Error making AWS request: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 0cdf83ac8cf800ca46738682ff5a0ab35d94891a568fc6fd9115ecf13dcce542
AKID length: 20


SAK    hash: 7ae856b46f3d5cd23b94f60765adbeb13215f6c226a2953ab93eed9e26d51694
SAK  length: 40
Error making AWS request
{ SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
    at Request.extractError (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/protocol/query.js:47:29)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
  message: 'The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.',
  code: 'SignatureDoesNotMatch',
  time: 2017-09-18T20:43:21.662Z,
  requestId: '02ab939a-9cb2-11e7-a1f3-87975b0dbd52',
  statusCode: 403,
  retryable: false,
  retryDelay: 86.52138921193912 }
Makefile:6: recipe for target 'test' failed
make: *** [test] Error 1

Acabo de recrear mis claves: la nueva todavía contiene un '+', pero ahora puedo usar el cli

Podría ser tan fácil como eso

@ DanAbbz92 de hecho, encontré la misma solución ahora. No tengo idea de por qué las claves antiguas nunca funcionaron, pero las nuevas estaban bien usando el mismo proceso.

Tenía un ^ V en mi clave secreta por un mal intento de pegado. Puede ser prudente poner una advertencia más fuerte sobre la verificación de caracteres incorrectos en las claves. Evitará más escaladas innecesarias.

Este problema se informó en 2014. Hoy es 26 de octubre de 2017. Encontré este problema, mi secreto tenía un "+". Creé una nueva clave y la puse en ~ / .aws / configure
Vamos, Amazon, ¿alguna vez planeas arreglar este error * ???

Encontré este problema hoy después de instalar el cli y ejecutar aws configure . Mis claves no tenían caracteres especiales, pero lo siguiente solucionó mi problema:

• rm -r ~/.aws/
• recreó la carpeta .aws y el archivo credentials y agregó las credenciales manualmente

tl; dr apagarlo y encenderlo nuevamente funcionó para mí ¯_ (ツ) _ / ¯

Para las personas que usan Hadoop que terminan aquí: Se ha corregido un error relacionado para Hadoop 2.8.0:
Las URL "

Hola, hoy me he encontrado con el mismo problema.
La caja tenía un mal momento. Después de actualizar el tiempo, todo está funcionando.

Añadiendo otro "yo también"

Tenía una clave secreta que tenía dos caracteres '+' y eso funcionaba desde mi archivo .aws / credentials en mi VM de Windows (cuando lo usa una aplicación .NET), pero cuando instalé awscli de brew en mi MacBook Pro y copió los archivos .aws (probando codificaciones de archivos, formatos de final de línea, etc.) falló con SignatureDoesNotMatch.

Intenté recrear las credenciales hasta que obtuve una clave secreta sin ningún alfanumérico, y ahora funciona desde awscli en mi Mac. Copiando esas credenciales de nuevo a mi máquina con Windows y ejecutando la aplicación .NET, eso todavía funciona.

No realicé ningún cambio en la hora en ninguna de las máquinas (la Mac ya estaba usando NTP, y la VM de Windows parece que se está ejecutando unos 12 minutos por detrás de la hora real)

Instalé awscli con: brew install awscli

y aws --versión devuelve: aws-cli / 1.14.30 Python / 3.6.4 Darwin / 16.7.0 botocore / 1.8.34

Bueno, empujé el código a lambdas esta tarde (2018-02-01 15:48 EST con lambda en us-east-1).
Ahora a las 6:00 p. M., Recibo errores de firma en todos los sistemas de la oficina.
Mirando hacia atrás a través de este hilo: mis tiempos son correctos, nada ha cambiado, las credenciales tienen menos de un año, han estado funcionando desde el día en que se establecieron, usando la versión homebrew aws-cli/1.14.30 Python/3.6.4 Darwin/17.4.0 botocore/1.8.34 (intenté una degradación a 1.14. Versión 2x, sin amor)

Esto es algo de malarky

Tener el mismo problema y resolver generando nuevas claves sin caracteres especiales (como /, + y así sucesivamente).

¡Gracias a @hellais por la entrada!

Simplemente tuve el mismo problema, lo resolví corrigiendo el reloj de mi computadora portátil. Aparentemente estaba atrasada.

Acabo de experimentar este problema y parece que mi cliente ntp tenía un retraso de 10 minutos. Hice una ntpdatey ahora todo está arreglado.

Puedo confirmar que la recreación de mis claves de acceso hasta que obtuve una sin caracteres especiales funcionó. Qué error más ridículo, guau.

Dado que se trata de un problema de larga duración, ¿no sería inteligente actualizar los mensajes de error para brindarles a los usuarios un enlace a una posible solución, como reconstruir sus claves? En lugar de algo que demuestre que el problema es mucho más complejo que "sí, nos equivocamos cuando tus claves tienen caracteres especiales, ¡lo siento!".

mismo problema escuche:

Versiones:

aws-cli/1.14.58 Python/2.7.10 Darwin/17.4.0 botocore/1.9.11

Mando:

aws s3 ls
obtuve el siguiente error:
Unknown Signature Version: s3v3.

sin solución:

actualicé mi capa y genero un secreto sin ningún personaje especial

actualización - arreglado siguiendo

aws configure set default.s3.signature_version s3v4

Sí, esto sigue siendo un problema: mi clave secreta terminó con un carácter + y no encontré ninguna solución que funcionara. Regeneraron nuevas claves sin + al final de la clave secreta y funcionó bien.

¿Cómo diablos es esto todavía un problema?

Se produjo un error (SignatureDoesNotMatch) al llamar a la operación CreateMultipartUpload: la firma de solicitud que calculamos no coincide con la firma que proporcionó. Verifique su clave y método de firma.
por favor ayuda.

Mi secreto comienza con el signo + y ni siquiera sabía que había este problema hasta hoy. Utilizo boto3 python para acceder a mi s3. No funciona cuando paso las credenciales como cadenas sin procesar, pero funciona bien si lo cargo desde config.ini como una variable usando configparser.RawConfigParser() . Por supuesto, generar un nuevo secreto sin el signo + al final o al principio también resolverá este problema.

No obstante, si esto (por alguna razón) no se puede solucionar, tal vez cambie el mensaje de excepción a algo como "no permitimos el signo +, genere uno nuevo si desea acceder a él de la forma en que lo hace".

Estoy usando aws cli en osx y también tenía un secreto que parecía no ser correcto. Mi original tenía un + y un = y recibí el error SignatureDoesNotMatch al intentar cp archivos a s3. Regeneré las claves y mi nuevo secreto ahora es una cadena alfanumérica. Solo agrego otra confirmación de que la regeneración funciona. :aliviado:

Con la esperanza de que esto pueda proporcionar información, este problema (no manejar + en claves secretas) se expone con esta versión en RHEL5

aws-cli/1.15.25 Python/3.4.7 Linux/3.2.45-0.6.wd.865.49.315.metal1.x86_64 botocore/1.10.25

pero no ocurre con esta versión en Ubuntu

aws-cli/1.11.13 Python/3.5.2 Linux/4.4.0-121-generic botocore/1.4.70

Comenzó en enero de 2014 y ahora en junio de 2018, más de 4 años y tuve el mismo problema con el error SignatureDoesNotMatch . La solución para mí fue la misma que todas las soluciones de la mayoría aquí, obtener una nueva clave secreta sin ningún carácter especial, ya que mi clave anterior tiene dos puntos : , probé la sincronización de tiempo, pero no funcionó para mí. Estoy usando WSL.

aws-cli/1.15.27 Python/3.6.5 Linux/4.4.0-17134-Microsoft botocore/1.10.27

Acabo de actualizar lo que dijo @gchiu en abril de 2017: todavía es el caso en junio de 2018 que los secretos que tienen el carácter de barra (/) pueden hacer que el cliente PHP no funcione (PHP 7 en Windows 10 en mi caso), devolviendo el _las firmas no coinciden_ error. En esta situación, simplemente genere otro par de claves que sea más seguro.

Esto me desconcertó durante unos 30 minutos.

Seguí este problema y verifiqué la hora local, etc., todo estaba bien.

Desesperado, destruyó el archivo ~/.aws/credentials e inició sesión nuevamente (esencialmente recreando el archivo) y listo, simplemente funciona.

¡Me pregunto por qué arroja este error en absoluto!

EDITAR:
No parece estar relacionado con la clave secreta en mi caso; eran en su mayoría cadenas simples.

+1 en este tema, mi clave comenzó con un = . Regeneraron una clave que solo tenía / y todo estaba bien. Intenté encerrar la clave en " marcas, pero fue en vano.

No es algo que esperaría ver de la AWS CLI.

Agregando al mismo problema aquí, no puedo creer que el / en mi clave haya causado esto. ¡Gracias por el tiempo perdido!

Tuve este problema. Creo que fue el resultado de la instalación inicial de aws cli como usuario root. La resolución parecía ser desinstalar aws cli, eliminar tanto la carpeta .aws en la carpeta de inicio del usuario actual como en la carpeta raíz, y luego ejecutar 'aws configure' nuevamente como el usuario actual.

Experimenté este problema al ejecutar un script bash usando un temporizador systemd en Ubuntu. Al ejecutar manualmente el script con mi usuario, todo funcionó bien. Sin embargo, el temporizador seguiría arrojando el error (SignatureDoesNotMatch). Luego me di cuenta de que (SignatureDoesNotMatch) se produjo para cualquier comando aws que se ejecutara como root y que 'aws configure' no guardaba los nuevos valores proporcionados.

Para resolver el problema, inicié sesión como root 'su -i', cambié a 'cd ~ / .aws /' y eliminé la configuración con 'sudo rm -r credentials', ejecuté 'aws configure' nuevamente y esta vez los nuevos valores fue salvado. ¡A partir de ahí todo volvió a funcionar como se esperaba!

Puede confirmar que este problema aún existe en aws-cli / 1.15.4 Python / 2.7.15rc1 Linux / 4.15.0-42-generic botocore / 1.12.8.

An error occurred (SignatureDoesNotMatch) when calling the <whatever> operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Y resulta que había un + en mi secreto. Me regeneré y todo está bien ahora. ¿Cuándo podemos esperar una solución para esto @jamesls? ¿O hay algo que pueda hacer para ayudar?

Enfrenté lo mismo en mi aws cli porque la clave secreta contenía + ... (como se describe arriba) Después de regenerar una nueva clave ... (como vi en el comentario de delmartechdude arriba) .... el problema sido resuelto.

Mis dos centavos. Me estaba dando este error porque estaba tratando de cargar contenido a s3 con transferencias aceleradas de esta manera (solía funcionar en el pasado): --endpoint-url http://imaat.s3-accelerate.amazonaws.com ( --endpoint-url http://<bucket-name>.s3-accelerate.amazonaws.com ) como se especifica en las propiedades del punto final de aceleración :

Siguiendo las instrucciones en los documentos oficiales: https://docs.aws.amazon.com/es_es/AmazonS3/latest/dev/transfer-acceleration-examples.html Reemplacé esa última parte con: --endpoint-url http://s3-accelerate.amazonaws.com y ejecuté el comando aws configure set s3.addressing_style virtual para construir el nombre de host dinámicamente. Verificar: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#addressing -style

No sé por qué, pero ahora funciona. Mi nombre de depósito ("imaat") no tiene ningún carácter especial que pueda provocar fallas en el DNS, pero falló por alguna razón con las últimas actualizaciones de cli.

Agregar un perfil a través de la edición de texto y obtuve este error. Actualización de la identificación de acceso al perfil y el secreto a través de un conjunto de configuración de aws y funcionó. Esto es para un secreto con '+' y aws-cli / 1.16.23 Python / 2.7.15 Windows / 10 botocore / 1.12.13

@ dave-miles Estás en algo, ¡gracias por comentar! Estoy ampliando su hallazgo a continuación:

Me encontré con este problema con algunas imágenes de la ventana acoplable. Originalmente estaba usando un ADD en el dockerfile para agregar el archivo ~ / .aws / credentials en el contenedor.

Si hiciéramos esto, nos encontraríamos con el error SignatureDoesNotMatch al intentar descargar desde s3.

Eliminé la línea ADD en el dockerfile, la reconstruí y lancé un nuevo contenedor de la ventana acoplable. En este nuevo contenedor, ejecuté manualmente aws configure set aws_access_key_id <access key id goes here> y aws configure set aws_secret_access_key <secret access key goes here> Esta fue la primera vez que ingresé la información de las credenciales en este contenedor (es decir, el contenedor era una imagen centos "nueva").

Después de usar los comandos aws configure set , pude descargar con éxito desde s3.

Para cualquiera que use esto con un dockerfile, puede usar declaraciones RUN en el dockerfile para ejecutar los dos comandos o puede usar una declaración ADD para enviar un script a su contenedor docker:

#! / bin / sh

aws configure set aws_access_key_id _acceso-clave-id-va-aquí_
aws configure set aws_secret_access_key _secret-access-key-va-here_

Tuve el mismo problema que @villasenor : un + en la clave secreta causaría el error al configurar el awscli usando env vars en la ventana acoplable. rotar las teclas solucionó el problema.

Lo mismo ocurre aquí, pero no hay caracteres especiales en la clave de acceso o la clave secreta.
Se volvió a generar un nuevo conjunto para el mismo usuario de IAM, y los nuevos pueden enumerar depósitos, los antiguos no.

Esto ocurrió con las llamadas de AWS cli y Java SDK. Sugerir que la culpa no está en los clientes ...

Ambos sets aún están en vivo. Si alguien en Amazon quiere más detalles, póngase en contacto.

Mi compañero de trabajo acaba de encontrar esto también. Intenté depurar creando una clave de acceso hasta que obtuve una con un + o / al principio. Sin embargo, no pude reproducir.

Tuve una experiencia de compañero de trabajo de esto. Determinamos que esto ocurre específicamente en Ubuntu 18.04 con + o / en la clave secreta.

Recibí el mismo error hoy, actualmente usando Windows 10. Sin embargo, cuando uso la misma clave de acceso en otra computadora portátil (mac), funciona bien para mí. Luego probé la clave de acceso dentro de WSL, que también está bien. No estoy seguro del motivo y no hay ningún carácter especial en la tecla aws.

Tengo este error con un conjunto de claves de acceso y no con el otro.
Como se mencionó en varias otras publicaciones, aquí mi clave como '/' en ella. Para mí, este problema parece un problema simple de que el servidor o los clientes codifican / decodifican usando el estándar de codificación RFC URI y el otro no lo usa.
Planeo ejecutar estos scripts de prueba mencionados e intentar reproducir los errores.

Para otras personas aquí, encontré el error, pero tenía credenciales incorrectas almacenadas en la memoria caché de mi carpeta ~ / .aws. Primero busca allí y en segundo lugar a las variables de entorno.

Estoy experimentando esto en Windows 10 usando Git Bash. Funciona bien con Powershell. La invocación de Python es obviamente diferente, pero es el mismo módulo de Python y Python. También tengo + y / en mi clave.

Acabo de tener este problema y, para mí, la solución fue eliminar los espacios. ejemplo.
en lugar del predeterminado de:
[profilename]
aws_access_key_id = MYAWSACCESSKEYID
aws_secret_access_key = MYAWSSECRETACCESKEY
Lo cambié a:
[profilename]
aws_access_key_id=MYAWSACCESSKEYID
aws_secret_access_key=MYAWSSECRETACCESKEY

tenga en cuenta la falta de espacios alrededor de =. Esto lo arregló para mí y tengo + y / en mi clave también por cierto.

Todos, aquí hay algunos consejos increíbles para la resolución de problemas. Los convertiré en una página en la sección Solución de problemas de la Guía del usuario de CLI. ¡Gracias por las contribuciones!

Hola a todos,

Puedo ver que hay muchas respuestas aquí, pero para mí fueron los caracteres especiales en la clave de acceso secreta de AWS. El mío comenzó con "= +", pero cuando generé uno nuevo sin caracteres especiales desde la consola web, comenzó a funcionar de inmediato.

Estoy ejecutando awscli en un shell Zsh en Ubuntu en Windows:

jonathan<strong i="8">@SurfaceBook</strong>  ~  aws --version aws-cli/1.16.216 Python/2.7.12 Linux/4.4.0-17134-Microsoft botocore/1.12.206

Espero que esto sea útil para otros.

Gracias
Jonathan

Acabo de sumergir 4 horas de depuración en esto hasta que encontré este hilo. Podría usar el cli s3 localmente sin ningún problema, pero al ejecutarlos en circleci recibí este error: SignatureDoesNotMatch ..

Como otros han sugerido, mi clave de acceso secreta contenía un carácter + , y después de generar una nueva clave, todo comenzó a funcionar.

Casi hubiera sido imposible depurar sin este hilo

Gracias @blbradley . Fue exactamente el problema que tuve.

tenía el mismo problema: la solución era eliminar las variables de entorno de Windows con credenciales de AWS obsoletas

Yo también tuve el problema en Python3 boto3.
El mío comienza con =/

Estoy en una máquina virtual que hace que la hora y la región del host sea similar a la hora y la región del invitado y resuelve el problema.

Solo quería comentar que esto también me golpeó hoy en una clave recién creada, y después de mucha frustración, llegué aquí y vi una mención de / en la clave. Efectivamente, ese era el problema: la nueva clave sin ella funciona. ¡¿Wtf ?!

No puedo creer que este problema se abrió en 2014 y aún no hay solución para él, este error me obligó a crear un nuevo conjunto de credenciales de AWS para mí, incluso intenté codificar el '/' pero no funcionó :(

Eliminar la credencial con "/" solucionó el problema. Gracias a todos por señalar esto.

Solo golpea esto en 2020 ahora. La clave secreta tiene un '+'.

aws-cli - desarrollado por el proyecto aws - falla con claves válidas de aws ... ¿por 6 años?

Mismo problema en enero de 2020. La clave secreta tiene un carácter de barra "/".

Genere un nuevo conjunto de credenciales, usando la consola de AWS IAM, y me aseguré de que la clave secreta fuera alfanumérica, no "/" no "+" y así sucesivamente. Reemplacé mi antigua clave secreta con la nueva clave secreta, en mi archivo ~ / .aws / credentials, luego lo intenté.

Esto lo resolvió.

El mismo problema aquí en 2020. Pero no puedo eliminar ningún carácter alfanumérico, ya que son parte de mis credenciales, y no tengo el control de eso.

Simplemente regenere la credencial hasta que se deshaga de los personajes. Por lo general, solo se necesitan uno o dos intentos más.

Maurice

De: columb1a [email protected]
Enviado: martes 21 de enero de 2020 1:47 p.m.
Para: aws / aws-cli [email protected]
Cc: Maurice Bizzarri [email protected] ; Comentario [email protected]
Asunto: Re: [aws / aws-cli] Error SignatureDoesNotMatch (# 602)

El mismo problema aquí en 2020. Pero no puedo eliminar ningún carácter alfanumérico, ya que son parte de mis credenciales, y no tengo el control de eso.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faws%2Faws-cli%2Fissues%2F602%3Femail_source%3Dnotifications % 26email_token% 3DAAAXXM3CF63PVTWMVHJN2FTQ65UMRA5CNFSM4ALOPGL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRMFFA% 23issuecomment-576897684 y datos = 02% 7C01% 7Cmaurice% 40bizzarrisoftware.com% 7Cf6f2e8a571954134b76b08d79ebb6bee% 7C9aa15552370449f5ac56c2850c165d32% 7C1% 7C0% 7C637152400117352225 y sdata = 2Z6PQRSvKD0P8Eu0yrs15Ypi6GgtFvaDi7qewAq5yH4% 3D y reservado = 0 , o darse de baja https://nam04.safelinks.protection.outlook.com /?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAAXXM34MIXB32H3RMQL2FTQ65UMRANCNFSM4ALOPGLQ&data=02%7C01%7Cmaurice%40bizzarrisoftware.com%7Cf6f2e8a571954134b76b08d79ebb6bee%7C9aa15552370449f5ac56c2850c165d32%7C1%7C0%7C637152400117362212&sdata=53%2F78BXqn3FRxlkfzXYHnJPEEbs7Ta1XmJhW%2BZdBjXo%3D&reserved= 0 .

Primero encontré problemas de tiempo de espera y después de actualizar mi awscli encontré este problema. Pensaste que 6 años es suficiente para que funcione ...

también estoy implementando esta aplicación Vue.js a través de gitlab en el bucket de AWS S3, ¿alguien puede decirme qué hacer?
msg: error

No tenía caracteres no alfanuméricos, pero trabajar con perfilado no funcionó, para un solo perfil. Regeneré las credenciales usando la consola y las nuevas simplemente funcionaron.

Obtener tales errores también hoy, y regenerar las credenciales sin caracteres especiales ('+' o '/') funciona para mí.

Sigo teniendo el mismo problema, pero sucede de repente, trabajo con operaciones Get y Put y una funciona, la otra no. y sí, mi clave secreta no contiene ningún carácter especial. ¿alguna ayuda? Primero llamo a getIntent (API de modelos de amazon lex) para recuperar la suma de comprobación de intenciones, luego llamo a putIntent para actualizar esa intención. El método Get funciona (no todo el tiempo) pero el método put parece tener el mismo problema de firma, mientras que si eliminé la API del método Get del código, el método Put funciona 2 de cada tres veces.

Tuve este problema, te sugiero que generes nuevas claves
y vuelva a configurar su perfil de AWS

aws configure

ID de clave de acceso de AWS [ * * * * QD5E]: AWS_ACCESS_KEY_ID
Clave de acceso secreta de AWS [ * * * * ANjA]: AWS_SECRET_ACCESS_KEY
Nombre de región predeterminado [eu-west-3]: AWS_REGION
Formato de salida predeterminado [json]: OUTPUT_FORMAT

Hola !

Recibo el mismo problema cuando uso una URL firmada previamente que se devuelve a mi cliente
La URL se genera en el servidor (por tiempo limitado). El servidor es Python y no veo ningún error allí, pero el cliente es JS, solo obtiene la URL y la abre. Parte de la URL son credenciales generadas para este recurso)

El error está encendido y apagado, así que creo que está relacionado con lo que se dice aquí sobre las claves especiales en las credenciales, pero como estoy usando credenciales generadas en el servidor, ¡no puedo cambiarlas!

¿Alguna forma de solucionar esto en el código? analizar las claves especiales de alguna manera?

Hola !

Recibo el mismo problema cuando uso una URL firmada previamente que se devuelve a mi cliente
La URL se genera en el servidor (por tiempo limitado). El servidor es Python y no veo ningún error allí, pero el cliente es JS, solo obtiene la URL y la abre. Parte de la URL son credenciales generadas para este recurso)

El error está encendido y apagado, así que creo que está relacionado con lo que se dice aquí sobre las claves especiales en las credenciales, pero como estoy usando credenciales generadas en el servidor, ¡no puedo cambiarlas!

¿Alguna forma de solucionar esto en el código? analizar las claves especiales de alguna manera?

@ maya-harel puede cambiar las credenciales de IAM -> los usuarios seleccionan el usuario que ha creado y vuelven a generar la pestaña de credenciales de seguridad de clave secreta.

Además, el tiempo en el código es realmente fatal, para cada solicitud que realice en el back-end, obtenga el tiempo actual para usarlo en el encabezado para generar la firma.

Por otro lado, ha habido muchas sugerencias ciegas de "regenerar sus credenciales de IAM" para los usuarios que han dicho explícitamente que no es una opción para ellos.

Esto no es útil para los usuarios y distrae del hecho de que se trata de un error conocido que sigue afectando a los usuarios de aws-cli que intentan utilizar credenciales de IAM válidas.

Me encontré con esto también.
$ aws --versión
aws-cli / 1.16.300 Python / 2.7.16 Linux / 4.14.152-127.182.amzn2.x86_64 botocore / 1.13.36

Mis claves son completamente alfanuméricas, sin caracteres especiales.

Las claves funcionan desde el shell, sin embargo, cuando se utilizan a través de Jenkins en un destino Makefile, se produce este error. No estoy seguro de lo que está sucediendo aquí.

Mi clave secreta tiene / y + en ella. Me encontré con este problema y lo he intentado:

• A través de aws-cli > aws iam get-user (usando el archivo ~/.aws/credentials )
• boto3 (a través de Python 3.6.8)
  
  
  
  • Claves codificadas
  
  
  • Variable de entorno
  
  
  • Argumento boto3.Session(profile_name=PROFILE) (que se extrae de ~ / .aws / credentials)
  
  

Todos estos dan como resultado el error SignatureDoesNotMatch .

Actualmente no puedo regenerar la clave.

Lo que no entiendo es que puedo usar el Protocolo S3 en Cyberduck (https://cyberduck.io/) y funciona como se esperaba. ¿Cómo es posible?

Este tiene que ser uno de los errores más frustrantes que he encontrado y es una locura que no se haya solucionado. Obtener una credibilidad sin un "+" funcionó para mí en CircleCI.

¿Sigue chocando? enfrentando el mismo problema, wow no puedo ser posible ...

Sí, es frustrante. Mi clave secreta que tenía un + no funcionó en una tubería de Jenkins, pero cuando generé una nueva, que solo tenía unos pocos de / , funcionó bien.

Tuve este problema en la versión de paquete instalado de awscli en Ubuntu 16.04. Lo arreglé instalando awscli como un paquete pip de python.
Para obtener instrucciones, siga este enlace en la sección Instalación de AWS CLI con Python PIP

_ Problema encontrado _

1) Se encontró el error clave de acceso
2) El registro de errores parciales es el que se proporciona a continuación.

$ python SetupAWS.py list_things
Rastreo (llamadas recientes más última):
Archivo "SetupAWS.py", línea 222, en
list_things ()
Archivo "SetupAWS.py", línea 182, en list_things
cosas = cliente.lista_cosas () ['cosas']
Archivo "c: Archivos de programa (x86) Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", línea 316, en _api_call
return self._make_api_call (nombre_operación, kwargs)
Archivo "c: Archivos de programa (x86) Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", línea 626, en _make_api_call
subir error_class (parsed_response, operation_name)
botocore.exceptions.ClientError: Se produjo un error (InvalidSignatureException) al llamar a la operación ListThings: La firma de solicitud que calculamos no coincide con la firma que proporcionó. Verifique su clave de acceso secreta de AWS y el método de firma. Consulte la documentación de servicio para obtener más detalles.

_ Análisis de causa raíz _

1) Como sugirieron muchos en sus comentarios anteriores, la presencia de "+" en mi clave de acceso secreta resultó en el error anterior.

_ Resolución _

1) Se generó una nueva clave de acceso como usuario de IAM y se verificó que la nueva clave de acceso secreta no contiene un "+" dentro de la cadena.
2) Ejecutó el comando aws configure y proporcionó los nuevos valores.
3) Ejecuté el comando

$ python SetupAWS.py list_things
[{'thingName': 'myThingName', 'thingArn': 'myThingArn', 'atributos': {}, 'versión': 1}]

Este número ha estado abierto durante seis años y les agradezco su paciencia, perseverancia y la información que me han proporcionado. Se han identificado algunas causas subyacentes a través de sus comentarios (https://github.com/aws/aws-cli/issues/602#issuecomment-520469209) y se han compilado en el capítulo Errores de solución de problemas de la Guía del usuario de la línea de comandos. Estas causas incluyen la desviación del reloj y algunos sistemas operativos manejan mal las teclas con caracteres especiales.

Intenté reproducir esto usando varios entornos diferentes. Usé Ubuntu 16.04, Ubuntu 18.04 y Amazon Linux 2, con Python 3.6.8 y 3.8.3. Si bien muchos comentaristas usaron Python 2, no intenté reproducirlo porque ya no es compatible. Usé la última v1 aws-cli (1.18.80 en el momento de escribir este artículo), así como una versión anterior (1.11.78) a la que se hace referencia en este número. Usé el script provisto (https://github.com/aws/aws-cli/issues/602#issuecomment-281866173) por SignatureDoesNotMatch . Recibí errores ocasionales AuthFailure en el comando describe-instances, pero un reintento del comando con las mismas credenciales funciona correctamente.

La gran cantidad de comentarios dificulta que los nuevos usuarios que se acercan a este problema encuentren solicitudes de nuestro equipo de desarrolladores para sugerencias de solución de problemas. Para ayudar a nuestro equipo y a la comunidad a determinar la causa de este error, estoy cerrando este problema y creando una plantilla de problema de GitHub específica que incluye orientación y requisitos de comentarios para los usuarios que encuentran este error.

Si encuentra este error, diríjase a la pestaña de problemas, haga clic en el botón "Nuevo problema" y use la plantilla para un informe de error SignatureDoesNotMatch (o use el enlace a continuación).

Debido a la variación de los entornos de usuario donde se produce este error, presente un problema por separado en lugar de comentar uno existente.

Haga clic aquí para presentar un informe de error SignatureDoesNotMatch