EDIT : Si vous rencontrez ce problème, nous vous serions reconnaissants de nous aider à résoudre les problèmes. Je mets à jour ce commentaire pour une meilleure visibilité sur les étapes de dépannage.

Dépannage

La première étape pour résoudre ce problème consiste à déterminer si le problème est lié aux informations d'identification elles-mêmes ou à la CLI. Pour tester cela, essayez d'utiliser ces informations d'identification dans d'autres kits SDK AWS (javascript, ruby, java, etc.). Pour vous aider, j'ai créé un script de test qui utilise le kit AWS SDK pour python et javascript qui est disponible ici : https://github.com/jamesls/aws-creds-test . Après le clonage, exécutez simplement make install , make test . Il vous demandera des informations d'identification (similaires à la CLI) et effectuera un appel API à 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.

Pour les personnes rencontrant ce problème, veuillez exécuter le script de test et partager le résultat.

Cela devrait nous donner une meilleure idée de l'origine de ce problème :

• Si le script ci-dessus réussit à la fois pour python et javascript mais échoue lors de l'utilisation de l'interface de ligne de commande, il s'agit probablement d'un problème d'interface de ligne de commande.
• Si le script échoue pour python mais passe pour javascript, il s'agit probablement d'un problème avec botocore (que la CLI utilise).
• Si le script ci-dessus échoue à la fois pour python et javascript, il s'agit probablement d'un problème avec les informations d'identification réelles.

Merci d'avance à tous ceux qui pourront nous aider à résoudre ce problème. Faites-moi savoir s'il y a des questions.

C'est à ça que ça ressemble:

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

Des mises à jour sur ce problème? Je rencontre également cette erreur et mon fichier d'informations d'identification n'a pas changé.

J'ai un problème similaire. Le plugin Jenkins s3 est capable de mettre un objet en utilisant mes informations d'identification, mais aws-cli me donne les erreurs ci-dessous.

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.

Je rencontre le même problème. Si je crée un secret, cela me donne une erreur différente (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

Cela m'arrête complètement. Je peux faire certaines choses avec les utilitaires ec2-blah-stuff en spécifiant des certificats x509, mais l'aide dit que c'est obsolète, donc je ne veux pas en dépendre. Toute aide au dépannage ou quoi que ce soit serait vraiment appréciée.

La première étape serait de s'assurer que vos clés d'accès/secrètes sont réellement valides. Quelques trucs à essayer :

• Ces mêmes informations d'identification de clé d'accès/secret fonctionnent-elles avec d'autres outils ? (Le SDK java/javascript/ruby/python ?)
• D'autres commandes que "aws s3" fonctionnent-elles pour vous ? « aws ec2 describe-instances » génère-t-il toujours des erreurs d'authentification ?

Ils ne fonctionnent pas avec d'autres outils (ec2-describe-instance par exemple).

Je pense que j'ai les droits appropriés puisque l'utilisation des certs fonctionne. Pour m'assurer qu'il ne s'agit pas d'un poste de travail, j'ai créé une instance Amazon Linux et j'utilise la version awscli qui l'accompagne, mais j'obtiens le même message.

Aussi un problème pour moi. Je l'utilise dans un conteneur Docker, construit avec le même Dockerfile.
Cela fonctionne bien lorsqu'il est construit sur un EC2, mais ne fonctionne pas lorsqu'il est construit localement sur une boîte de vagabond coreos.

Il semble que le problème concerne les informations d'identification elles-mêmes. J'ai vérifié cela et je ne suis pas en mesure de reproduire ce problème. Vérifiez les informations d'identification sur la page des informations d'identification de sécurité . Si quelqu'un peut fournir un ensemble exact d'étapes qui démontrent le problème, je serais heureux d'y jeter un autre coup d'œil.

Cela vient de m'arriver et était le résultat d'un temps système trop décalé, même s'il ne l'a pas signalé. Exécuté ntpdate contre pool.ntp.org et a résolu ce problème pour moi.

Si vous obtenez cette erreur lorsque cred est configuré à l'aide de la variable env, essayez sudo

Si vous êtes dans une machine virtuelle, assurez-vous que l'heure du système d'exploitation hôte correspond à l'heure du système d'exploitation invité. Si ce n'est pas le cas, vous obtiendrez l'erreur que vous avez décrite.

Une erreur très similaire se produit pour moi avec de bonnes informations d'identification, tout en répertoriant un compartiment contenant _beaucoup_ de clés. Voici l'erreur :

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.

Voici ma sortie 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

Notez que ces informations d'identification fonctionnent correctement avec d'autres invocations aws , et en fait cette opération list s'exécute pendant une longue période (plus d'une heure) avant de renflouer avec cette erreur. J'ai un fichier avec plus de 82 000 lignes de sortie de la commande qui a finalement échoué.

J'ai eu ce problème, et si je mets simplement mon script en veille pendant une seconde et que je réessaye, il passe. C'est presque comme s'il était étranglé et renvoyait la mauvaise erreur ou quelque chose du genre.

Je peux aussi signaler ce problème. En essayant de télécharger un fichier de 11 Go à l'aide d'aws cp foo s3://mybucket/foo/bar, j'obtiens diverses erreurs telles que :

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.

et

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)

J'ai vérifié que l'heure de mon système est correcte. J'ai également remarqué une lenteur considérable (au niveau du délai d'expiration des requêtes http) sur le même système lors du téléchargement, il s'agit donc d'un problème de limitation qui semble raisonnable. Cela fonctionne également très bien pour télécharger de petits fichiers avec les mêmes informations d'identification et en utilisant la console Web à partir de la même machine, cela semble donc être un problème aws-cli.

Cela m'est arrivé aussi avec aws-cli 1.5.5, la mise à jour d'aws-cli vers 1.6.2 l'a résolu.

Cela m'arrive avec la 1.6.2

Cela m'est arrivé aujourd'hui. C'est nouveau pour moi. J'utilise awl-cli depuis quelques mois sans problème et aucun changement dans les informations d'identification 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

Je pense que ce problème est désormais résolu via https://github.com/boto/botocore/pull/388 et sera disponible dans la prochaine version de l'AWS CLI.

@jamesls confirmé corrigé sur la version awscli 1.6.4 . J'utilisais 1.5.4 . Merci!

Je reçois ce problème sur un nouveau système Ubuntu.

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.

aws-cli installé via 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)

Des idées sur la façon de le réparer?

Ma solution consistait à dormir quelques secondes, puis à réessayer, mais cela
On dirait qu'il peut y avoir une mise à jour de l'outil qui le résout également.

Le mardi 2 décembre 2014 à 03h38, Mark Wolfe [email protected] a écrit :

Je reçois ce problème sur un nouveau système Ubuntu.

Une erreur client (SignatureDoesNotMatch) s'est produite lors de l'appel de l'opération PutObject : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. Vérifiez votre clé et votre méthode de signature.

aws-cli installé via pip

$ liste de pips
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)
charret (2.0.1)
Guépard (2.4.4)
cloud-init (0.7.5)
colorama (0.2.5)
configobj (4.7.2)
documents (0.11)
html5lib (0,999)
httplib2 (0.8)
Jinja2 (2.7.2)
jmespath (0.5.0)
jsonpatch (1.3)
jsonpointer (1.0)
Paysage-Client (14.01)
MarkupSafe (0.18)
mercuriel (2.8.2)
serment (1.0.1)
PAM (0.4.2)
Oreiller (2.3.0)
pépin (1.5.4)
jolie table (0.7.2)
pyasn1 (0.1.7)
pycrypto (2.6.1)
pycurl (7.19.3)
Pygment (1.6)
pyinotifier (0.9.4)
pyOpenSSL (0.13)
pysérie (2.6)
python-apt (0.9.3.5)
python-dateutil (2.3)
python-debian (0.1.21-nmu2ubuntu2)
PyYAML (3.10)
demandes (2.2.1)
romain (2.0.0)
rsa (3.1.2)
outils de configuration (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)

Des idées sur la façon de le réparer?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/aws/aws-cli/issues/602#issuecomment -65198065.

@wolfeidau et ouais j'ai parlé trop tôt. Le pip awscli installé localement renvoie à nouveau les erreurs SignatureDoesNotMatch. Aïe !

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'

Ce problème se produit-il uniquement lorsqu'une demande est retentée ? Ou cela se produit-il chaque fois que vous exécutez la commande deregister-instances-from-load-balancer ?

@jamesls ça arrive à chaque fois maintenant :(

Je sais que ce problème est fermé, mais je voulais partager que vous pouvez voir cette erreur lors de l'exécution dans une machine virtuelle qui hiberne. Dans de tels cas, l'horloge système ne rattrape pas systématiquement son retard si vous utilisez Ubuntu. Il suffit de mettre à jour l'heure à corriger (c'est-à-dire sudo ntpdate -s time.nist.gov).

bonjour, y a-t-il une solution définitive à ce sujet?

+1

En utilisant la version 1.7.8 de la CLI, je voyais la même erreur SignatureDoesNotMatch en essayant ce qui suit :
$ aws iam list-users

Et obtenir un AuthFailure pour ceci :
$ aws ec2 describe-security-groups

Après avoir supprimé mes clés et essayé de nouvelles, les deux commandes fonctionnent.

C'est l'ancienne clé d'accès secrète qui a peut-être été la cause de mes problèmes, notez les caractères pour cent, plus et barre oblique : H2J7/oT3Fib15SwFVB1s3EnTCmg+SC7wF7qoP+dw%

:+1: @gsterndale. Ma clé d'accès contenant % n'a pas fonctionné. J'ai dû générer de nouvelles clés.

J'ai également rencontré ce problème à plusieurs reprises. Chaque fois que je régénérais la clé jusqu'à ce que j'en obtienne une sans aucun caractère spécial (en particulier, j'avais des problèmes avec le signe + dans le secret) le réparait.

À vrai dire, tous mes problèmes de clé de signature ont disparu lorsque je suis passé de l'exécution de la commande sur une machine Ubuntu au lieu d'une installation locale de homebrew mac.

Je suis très nouveau sur AWS, j'ai tout de suite fait face à ce problème sur le nœud js

              ^

SignatureDoesNotMatch : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. Vérifiez votre clé d'accès secrète AWS et votre méthode de signature. Consulter le s
la documentation de vice pour plus de détails.

La chaîne canonique pour cette demande aurait dû être
'PUBLIER
/

hôte : e-mail.us-west-2.amazonaws.com
x-amz-content-sha256:89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39
x-amz- date : 20150809T053346Z

hôte;x-amz-content-sha256;x-amz-date
89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39'

Le String-to-Sign aurait dû être
'AWS4-HMAC-SHA256
20150809T053346Z
20150809/us-west-2/ses/aws4_request
0b908b0248bae550b814b37629a418707742416377816b5a5e78e1897b72293e'

+1

J'ai ce problème pour toutes les commandes aws s3 (awscli 1.8.6 sur ubuntu 14.04 LTS).
Existe-t-il des solutions connues ? J'ai essayé de supprimer mon fichier d'informations d'identification et d'exécuter aws configure, de redémarrer, de réinstaller awscli.

@mcobzarenco , as-tu essayé de nouvelles clés ?

@gsterndale J'ai vu le commentaire ci-dessus à propos d'avoir des barres obliques dans les anciennes clés, mais ce n'est pas le cas et mes clés ont été récemment générées (en juin 2015). Je n'ai ce problème que sur AWS Ubuntu 14.04 LTS. Sur mon ordinateur portable (14.04), awscli (même version) fonctionne bien.

@mcobzarenco Je ne pense pas que ce soit l'âge des clés, mais plutôt les caractères spéciaux qu'elles

vient de rencontrer ce problème sur Ubuntu. Lorsque j'ai entré les clés via cli, il les a stockées dans ~/.aws/config, mais a supprimé le caractère '+'. L'édition manuelle du fichier pour ajouter le '+' m'a permis de me connecter.

@gsterndale Merci pour le conseil, je peux confirmer que la génération d'une nouvelle clé qui ne contient pas + fonctionné pour moi. La solution de @stebl est sympa s'il n'est pas pratique de remplacer les clés.

J'ai rencontré le même problème lors de l'utilisation d'AWS SDk avec node js. Pour résoudre ces problèmes, j'ai suivi exactement les mêmes étapes mentionnées ici
http://aws.amazon.com/developers/getting-started/nodejs/

Je pense qu'AWS SDK est développé avec une version particulière de node js, une incompatibilité dans node js entraînera des problèmes comme celui-ci.

J'ai le même problème et oui, il a été résolu en utilisant une clé sans symboles spéciaux (le + dans mon cas spécifique)

Nous avons rencontré cette erreur (où une machine pouvait décrire des instances à l'aide d'awscli mais l'autre avait une erreur d'accès refusé avec la même clé d'accès. Sur cette dernière machine, iam list-users a donné cette erreur SignatureDoesNotMatch). Résolu en corrigeant l'heure de l'horloge système sur la machine avec le problème.

Comme @tukaaa l'a dit, il y a un bogue si la clé d'accès secrète contient un caractère non alphabétique (comme +). Je pense qu'une mauvaise évasion quelque part ;-(

@ebuildy Pouvez-vous confirmer sur quelle version de la CLI vous voyez cela ( aws --version ) ? S'il s'agit d'une version raisonnée de la CLI, j'irai de l'avant et rouvrirai ce problème.

Je reçois ça sur aws-cli/1.9.1 Python/3.5.0 Windows/7 botocore/1.1.8

J'avais le même problème sur une boîte Windows, en utilisant une clé sans aucun caractère non alpha. J'avais vérifié qu'il ne s'agissait pas d'une erreur de copier/coller en utilisant le même tampon de collage sur une autre boîte. La désinstallation/réinstallation de la CLI AWS et la suppression des informations d'identification/fichiers de configuration, puis la réexécution de la configuration aws l'ont corrigé.

Je viens de voir ça sur aws-cli/1.10.3 Python/2.7.10 Darwin/14.5.0 botocore/1.3.25 .

La régénération d'une clé sans caractères spéciaux l'a corrigée. FWIW dans mon cas, le caractère spécial était / et j'utilisais un fichier INI.

Ok réouverture, on va creuser ça.

@Je peux confirmer que j'ai le même problème que @gsterndale décrit.

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

Mais ma clé ne contient aucun symbole spécial.

J'obtiens la même erreur en utilisant le module de nœud s3-cli. Ma clé secrète contient un [ .

J'ai enfin découvert ce qui ne va pas. J'ai accidentellement ajouté plusieurs caractères aux touches. C'est la raison.

J'étais confronté à ce problème avec le scénario suivant ; à la fois sur rhel7 et ubuntu. Je pense que cela a quelque chose à voir avec les caractères non alpha comme d'autres l'ont mentionné

• compartiment s3 protégé pour un seul rôle
• L'instance ec2 avec ledit rôle doit assumer le même rôle avant d'accéder au compartiment s3 protégé

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`

Je crois que quelque chose avec le --query gâchait les informations d'identification. Lors de l'exécution manuelle des commandes et de la copie et du collage des valeurs ; puis en définissant les variables d'environnement, cela semblait bien fonctionner.

J'ai eu le même problème lors de l'exécution d'awscli version 1.10 sur Mac (installé via pip) par rapport à Ubuntu (image Amazon) awscli version 1.2.9. aws configure --profile user produit deux configurations différentes sous chacune. La version 1.10 a produit deux fichiers : config et credentials. La version 1.2.9 vient de produire un fichier de configuration (mais avec les informations d'identification). Lorsque j'ai supprimé les informations d'identification et le fichier de configuration produits par la version 1.10 et copié le fichier de configuration produit par la version 1.2.9, tout fonctionnait, même avec des caractères spéciaux et en exécutant awscli version 1.10. Le fichier de configuration produit par la version 1.2.9 est

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

Peut confirmer que cela est dû à des caractères non alphanumériques.

J'ai le même problème avec une clé secrète contenant un +. Cependant, je ne suis pas le propriétaire du compte S3 et je ne peux pas facilement en créer un nouveau. Quelqu'un a-t-il trouvé une solution autre que la création d'une nouvelle clé sans caractères spéciaux ?

tl;dr Solution : recréez à plusieurs reprises les informations d'identification JUSQU'À CE QUE votre aws_secret_access_key ne contienne PAS de caractères non alphanumériques ... dans mon cas, aws_secret_access_key contenait un + (signe plus)

Je viens de faire une nouvelle installation ... même problème ... c'est sur Ubuntu ... ce n'est pas un problème d'OS local c'est un problème d'API Amazon donc ignorez les autres commentaires qui disent que le fait de quitter OSX le résout

aws ec2 describe-instances

Une erreur s'est produite (AuthFailure) lors de l'appel de l'opération DescribeInstances : AWS n'a pas pu valider les informations d'identification d'accès fournies

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

aws ec2 describe-security-groups

Une erreur s'est produite (AuthFailure) lors de l'appel de l'opération DescribeSecurityGroups : AWS n'a pas pu valider les informations d'identification d'accès fournies

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

aws ecr se connecter

Une erreur s'est produite (InvalidSignatureException) lors de l'appel de l'opération GetAuthorizationToken : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. Vérifiez votre clé d'accès secrète AWS et votre méthode de signature. Consultez la documentation du service pour plus de détails.

La chaîne canonique pour cette demande aurait dû être
'PUBLIER
/

type de contenu
hôte : ecr.us-east-1.amazonaws.com
x-amz- date : 20160615T182955Z
x-amz- target:AmazonEC2ContainerRegistry_V20150921.GetAuthorizationToken

type de contenu;hôte;x-amz-date;x-amz-target
44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a'

Le String-to-Sign aurait dû être
'AWS4-HMAC-SHA256
20160615T182955Z
20160615/us-east-1/ecr/aws4_request
86c2e3c850acd6765a1ca6aa626c6e9a6c85284f3954f45e170f51b5b89961c7'

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

aws iam list-users

Une erreur s'est produite (SignatureDoesNotMatch) lors de l'appel de l'opération ListUsers : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. Vérifiez votre clé d'accès secrète AWS et votre méthode de signature. Consultez la documentation du service pour plus de détails.

La chaîne canonique pour cette demande aurait dû être
'PUBLIER
/

hôte : iam.amazonaws.com
x-amz- date : 20160615T183516Z

hôte;x-amz-date
b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2'

Le String-to-Sign aurait dû être
'AWS4-HMAC-SHA256
20160615T183516Z
20160615/us-east-1/iam/aws4_request
ad9f7581f0bf25ecae56355a6c96b60f3dc3188efbbdb3d0d4806e9f2c5cf8a9'

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

aws --version
aws-cli/1.10.38 Python/2.7.11+ Linux/4.4.0-22-generic botocore/1.4.28

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

cat /root/.aws/credentials
[défaut]
aws_access_key_id = AKIAJ7FCEUVVSGX7KZGQ
aws_secret_access_key = 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

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

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

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

SOLUTION :
Après avoir supprimé et créé de nouvelles informations d'identification
où aws_secret_access_key n'avait PAS de signe plus (+) tout était bien au-dessus des commandes qui ont commencé à fonctionner correctement

J'ai eu le même problème. Recréer les informations d'identification jusqu'à ce que je n'aie plus de caractères spéciaux a fonctionné pour moi.

J'ai découvert que lorsque j'ai copié et collé les informations d'identification, elles avaient des caractères ^M à la fin, ce qui provoquait l'erreur.

Obtenir une clé secrète sans + corrigé pour moi aussi...

Remarque - si vous voyez ce problème sous le docker (boot2docker VM'd), il se peut que l'horloge de la VM ne soit pas synchronisée.
Voir : http://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host

J'ai le même problème. Que faire si je n'ai pas les autorisations pour régénérer les informations d'identification.. des correctifs possibles par d'autres moyens ?

MISE À JOUR : j'ai corrigé cela en exécutant rm -rf .aws/cli/cache/

J'ai aussi ce problème maintenant. Lorsque vous essayez d'assumer un rôle

Version:
aws-cli/1.11.17 Python/2.7.10 Darwin/16.1.0 botocore/1.4.74

Edit : J'ai également essayé de mettre à jour à nouveau maintenant, même problème :
aws-cli/1.11.18 Python/2.7.12 Darwin/16.1.0 botocore/1.4.75

Sortir:

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'

Le même problème existe toujours avec la dernière version (à jour) de l'AWS CLI. Je viens de mettre à niveau mon CLI 1.8.3 vers 1.11.19 - et je n'ai pu exécuter aucune commande avec un nouvel utilisateur/de nouvelles clés que j'ai créées. J'ai dû recycler environ 5 clés avant d'avoir une paire où la clé secrète n'avait aucun caractère non alphabétique. Une fois que je suis tombé sur une telle paire - CLI fonctionne bien.

Très ennuyeux - je souhaite qu'Amazon ne génère pas de clés invalides qu'ils ne peuvent pas traiter .....

@mpopova-yottaa avez-vous essayé de vider complètement le cache awe-cli ? Essayez de supprimer l'intégralité du répertoire ~/.aws (faites une copie de vos fichiers de configuration/d'informations d'identification)

aws ec2 describe-instances s'exécute pour moi, mais lorsque vous essayez de créer une pile de formation de nuages :

```Exception dans le thread "main" com.amazonaws.services.cloudformation.model.AmazonCloudFormationException : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. Vérifiez votre clé d'accès secrète AWS et votre méthode de signature. Consultez la documentation du service pour plus de détails.

La chaîne canonique pour cette demande aurait dû être
'PUBLIER
/

amz-sdk-invocation-id:18d13b66-80ae-f676-c0cf-dbf875edb1aa
amz-sdk- retry:3/345/470
hôte : cloudformation.us-west-1.amazonaws.com
user-agent:aws-sdk-java/1.11.20 Mac_OS_X/10.10.5 Java_HotSpot(TM)_64-Bit_Server_VM/25.91-b14/1.8.0_91
x-amz- date : 20161127T194448Z

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

Le String-to-Sign aurait dû être
'AWS4-HMAC-SHA256
20161127T194448Z
20161127/us-west-1/cloudformation/aws4_request
cb0286a8727afcc465171ab991accde0aaa7210e160a9ba3196e2a5e4305f428' (Service : AmazonCloudFormation ; Code d'état : 403 ; Code d'erreur : SignatureDoesNotMatch ; ID de demande : f52abbd4-b4d9-11e6-b989-d5c3bd50d5e

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 clé secrète ne contient que des caractères alphanumériques, je suis donc bloqué.

@aebrow4 C'est dans le cache pour awe-cli. Essayez de supprimer : .aws/cli/cache/

@cultavix il n'y a pas de cli dans .aws

J'ai eu cette erreur lors de l'exécution de aws glacier upload-archive avec --archive-description "`date`" . Lorsque j'utilise --archive-description "`date +%Y/%m/%d`" cela fonctionne bien, il semble donc y avoir un problème d'échappement.

J'avais un problème similaire :

λ 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.

J'ai essayé de synchroniser l'heure avec un serveur NTP (avec succès), mais cela n'a pas résolu le problème. Régénérer les clés jusqu'à ce que j'aie un jeu sans caractères spéciaux l'a corrigé.

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

J'ai le même problème en utilisant awscli et un exemple de code python (boto3).
Notez que j'utilise IBM Object Storage S3 compatible api, je peux répertorier les buckets et leur contenu mais je ne peux pas télécharger (à la fois pour le code pyhton et cli).
J'ai testé le scénario avec le ruby aws-sdk et ça marche bien (upload/download).
-- configuration
aws-cli/1.2.9 Python/3.4.3 Linux/3.19.0-33-generic

Je viens de commencer à avoir le même problème avec un script que j'utilise depuis des mois pour déposer des téléchargements en plusieurs parties dans Glacier. Peut toujours déposer correctement via aws cli, donc les informations d'identification fonctionnent toujours, mais le script utilisant boto3 échoue avec :

« botocore.exceptions.ClientError : une erreur s'est produite (InvalidSignatureException) lors de l'appel de l'opération InitiateMultipartUpload : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. Vérifiez votre clé d'accès secrète AWS et votre méthode de signature. Consultez la documentation du service pour plus de détails.

aws --version est
aws-cli/1.11.38 Python/2.7.10 Darwin/15.6.0 botocore/1.5.1

(oui, j'ai tout mis à jour en pensant que cela pourrait résoudre le problème... pas de chance.)

obtenir une nouvelle paire de clés sans caractères spéciaux (c'était + dans mon cas) a résolu le problème pour moi

une autre confirmation ici d'un traitement incorrect de + dans la clé secrète.

Bonjour à tous, voici un script que j'ai utilisé pour essayer de reproduire ce problème : https://gist.github.com/jamesls/00ef7fcc0ac39ba8b06956d165c42f6d . Voici ce que fait le script :

• Crée une nouvelle paire access_key/secret_key via aws iam create-access-key dans une boucle jusqu'à ce qu'il trouve des informations d'identification qui ont un caractère + ou / .
• Il crée un nouveau profil "testcreds" avec ces informations d'identification nouvellement générées
• Il essaie d'invoquer diverses commandes AWS CLI pour s'assurer que ces informations d'identification fonctionnent

Il le fait dans une boucle infinie jusqu'à ce qu'un appel d'API échoue. Jusqu'à présent, je n'ai pas réussi à le faire échouer. Les clés secrètes qui ont + et / fonctionnent pour moi.

À ce stade, nous avons confirmé qu'il est certainement possible d'utiliser des clés secrètes qui ont un + ou / donc je ne pense pas que la cause première soit quelque chose d'aussi simple qu'un bogue dans notre code de signature qui casse lorsque + est présent. En relisant les commentaires de ce fil de discussion, il se peut que la façon dont les informations d'identification sont saisies dans le fichier ~/.aws/config ou ~/.aws/credentials soit un problème. Peut-être qu'il y a une chose spécifique à la plate-forme qui modifie les caractères qui contiennent + ou / .

Donc, pour tous ceux qui rencontrent toujours ce problème, ce serait vraiment utile si vous pouviez fournir des informations supplémentaires :

1. Comment obtenez-vous les informations d'identification (copier/coller depuis la console, aws iam create-access-key , fichier CSV depuis la console, etc.) ?
2. Comment configurez-vous la CLI pour utiliser ces informations d'identification ? Exécutez-vous aws configure et saisissez-vous les valeurs lorsque vous y êtes invité ? Faites-vous cela par programmation en exécutant aws configure set ? Modifiez-vous manuellement ~/.aws/config et/ou ~/.aws/credentials ? Définir les différentes AWS_* env vars ?

Des bonus qui seraient encore plus utiles si possible :

1. Si vous utilisez d'autres kits SDK, ces informations d'identification qui ne fonctionnent pas dans l'interface de ligne de commande fonctionnent-elles dans d'autres kits SDK AWS ?
2. Si vous avez un compte de test ou un utilisateur de test IAM, est-ce que l'exécution du script que j'utilise pour tester échoue pour vous ?

Toute information supplémentaire qui pourrait nous aider à reproduire ce problème de notre côté serait formidable.

J'ai toujours ce problème. Pour répondre à tes questions:
Création d'informations d'identification dans la console amazon et copier/coller dans ~/.aws/credentials (édité avec emacs sur un mac)

D'après le dépannage que j'ai effectué jusqu'à présent (et je suis novice en la matière...), la "chaîne canonique" est correcte, mais la "chaîne à signer" est fausse, ayant une dernière ligne différente. C'est-à-dire que lorsque j'imprime la valeur de retour de auth.py string_to_sign, le nombre produit à partir de 'sha256(canonical_request.encode('utf-8')).hexdigest())' est différent du nombre signalé dans l'erreur renvoyée "The String -to-Sign aurait dû être".

Il n'y a pas de caractères spéciaux dans mes informations d'identification, et cela fonctionne lorsque vous utilisez d'autres outils, par exemple CrossFTP (que je ne veux pas utiliser !!!)

Toute idée serait grandement appréciée !!

@ samato88 qui semble être un problème différent là-bas. Si vous pouviez partager des informations de débogage (en veillant à supprimer toutes les informations sensibles), cela aiderait.

Le string_to_sign n'est pas influencé par le secret_access_key. Lorsque nous signons une requête, nous prenons la requête HTTP que nous sommes sur le point d'envoyer, la convertissons en une chaîne (c'est-à-dire la chaîne ot sign), puis en utilisant la clé secrète, nous signons cette chaîne avec la clé secrète (en sautant quelques détails ici). Ainsi, tout problème avec la chaîne à signer serait distinct de ce problème.

Pourriez-vous ouvrir un autre numéro et fournir la sortie --debug (ou inclure la demande complète et le message d'erreur du service) ? Nous serions heureux d'étudier cela pour vous.

Merci jamesls - j'ai ouvert un sujet séparé à l'adresse :
https://github.com/aws/aws-cli/issues/2474

Toutes les idées sont très appréciées.

Si l'heure de votre système est décalée de plus de 5 minutes, vous ne pourrez pas utiliser la CLI

cours... sudo ntpdate -s time.nist.gov

puis réessayez

J'ai eu le même problème, ma clé secrète contient le signe "+". J'ai supprimé mon fichier .aws/credentials et réexécute aws configure. Après cela, ma requête à la file d'attente sqs pour recevoir le message a fonctionné.

Merci @AlexParra03 . J'ai eu le même problème et vos commentaires m'ont aidé à le résoudre.... :-)

@robotzero vous souvenez-vous de la façon dont vous avez entré vos informations d'identification ? Avez-vous exécuté aws configure puis copié/collé les valeurs de la console Web ?

Oui, j'ai exécuté aws configure et j'ai copié-collé les valeurs.

Oui, j'avais un + dans mon secret, ce qui provoquait toujours cette erreur. La création de nouvelles clés sans caractères spéciaux a résolu le problème.

aws --version
aws-cli/1.11.78 Python/3.6.1 Darwin/15.6.0 botocore/1.5.41

Avait un + et un / dans mon secret. Les secrets sans ceux-ci ont résolu le problème pour moi.

J'ai également eu ce problème.

$ 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

Avait un "+" dans les informations d'identification. A été résolu en régénérant la clé d'accès sans eux. Remarque : "/" est un bon caractère à avoir.

@adityanatraj @shwetapurushe @damienrj pouvez-vous tous répondre à ces questions ici ? À ce stade, nous essayons d'obtenir plus d'informations sur votre environnement et sur la manière dont vous saisissez les informations d'identification. Comme mentionné dans ce commentaire, générer une clé secrète avec + ne reproduira pas le problème pour nous, il est donc probablement lié à une combinaison de votre environnement et/ou de la façon dont vous entrez les informations d'identification.

En d'autres termes, nous avons besoin de plus d'informations de la part des gens pour pouvoir dépanner ce qui se passe.

@jamesls

1. Comment ai-je obtenu les identifiants ?

J'ai obtenu les informations d'identification en les copiant à partir de la console Web.

1. Comment configurer la CLI pour les utiliser ?

J'ai créé manuellement les deux fichiers :

~/.aws/config

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

~/.aws/identifiants

[default]
aws_access_key_id = ACCESS_KEY_HERE 
aws_secret_access_key = SECRET_ACCESS_KEY_THAT_BREAKS_WITH_A_+_SIGN

Désolé, je ne peux pas aider avec les questions bonus car j'ai purgé mes clés d'accès contenant des signes '+', donc le problème n'apparaît pas.

@adityanatraj merci, chaque

La prochaine étape qui nous aiderait à résoudre les problèmes consiste à déterminer s'il s'agit d'un problème lié uniquement à la CLI ou d'un problème lié aux informations d'identification elles-mêmes. Pour tous ceux qui rencontrent toujours ce problème, il serait très utile que vous essayiez ces informations d'identification dans d'autres kits SDK AWS. Pour vous aider, j'ai rassemblé un exemple de référentiel/script qui facilite les choses si vous ne voulez pas le configurer vous-même : https://github.com/jamesls/aws-creds-test . Il suffit de cloner le référentiel et d'exécuter 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.

Pour les personnes rencontrant ce problème, veuillez exécuter le script de test et partager le résultat.

Cette même exception m'est arrivée sur une requête PutObject (C#), chaque fois que les métadonnées de l'objet avaient des caractères Unicode.

J'ai eu le même problème. Les nouvelles clés secrètes avec + et / ne fonctionnent pas. J'ai généré de nouvelles clés sans ces caractères et elles fonctionnent bien.
Votre script de test est pour Linux et j'utilise Windows.
J'ai collé mes informations d'identification à l'aide de Control-C et Control-V à l'aide du shell Windows et de _aws configure_
et j'utilisais seulement _aws cp_

Testé cela aussi, et cela fonctionne bien tant que la clé secrète n'a pas de symboles, comme mentionné ci-dessus.

J'espère voir ce problème résolu bientôt, c'est pénible de devoir continuer à régénérer les informations d'identification jusqu'à ce que j'en obtienne une qui fonctionne !

J'ai envoyé un ticket d'assistance à AWS hier, et aujourd'hui il semble être résolu

J'ai testé plusieurs fois et + et / les deux semblent maintenant fonctionner ? Je ne peux plus reproduire ce bug.

J'ai eu le même problème sur mon Pi.
Avec le dernier awscli (aws-cli/1.11.85 Python/3.4.2 Linux/4.9.24-v7+ botocore/1.5.48), j'avais toujours le problème :

root@pi :~# aws s3 ls s3://
Une erreur s'est produite (SignatureDoesNotMatch) lors de l'appel de l'opération ListBuckets : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie.
Vérifiez votre clé d'accès secrète et votre méthode de signature. Pour plus d'informations, consultez Authentification REST et Authentification SOAP pour plus de détails.

Même avec une clé secrète qui n'avait pas de caractères spéciaux (+ ou /), l'accès ne fonctionnait pas. L'heure était toujours synchronisée, malheureusement ce n'était pas le problème non plus.

Dans le fichier ".aws/config", j'ai ajouté une région valide (juste pour tester...) et du coup ça a fonctionné. Depuis que j'utilise un stockage s3 compatible (pas s3 d'Amazon)

[défaut]
aws_secret_access_key = MA CLÉ
aws_access_key_id = MYID
region = us-east-1 <-- il y avait une valeur "factice" avant.

En apparence, la région doit avoir une valeur « correcte ». Lorsque je le remplace par quelque chose de différent comme "dummyvalue", j'obtiens la même erreur que celle mentionnée ci-dessus.
Maintenant avec la valeur "us-east-1" ça marche !
J'espère que cela aide quelqu'un.

Je viens de tomber sur ça aussi. Semble également être un problème avec un '+' dans la clé secrète. Si j'ai les crédits dans les variables d'environnement, j'obtiens l'erreur. Si je les mets dans le fichier ~/.aws/credentials (en éditant à la main), je n'obtiens pas l'erreur.

[modifier] Je viens de remarquer que les variables d'environnement étaient dans un fichier formaté pour dos (ff=dos dans vim). C'était parce que je venais de prendre le fichier .csv comme téléchargé et de l'éditer pour changer les entrées en variables d'environnement. Lorsque j'ai reformaté le fichier en 'ff=unix', je n'ai plus eu d'erreur. La seule différence entre les 2 est le retour de ligne, dos utilise "CR-NL" alors qu'unix est juste "NL". Je suppose que c'était en fait ce caractère "CR" qui était le problème.

moi aussi, et confirmez également le problème "+"

Si vous rencontrez ce problème lors de l'utilisation de Docker pour Mac, le simple redémarrage de Docker corrigera le décalage horaire du système.

J'étais confronté au même problème.
J'ai vérifié le secret, et il y avait +/ dedans.
J'ai dû créer une nouvelle paire d'identifiants sans caractère spécial pour que cela fonctionne

La création de nouvelles paires de clés jusqu'à ce que j'en obtienne une sans caractères spéciaux l'a également résolue pour moi ; les caractères spéciaux (en particulier +) ne fonctionnent tout simplement pas dans ~/.aws/credentials.

La clé générée sans caractères spéciaux (en particulier + ) a également résolu le problème pour moi.

Le formatage du fichier selon le commentaire de @eikenb fait également l'affaire.

Supprimer la clé et en créer une nouvelle a fonctionné pour moi.

Je viens de recevoir cette erreur. Heure système mise à jour qui semblait être à plus de 6 minutes de l'heure GMT. Correction du problème immédiatement.

C'était tellement étrange et délicat pour moi.
J'ai lutté avec ce problème et j'ai essayé plusieurs fois de le résoudre.
Pour le moment, cela a soudainement fonctionné ! J'ai été surpris alors j'ai fait un nouveau seau mais cela n'a pas fonctionné. Parce que je n'avais rien fait d'autre que changer de code, j'ai juste attendu des heures. Finalement, cela a bien fonctionné même si je n'ai rien fait. Je ne peux pas le croire...

En utilisant aws configure dans un shell bash sur Windows 7, j'ai découvert que j'avais deux lignes aws_secret_access_key dans mon .aws/credentials et la deuxième ligne était l'endroit où j'avais mal tapé une charge de déchets . J'ai supprimé la deuxième ligne et tout a fonctionné.

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

Voir ce problème sur Linux Mint ici, sans + dans ma clé ou mon secret.

Sortie du script de test :

/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

Après la mise à niveau d'awscli vers 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

Je viens de recréer mes clés - Ma nouvelle contient toujours un '+', mais maintenant capable d'utiliser le cli

Ça pourrait être aussi simple que ça

@ DanAbbz92 en effet, il m'est arrivé de trouver la même solution maintenant. Aucune idée de la raison pour laquelle les anciennes clés n'ont jamais fonctionné, mais les nouvelles fonctionnaient bien en utilisant le même processus.

J'ai eu un ^V dans ma clé secrète suite à une mauvaise tentative de collage. Il peut être prudent de mettre un avertissement plus fort sur la vérification des mauvais caractères dans les clés. Empêchera d'autres escalades inutiles.

Ce problème a été signalé en 2014. Nous sommes aujourd'hui le 26 octobre 2017. J'ai rencontré ce problème, mon secret contenait un "+". J'ai créé une nouvelle clé et l'ai mise dans ~/.aws/configure
Allez sur Amazon, avez-vous déjà prévu de corriger ce bug* ???

J'ai rencontré ce problème aujourd'hui après avoir installé le cli et exécuté aws configure . Mes clés ne comportaient aucun caractère spécial, mais les éléments suivants ont résolu mon problème :

• rm -r ~/.aws/
• recréé le dossier .aws et le fichier credentials et rajouté les informations d'identification manuellement

tl; dr l'éteindre et le rallumer a fonctionné pour moi ¯_(ツ)_/¯

Pour les personnes utilisant Hadoop qui se retrouvent ici : Un bogue connexe a été corrigé pour Hadoop 2.8.0 :
« s3 : » Les URL se cassent lorsque la clé secrète contient une barre oblique, même si elle est codée

Bonjour, aujourd'hui j'ai le même problème.
La boîte n'était pas à l'heure. Après la mise à jour, tout fonctionne.

Ajout d'un autre "moi aussi"

J'avais une clé secrète qui contenait deux caractères '+' et qui fonctionnait à partir de mon fichier .aws/credentials sur ma machine virtuelle Windows (lorsqu'elle était utilisée par une application .NET), mais lorsque j'ai installé awscli de brew sur mon MacBook Pro , et copié les fichiers .aws à travers (test des encodages de fichiers, formats de fin de ligne, etc.), il a échoué avec SignatureDoesNotMatch.

J'ai essayé de recréer les informations d'identification jusqu'à ce que j'obtienne une clé secrète sans aucun élément non alphanumérique, et maintenant cela fonctionne à partir de l'awscli sur mon Mac. En copiant ces informations d'identification sur ma machine Windows et en exécutant l'application .NET, cela fonctionne toujours.

Je n'ai apporté aucune modification à l'heure sur l'une ou l'autre des machines (le Mac utilisait déjà NTP et la machine virtuelle Windows semble tourner environ 12 minutes en retard par rapport à l'heure réelle)

J'ai installé awscli avec : brew install awscli

et aws --version renvoie : aws-cli/1.14.30 Python/3.6.4 Darwin/16.7.0 botocore/1.8.34

Eh bien, j'ai poussé le code vers lambdas cet après-midi (2018-02-01 15:48 EST avec lambda dans us-east-1).
Maintenant, à 18 heures, je reçois des erreurs de signature sur tous les systèmes du bureau.
En regardant en arrière sur ce fil: mes temps sont corrects, rien n'a changé, les informations d'identification ont moins d'un an, fonctionnent depuis le jour de leur création, en utilisant la version homebrew aws-cli/1.14.30 Python/3.6.4 Darwin/17.4.0 botocore/1.8.34 (j'ai essayé de passer à une version 1.14. 2x version, pas d'amour)

C'est un peu maladroit

Ayant le même problème et résolu en générant de nouvelles clés sans aucun caractère spécial (comme /, + et ainsi de suite).

Merci à @hellais pour la contribution !

Je viens d'avoir le même problème, je l'ai résolu en corrigeant l'horloge de mon ordinateur portable. Apparemment, j'étais en retard.

Je viens de rencontrer ce problème et il semble que mon client ntp soit en retard de 10 minutes. j'ai fait une ntpdateet tout est maintenant réparé.

Je peux confirmer que la recréation de mes clés d'accès jusqu'à ce que j'en obtienne une sans caractères spéciaux a fonctionné. Quel bug ridicule, wow.

Étant donné qu'il s'agit d'un problème de longue haleine, ne serait-il pas intelligent de mettre à jour la messagerie d'erreur pour donner aux utilisateurs un lien vers un correctif potentiel, comme la reconstruction de vos clés ? Au lieu de quelque chose qui fait que le problème est bien plus complexe que "oui, nous faisons une erreur lorsque vos clés contiennent des caractères spéciaux, désolé!".

même problème entendre :

Versions :

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

Commander:

aws s3 ls
obtenu l'erreur suivante :
Unknown Signature Version: s3v3.

pas de solution:

j'ai mis à jour ma cape et je génère un secret sans personnage particulier

mise à jour - corrigé en suivant

aws configure set default.s3.signature_version s3v4

Oui, c'est toujours un problème - ma clé secrète s'est terminée par un caractère + et aucun correctif que j'ai trouvé n'a fonctionné. Nouvelles clés régénérées sans + à la fin de la clé secrète et cela a bien fonctionné.

Comment diable est-ce encore un problème?

Une erreur s'est produite (SignatureDoesNotMatch) lors de l'appel de l'opération CreateMultipartUpload : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. Vérifiez votre clé et votre méthode de signature.
s'il vous plaît aider.

Mon secret commence par le signe + et je ne savais même pas qu'il y avait ce problème jusqu'à aujourd'hui. J'utilise boto3 python pour accéder à mon s3. Cela ne fonctionne pas lorsque je transmets les informations d'identification sous forme de chaînes brutes, mais fonctionne bien si je les charge à partir de config.ini en tant que variable en utilisant configparser.RawConfigParser() . Bien sûr, générer un nouveau secret sans signe + à la fin ou au début résoudra également ce problème.

Néanmoins, si cela (pour une raison quelconque) ne peut pas être corrigé, changez peut-être le message d'exception en quelque chose comme "nous n'autorisons pas le signe +, générez-en un nouveau si vous voulez y accéder comme vous le faites".

J'utilise aws cli sur osx et j'avais aussi un secret qui semblait ne pas être correct. Mon fichier d'origine contenait un + et un = et j'ai reçu l'erreur SignatureDoesNotMatch lors de la tentative de cp fichiers vers s3. J'ai régénéré les clés et mon nouveau secret est maintenant une chaîne alphanumérique. J'ajoute juste une autre confirmation que la régénération fonctionne. :soulagé:

Dans l'espoir que cela puisse fournir des informations, ce problème (ne pas gérer + dans les clés secrètes) se révèle avec cette version sur 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

mais ne se produit pas avec cette version sur Ubuntu

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

Commencé en janvier 2014 et maintenant en juin 2018, sur 4 ans et j'ai eu le même problème avec l'erreur SignatureDoesNotMatch . La solution pour moi était la même que toutes les solutions majoritaires ici, obtenez une nouvelle clé secrète sans caractère spécial car pour mon ancienne clé a un deux-points : , a essayé la synchronisation de l'heure, mais ne fonctionne pas pour moi. J'utilise WSL.

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

Je viens de mettre à jour ce que @gchiu a dit en avril 2017 : il est toujours vrai en juin 2018 que les secrets

J'ai été déconcerté par cela pendant environ 30 minutes.

J'ai suivi ce problème et vérifié l'heure locale, etc. - tout allait bien.

En désespoir de cause, j'ai supprimé le fichier ~/.aws/credentials et je me suis reconnecté (essentiellement en recréant le fichier) et le tour est joué.

Je me demande pourquoi cela génère cette erreur !

ÉDITER:
Ne semble pas être lié à la clé secrète dans mon cas ; ils étaient tous pour la plupart des chaînes simples.

+1 sur ce problème, ma clé a commencé par un = . Régénéré une clé qui ne contenait qu'un / et tout allait bien. J'ai essayé d'enfermer la clé dans des marques " , mais en vain.

Pas quelque chose que je m'attendrais à voir de l'AWS CLI.

Ajoutant au même problème ici, je ne peux pas croire que le / dans ma clé aurait causé cela. Merci pour le temps perdu !

J'ai eu ce problème. Je pense que c'était le résultat de l'installation initiale d'aws cli en tant qu'utilisateur root. La résolution semblait être de désinstaller le cli aws, de supprimer à la fois le dossier .aws dans le dossier de départ de l'utilisateur actuel ainsi que dans le dossier racine, puis d'exécuter à nouveau 'aws configure' en tant qu'utilisateur actuel.

J'ai rencontré ce problème lors de l'exécution d'un script bash à l'aide d'un timer systemd sur Ubuntu. Lors de l'exécution manuelle du script avec mon utilisateur, tout a bien fonctionné. Cependant, la minuterie continuerait à lancer l'erreur (SignatureDoesNotMatch). J'ai ensuite remarqué que le (SignatureDoesNotMatch) était produit pour toute commande aws exécutée en tant que root et que 'aws configure' n'enregistrait pas les nouvelles valeurs fournies.

Pour résoudre le problème, je me suis connecté en tant que root 'su -i', je suis passé à 'cd ~/.aws/' et j'ai supprimé la configuration avec 'sudo rm -r credentials', j'ai réexécuté 'aws configure' et cette fois les nouvelles valeurs a été sauvé. À partir de là, tout a fonctionné à nouveau comme prévu !

Peut confirmer que ce problème existe toujours sur 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.

Et il s'est avéré qu'il y avait un + dans mon secret. Je me suis régénéré et tout va bien maintenant. Quand pouvons-nous nous attendre à un correctif pour ce @jamesls ? Ou y a-t-il quelque chose que je puisse faire pour aider ?

Face à la même chose sur mon aws cli parce que la clé secrète contenait + ... (comme décrit ci-dessus) Après avoir régénéré une nouvelle clé... (comme je l'ai vu dans le commentaire de delmartechdude ci-dessus)... le problème été résolu.

Mes deux centimes. Cela me donnait cette erreur parce que j'essayais de télécharger du contenu sur s3 avec des transferts accélérés de cette façon (cela fonctionnait auparavant): --endpoint-url http://imaat.s3-accelerate.amazonaws.com ( --endpoint-url http://<bucket-name>.s3-accelerate.amazonaws.com ) comme spécifié dans les propriétés du point de terminaison d'accélération :

En suivant les instructions dans les documents officiels : https://docs.aws.amazon.com/es_es/AmazonS3/latest/dev/transfer-acceleration-examples.html J'ai remplacé cette dernière partie par : --endpoint-url http://s3-accelerate.amazonaws.com et exécutez la commande aws configure set s3.addressing_style virtual pour construire le nom d'hôte dynamiquement. Vérifiez : https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#addressing -style

Je ne sais pas pourquoi, mais maintenant ça marche. Mon nom de compartiment ("imaat") n'a pas de caractère spécial qui peut entraîner des échecs DNS, mais il a échoué pour une raison quelconque avec les dernières mises à jour cli.

L'ajout d'un profil via l'édition de texte et cet échec. Mise à jour de l'identifiant et du secret d'accès au profil via un ensemble de configuration aws et cela a fonctionné. C'est pour un secret avec '+' dedans et aws-cli/1.16.23 Python/2.7.15 Windows/10 botocore/1.12.13

@dave-miles Vous êtes sur quelque chose, merci d'avoir commenté ! Je développe votre conclusion ci-dessous:

J'ai rencontré ce problème avec certaines images de docker. À l'origine, j'utilisais un ADD dans le fichier docker pour ajouter le fichier ~/.aws/credentials dans le conteneur.

Si nous faisions cela, nous rencontrerions l'erreur SignatureDoesNotMatch lors de la tentative de téléchargement à partir de s3.

J'ai supprimé la ligne ADD dans le fichier docker, reconstruit et lancé un nouveau conteneur docker. Dans ce nouveau conteneur, je manuellement couru aws configure set aws_access_key_id <access key id goes here> et aws configure set aws_secret_access_key <secret access key goes here> Ce fut la première fois entrer dans authentification dans ce conteneur (IE le conteneur était un CentOS « frais » image).

Après avoir utilisé les commandes aws configure set , j'ai pu télécharger avec succès à partir de s3.

Pour toute personne utilisant ceci avec un fichier docker, vous pouvez utiliser des instructions RUN dans le fichier docker pour exécuter les deux commandes ou vous pouvez utiliser une instruction ADD pour envoyer un script à votre conteneur docker :

#!/bin/sh

aws configure définir aws_access_key_id _access-key-id-goes-here_
aws configure set aws_secret_access_key _secret-access-key-goes-here_

J'ai eu le même problème que @villasenor - un + dans la clé secrète provoquerait l'erreur lors de la configuration de l'awscli à l'aide des vars env dans docker. la rotation des touches a résolu le problème.

Idem ici, mais il n'y a pas de caractères spéciaux dans la clé d'accès ou la clé secrète.
Un nouvel ensemble a été régénéré pour le même utilisateur IAM, et les nouveaux peuvent répertorier les compartiments, les anciens ne le peuvent pas.

Cela s'est produit avec les appels AWS cli et Java SDK. Suggérer que la faute n'est pas dans les clients...

Les deux ensembles sont toujours en direct. Si quelqu'un chez Amazon veut plus de détails, veuillez nous contacter.

Mon collègue vient de rencontrer cela aussi. J'ai essayé de déboguer en créant une clé d'accès jusqu'à ce que j'en obtienne une avec un + ou / au début. N'a pas pu reproduire cependant.

J'ai eu une expérience de collègue cela. Nous avons déterminé que cela se produit spécifiquement pour Ubuntu 18.04 avec + ou / dans la clé secrète.

J'ai la même erreur aujourd'hui, j'utilise actuellement Windows 10. Cependant, lorsque j'utilise la même clé d'accès sur un autre ordinateur portable (mac), cela fonctionne bien pour moi. Ensuite, j'ai essayé la clé d'accès dans WSL, ce qui est également très bien. Pas sûr de la raison, et il n'y a pas de caractère spécial dans la clé aws.

J'ai cette erreur avec un jeu de clés d'accès et pas l'autre.
Comme mentionné dans plusieurs autres articles, ma clé est un '/' dedans. Pour moi, ce problème semble être un simple problème de codage/décodage du serveur ou des clients utilisant la norme de codage RFC URI et l'autre ne l'utilisant pas.
Je prévois d'exécuter ces scripts de test mentionnés et d'essayer de reproduire les erreurs.

Pour d'autres personnes ici, j'ai rencontré l'erreur, mais j'avais des informations d'identification incorrectes mises en cache dans mon dossier ~/.aws. Il y regarde d'abord et ensuite aux variables d'environnement.

Je rencontre cela sur Windows 10 en utilisant Git Bash. Cela fonctionne très bien avec Powershell. L'invocation Python est évidemment différente, mais c'est le même module Python et Python. J'ai aussi + et / dans ma clé.

Je viens d'avoir ce problème et pour moi, le correctif consistait à supprimer les espaces. Exemple.
au lieu de la valeur par défaut de :
[profilename]
aws_access_key_id = MYAWSACCESSKEYID
aws_secret_access_key = MYAWSSECRETACCESKEY
Je l'ai changé en :
[profilename]
aws_access_key_id=MYAWSACCESSKEYID
aws_secret_access_key=MYAWSSECRETACCESKEY

notez le manque d'espaces autour du =. Cela l'a corrigé pour moi et j'ai aussi + et / dans ma clé d'ailleurs.

Tous, il y a quelques conseils de dépannage impressionnants ici. Je vais les transformer en une page dans la section Dépannage du Guide de l'utilisateur de la CLI. Merci pour les contributions !

Salut tout le monde,

Je peux voir qu'il y a beaucoup de réponses ici, mais pour moi, il s'agissait des caractères spéciaux de la clé d'accès secrète AWS. Le mien a commencé avec "="", mais lorsque j'en ai généré un nouveau sans caractères spéciaux à partir de la console Web, il a commencé à fonctionner immédiatement.

J'exécute awscli dans un shell Zsh sur Ubuntu sous 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

J'espère que cela sera utile à d'autres.

Merci
Jonathan

Je viens de passer 4 heures de débogage jusqu'à ce que je trouve ce fil. Je pouvais utiliser le cli s3 localement sans aucun problème, mais lors de leur exécution dans circleci, j'ai eu cette erreur: SignatureDoesNotMatch ..

Comme d'autres l'ont suggéré, ma clé d'accès secrète contenait un caractère + , et après avoir généré une nouvelle clé, tout a commencé à fonctionner.

Aurait presque été impossible à déboguer sans ce fil

Merci @blbradley . C'était exactement le problème que j'avais.

avait le même problème - la solution consistait à supprimer les variables d'environnement Windows avec des informations d'identification AWS obsolètes

J'ai eu le problème aussi sur Python3 boto3.
Le mien commence par =/

Je suis dans une machine virtuelle rendant l'hôte Time&Region similaire à l'invité Time&Region résout le problème.

Je voulais juste souligner que cela m'a également frappé aujourd'hui sur une clé nouvellement créée - et après beaucoup de frustration, j'ai atterri ici et j'ai vu la mention d'un / dans la clé. Effectivement, c'était le problème - une nouvelle clé sans qu'elle fonctionne. Wtf ?!

Je ne peux pas croire que ce problème s'est ouvert en 2014 et il n'y a toujours pas de solution, ce bogue m'a forcé à créer un nouvel ensemble d'informations d'identification AWS pour moi-même, j'ai même essayé d'encoder le '/' mais cela n'a pas fonctionné :(

L'élimination des informations d'identification avec le "/" a résolu le problème pour moi. Merci à tous de l'avoir signalé.

Frappez-le en 2020 maintenant. La clé secrète a un '+'.

aws-cli — développé par le projet aws — échoue avec des clés aws valides... pendant 6 ans ?

Même problème en janvier 2020. La clé secrète a une barre oblique "/".

J'ai généré un nouvel ensemble d'informations d'identification à l'aide de la console AWS IAM et je me suis assuré que la clé secrète était entièrement alphanumérique, sans "/" ni "+", etc. J'ai remplacé mon ancienne clé secrète par la nouvelle clé secrète, dans mon fichier ~/.aws/credentials, puis j'ai réessayé.

Cela l'a résolu.

Même problème ici sur 2020. Mais je ne peux supprimer aucun caractère alphanumérique car ils font partie de mes informations d'identification elles-mêmes, et je ne contrôle pas cela

Régénérez simplement les informations d'identification jusqu'à ce que vous vous débarrassiez des caractères. Cela ne prend généralement qu'un ou deux essais supplémentaires.

Maurice

De : columb1a [email protected]
Envoyé : mardi 21 janvier 2020 13:47
À : aws/aws-cli [email protected]
Cc : Maurice Bizzarri [email protected] ; Commentaire [email protected]
Objet : Re : [aws/aws-cli] Erreur SignatureDoesNotMatch (#602)

Même problème ici sur 2020. Mais je ne peux supprimer aucun caractère alphanumérique car ils font partie de mes informations d'identification elles-mêmes, et je ne contrôle pas cela

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur 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 & data = 02% 7C01% 7Cmaurice% 40bizzarrisoftware.com% 7Cf6f2e8a571954134b76b08d79ebb6bee% 7C9aa15552370449f5ac56c2850c165d32% 7C1% 7C0% 7C637152400117352225 & sdata = 2Z6PQRSvKD0P8Eu0yrs15Ypi6GgtFvaDi7qewAq5yH4% 3D et réservé = 0 , ou désabonnement 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 .

J'ai d'abord rencontré des problèmes de délai d'attente et après la mise à jour de mon awscli, j'ai rencontré ce problème. Vous pensiez que 6 ans suffisaient pour que ça marche...

je déploie également cette application Vue.js via gitlab vers le compartiment AWS S3 quelqu'un peut-il me dire quoi faire
msg: erreur

Je n'avais pas de caractères non alphanumériques, mais travailler avec profilé n'a pas fonctionné, pour un seul profil. J'ai régénéré les informations d'identification à l'aide de la console et les nouvelles ont fonctionné.

Obtenir de telles erreurs également aujourd'hui et régénérer les informations d'identification sans caractères spéciaux ("+" ou "/") fonctionne pour moi.

J'ai toujours le même problème, mais cela arrive soudainement, je travaille avec les opérations Get et Put et l'une fonctionne, l'autre non. et oui ma clé secrète ne contient aucun caractère spécial. de l'aide? J'appelle d'abord getIntent (API de modèles lex amazon) pour récupérer la somme de contrôle des intentions, puis j'appelle putIntent pour mettre à jour cette intention. La méthode Get fonctionne (pas tout le temps) mais la méthode put présente le même problème de signature, tandis que si j'ai supprimé l'API de méthode Get du code, la méthode Put fonctionne 2 fois sur trois.

J'ai eu ce problème, je vous propose de générer de nouvelles clés
et reconfigurez votre profil aws

aws configurer

ID de clé d'accès AWS [ * * * * QD5E] : AWS_ACCESS_KEY_ID
Clé d'accès secrète AWS [ * * * * ANjA] : AWS_SECRET_ACCESS_KEY
Nom de région par défaut [eu-west-3] : AWS_REGION
Format de sortie par défaut [json] : OUTPUT_FORMAT

Salut !

J'obtiens le même problème lors de l'utilisation d'une URL pré-signée renvoyée à mon client
L'URL est générée dans le serveur (pour une durée limitée). Le serveur est python et je ne vois aucune erreur là-bas, mais le client est JS - n'obtient que l'URL et l'ouvre. Une partie de l'URL correspond aux informations d'identification générées pour cette ressource)

L'erreur est activée et désactivée, donc je pense qu'elle est liée à ce qui est dit ici à propos des clés spéciales dans les informations d'identification, mais comme j'utilise les informations d'identification générées sur le serveur, je ne peux pas les modifier !

Un moyen de s'en occuper dans le code ? analyser les touches spéciales d'une manière ou d'une autre ?

Salut !

J'obtiens le même problème lors de l'utilisation d'une URL pré-signée renvoyée à mon client
L'URL est générée dans le serveur (pour une durée limitée). Le serveur est python et je ne vois aucune erreur là-bas, mais le client est JS - n'obtient que l'URL et l'ouvre. Une partie de l'URL correspond aux informations d'identification générées pour cette ressource)

L'erreur est activée et désactivée, donc je pense qu'elle est liée à ce qui est dit ici à propos des clés spéciales dans les informations d'identification, mais comme j'utilise les informations d'identification générées sur le serveur, je ne peux pas les modifier !

Un moyen de s'en occuper dans le code ? analyser les touches spéciales d'une manière ou d'une autre ?

@maya-harel, vous pouvez modifier les informations d'identification depuis IAM -> les utilisateurs sélectionnent l'utilisateur que vous avez créé et régénérez l'onglet des informations d'identification de sécurité de la clé secrète.

De plus, le timing dans le code est vraiment fatal, pour chaque demande que vous faites en back-end, obtenez l'heure actuelle pour l'utiliser dans l'en-tête pour générer la signature.

Soit dit en passant, il y a eu beaucoup de suggestions aveugles de "régénérer vos informations d'identification IAM" aux utilisateurs qui ont explicitement dit que ce n'était pas une option pour eux.

Cela n'est pas utile pour les utilisateurs et détourne l'attention du fait qu'il s'agit d'un bogue connu qui continue d'affecter les utilisateurs aws-cli qui tentent d'utiliser des informations d'identification IAM valides.

Courir dans cela aussi.
$ aws --version
aws-cli/1.16.300 Python/2.7.16 Linux/4.14.152-127.182.amzn2.x86_64 botocore/1.13.36

Mes clés sont entièrement alphanumériques, sans caractères spéciaux.

Les clés fonctionnent à partir du shell, mais lorsqu'elles sont utilisées via Jenkins dans une cible Makefile, cette erreur se produit. Je ne sais pas ce qui se passe ici.

Ma clé secrète contient à la fois / et + . J'ai rencontré ce problème et j'ai essayé :

• À travers aws-cli > aws iam get-user (en utilisant le fichier ~/.aws/credentials )
• boto3 (via python 3.6.8)
  
  
  
  • Clés codées en dur
  
  
  • Variable d'environnement
  
  
  • Argument boto3.Session(profile_name=PROFILE) (qui tire de ~/.aws/credentials)
  
  

Tout cela entraîne l'erreur SignatureDoesNotMatch .

Je ne peux actuellement pas régénérer la clé.

Ce que je ne comprends pas, c'est que je peux utiliser le protocole S3 dans Cyberduck (https://cyberduck.io/) et cela fonctionne comme prévu. Comment cela pourrait-il être?

Ce doit être l'un des bugs les plus frustrants que j'ai rencontrés et c'est fou qu'il n'a pas été corrigé. Obtenir un crédit sans "+" a fonctionné pour moi dans CircleCI.

Est-ce que ça plante toujours ? face au même problème, wow je ne peux pas être possible...

Oui, c'est frustrant. Ma clé secrète qui avait un + ne fonctionnait pas dans un pipeline Jenkins, mais quand j'en ai généré une nouvelle, qui n'avait que quelques / , a bien fonctionné.

J'ai eu ce problème sur la version installée du package d'awscli sur Ubuntu 16.04. Je l'ai corrigé en installant awscli en tant que package pip python.
Pour obtenir des instructions, suivez ce lien dans la section Installation de l'AWS CLI à l'aide de Python PIP

_ Problème rencontré _

1) A rencontré l'erreur InvalidSignatureException après avoir régénéré la clé d'accès
2) Le journal des erreurs partielles est tel que fourni ci-dessous.

$ python SetupAWS.py list_things
Traceback (appel le plus récent en dernier) :
Fichier "SetupAWS.py", ligne 222, dans
liste_choses()
Fichier "SetupAWS.py", ligne 182, dans list_things
choses = client.list_things()['things']
Fichier "c:Program Files (x86)Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", ligne 316, dans _api_call
return self._make_api_call(operation_name, kwargs)
Fichier "c:Program Files (x86)Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", ligne 626, dans _make_api_call
augmenter error_class (parsed_response, operation_name)
botocore.exceptions.ClientError : une erreur s'est produite (InvalidSignatureException) lors de l'appel de l'opération ListThings : la signature de la demande que nous avons calculée ne correspond pas à la signature que vous avez fournie. Vérifiez votre clé d'accès secrète AWS et votre méthode de signature. Consultez la documentation du service pour plus de détails.

_ Analyse des causes profondes _

1) Comme suggéré par beaucoup dans leurs commentaires ci-dessus, la présence de "+" dans ma clé d'accès secrète entraînait l'erreur ci-dessus.

_ Résolution _

1) Généré une nouvelle clé d'accès en tant qu'utilisateur IAM et vérifié que la nouvelle clé d'accès secrète ne contient pas de « + » dans la chaîne.
2) Exécutez la commande aws configure et fournissez les nouvelles valeurs.
3) Exécuté la commande

$ python SetupAWS.py list_things
[{'thingName' : 'myThingName', 'thingArn' : 'myThingArn', 'attributes' : {}, 'version' : 1}]

Ce problème est ouvert depuis six ans et je vous remercie pour votre patience, votre persévérance et les informations que vous m'avez fournies. Quelques causes sous-jacentes ont été identifiées grâce à vos commentaires (https://github.com/aws/aws-cli/issues/602#issuecomment-520469209) et compilées dans le chapitre Guide de l'utilisateur de la ligne de commande

J'ai essayé de reproduire cela en utilisant un certain nombre d'environnements différents. J'ai utilisé Ubuntu 16.04, Ubuntu 18.04 et Amazon Linux 2, avec Python 3.6.8 et 3.8.3. Alors que de nombreux commentateurs ont utilisé Python 2, je n'ai pas essayé de le reproduire car il n'est plus pris en charge. J'ai utilisé la dernière v1 aws-cli (1.18.80 au moment de la rédaction) ainsi qu'une ancienne version (1.11.78) référencée dans ce numéro. J'ai utilisé le script fourni (https://github.com/aws/aws-cli/issues/602#issuecomment-281866173) par @jamesls qui crée de nouvelles paires d'informations d'identification jusqu'à ce qu'il en rencontre une avec des caractères spéciaux et les laisse s'exécuter jusqu'à une heure chacun. Je n'ai eu aucune occurrence d'une erreur SignatureDoesNotMatch . J'ai reçu occasionnellement des erreurs AuthFailure sur la commande describe-instances, mais une nouvelle tentative de la commande avec les mêmes informations d'identification réussit.

Le grand nombre de commentaires rend difficile pour les nouveaux utilisateurs qui rencontrent ce problème de trouver des demandes de notre équipe de développeurs pour des suggestions de dépannage. Pour aider notre équipe et la communauté à déterminer la cause de cette erreur, je ferme ce problème et crée un modèle de problème GitHub spécifique qui inclut des instructions et des commentaires pour les utilisateurs rencontrant cette erreur.

Si vous rencontrez cette erreur, rendez-vous sur l'onglet Problèmes, cliquez sur le bouton "Nouveau problème" et utilisez le modèle de rapport d'erreur SignatureDoesNotMatch (ou utilisez le lien ci-dessous).

En raison de la variation des environnements utilisateur dans lesquels cette erreur se produit, veuillez déposer un problème distinct au lieu de commenter un problème existant.

Cliquez ici pour déposer un rapport d'erreur SignatureDoesNotMatch