BEARBEITEN: Wenn dieses Problem auftritt, würden wir uns über Ihre Hilfe bei der Fehlerbehebung freuen. Ich aktualisiere diesen Kommentar, um die Schritte zur Fehlerbehebung besser sichtbar zu machen.

Fehlerbehebung

Der erste Schritt zur Fehlerbehebung besteht darin, festzustellen, ob das Problem an den Anmeldeinformationen selbst oder an der CLI liegt. Um dies zu testen, versuchen Sie, diese Anmeldeinformationen in anderen AWS SDKs (Javascript, Ruby, Java usw.) zu verwenden. Um dabei zu helfen, habe ich ein Testskript erstellt, das das AWS SDK für Python und Javascript verwendet, das hier verfügbar ist: https://github.com/jamesls/aws-creds-test . Führen Sie nach dem Klonen einfach make install , make test . Es fordert Sie zur Eingabe von Anmeldeinformationen auf (ähnlich der CLI) und führt einen API-Aufruf an 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.

Für Personen, die auf dieses Problem stoßen, führen Sie bitte das Testskript aus und geben Sie die Ausgabe frei.

Dies sollte uns einen besseren Einblick geben, wo dieses Problem auftritt:

• Wenn das obige Skript sowohl für Python als auch für Javascript funktioniert, aber bei der Verwendung der CLI fehlschlägt, liegt wahrscheinlich ein CLI-Problem vor.
• Wenn das Skript für Python fehlschlägt, aber für Javascript erfolgreich ist, liegt wahrscheinlich ein Problem mit Botocore (das die CLI verwendet) vor.
• Wenn das obige Skript sowohl für Python als auch für Javascript fehlschlägt, liegt wahrscheinlich ein Problem mit den tatsächlichen Anmeldeinformationen vor.

Vielen Dank im Voraus für jeden, der uns bei der Behebung dieses Problems helfen kann. Lassen Sie es mich wissen, wenn es Fragen gibt.

So sieht es aus:

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

Irgendwelche Updates zu diesem Thema? Ich stoße auch auf diesen Fehler und meine Datei mit den Anmeldeinformationen hat sich nicht geändert.

Ich habe ein ähnliches Problem. Das Jenkins s3-Plugin kann ein Objekt mit meinen Anmeldeinformationen platzieren, aber die aws-cli gibt mir die folgenden Fehler aus.

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.

Ich stoße auf das gleiche Problem. Wenn ich ein Geheimnis erfinde, erhalte ich einen anderen Fehler (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

Das hält mich ziemlich davon ab. Ich kann einige Dinge mit den Dienstprogrammen ec2-blah-stuff tun, indem ich x509-Zertifikate angebe, aber die Hilfe sagt, dass dies veraltet ist, also möchte ich mich nicht darauf verlassen. Jede Hilfe bei der Fehlerbehebung oder was auch immer wäre wirklich dankbar.

Der erste Schritt wäre, sicherzustellen, dass Ihre Zugangs-/Geheimschlüssel tatsächlich gültig sind. Ein paar Dinge zum Ausprobieren:

• Funktionieren dieselben Zugangs-/Geheimschlüssel-Anmeldeinformationen mit anderen Tools? (Das Java/Javascript/Ruby/Python-SDK?)
• Funktionieren andere Befehle außer "aws s3" für Sie? Generiert "aws ec2 describe-instances" immer noch Authentifizierungsfehler?

Sie funktionieren nicht mit anderen Tools (zB ec2-describe-instance).

Ich denke, dass ich die entsprechenden Rechte habe, seit ich die certs-Werke verwende. Um sicherzustellen, dass es sich nicht um eine Workstation-Sache handelt, habe ich eine Amazon Linux-Instance erstellt und verwende die mitgelieferte awscli-Version, erhalte jedoch die gleiche Meldung.

Auch ein Thema für mich. Ich verwende es in einem Docker-Container, der mit derselben Dockerfile erstellt wurde.
Es funktioniert gut, wenn es auf einem EC2 erstellt wird, funktioniert jedoch nicht, wenn es lokal auf einer Coreos-Vagrant-Box erstellt wird.

Es sieht so aus, als ob das Problem bei den Anmeldeinformationen selbst liegt. Ich habe dies doppelt überprüft und kann dieses Problem nicht reproduzieren. Überprüfen Sie die Anmeldeinformationen auf der Seite mit den

Mir ist das gerade passiert und es lag daran, dass meine Systemzeit zu stark war, obwohl dies nicht gemeldet wurde. Habe ntpdate gegen pool.ntp.org ausgeführt und dieses Problem für mich behoben.

Wenn Sie diesen Fehler erhalten, wenn Creds mit der env-Variablen eingerichtet werden, versuchen Sie es mit sudo

Wenn Sie sich in einer virtuellen Maschine befinden, stellen Sie sicher, dass die Uhrzeit des Host-Betriebssystems mit der Uhrzeit des Gastbetriebssystems übereinstimmt. Ist dies nicht der Fall, kommt der von Ihnen beschriebene Fehler.

Ein sehr ähnlicher Fehler tritt bei mir mit guten Anmeldeinformationen auf, wenn ich einen Bucket aufliste, der eine _lot_ von Schlüsseln enthält. Hier ist der Fehler:

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.

Hier ist meine Ausgabe von 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

Beachten Sie, dass diese Anmeldeinformationen mit anderen aws Aufrufen gut funktionieren, und tatsächlich wird diese list Op für eine lange Zeit (mehr als eine Stunde) ausgeführt, bevor dieser Fehler ausgelöst wird. Ich habe eine Datei mit über 82.000 Ausgabezeilen aus dem Befehl, der schließlich fehlgeschlagen ist.

Ich habe dieses Problem bekommen, und wenn ich mein Skript nur eine Sekunde lang schlafe und es erneut versuche, wird es ausgeführt. Es ist fast so, als ob es gedrosselt wird und den falschen Fehler oder so zurückgibt.

Dieses Problem kann ich auch melden. Beim Versuch, eine 11-GB-Datei mit aws cp foo s3://mybucket/foo/bar hochzuladen, erhalte ich verschiedene Fehler wie:

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.

und

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)

Ich habe überprüft, ob meine Systemzeit korrekt ist. Ich habe auch beim Hochladen auf demselben System eine beträchtliche Langsamkeit (in Bezug auf das Timing von HTTP-Anfragen) festgestellt, sodass dies ein Drosselungsproblem ist, das vernünftig klingt. Es funktioniert auch gut, kleine Dateien mit denselben Anmeldeinformationen hochzuladen und die Webkonsole von demselben Computer aus zu verwenden. Dies scheint also ein aws-cli-Problem zu sein.

Dies ist mir auch mit aws-cli 1.5.5 passiert, ein Update von aws-cli auf 1.6.2 hat es gelöst.

Passiert mir mit 1.6.2

Das ist mir heute passiert. Das ist mir neu. Benutze awl-cli seit einigen Monaten kein Problem und keine Änderung der Anmeldeinformationen 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

Ich glaube, dieses Problem ist jetzt über https://github.com/boto/botocore/pull/388 behoben und wird in der nächsten AWS CLI-Version verfügbar sein.

@jamesls bestätigt, dass die awscli-Version 1.6.4 behoben wurde. Ich habe 1.5.4 . Danke!

Ich bekomme dieses Problem auf einem neuen Ubuntu-System.

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 über pip installiert

$ 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)

Irgendwelche Ideen, wie man es beheben kann?

Meine Lösung war, ein paar Sekunden zu schlafen und es dann erneut zu versuchen, aber es ist
Klingt so, als ob es ein Update für das Tool geben könnte, das es auch behebt.

Am Dienstag, den 2. Dezember 2014 um 3:38 Uhr schrieb Mark Wolfe [email protected] :

Ich bekomme dieses Problem auf einem neuen Ubuntu-System.

Beim Aufrufen des PutObject-Vorgangs ist ein Clientfehler (SignatureDoesNotMatch) aufgetreten: Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen bereitgestellten Signatur überein. Überprüfen Sie Ihren Schlüssel und die Signaturmethode.

aws-cli über pip installiert

$ Pip-Liste
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)
Karte (2.0.1)
Gepard (2.4.4)
cloud-init (0.7.5)
Kolorama (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)
Landschafts-Client (14.01)
MarkupSafe (0,18)
Quecksilber (2.8.2)
auth (1.0.1)
PAM (0.4.2)
Kissen (2.3.0)
Pip (1.5.4)
hübschtisch (0.7.2)
pyasn1 (0.1.7)
pycrypto (2.6.1)
pycurl (7.19.3)
Pygmente (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)
Anfragen (2.2.1)
römisch (2.0.0)
rsa (3.1.2)
Setuptools (3.3)
sechs (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)

Irgendwelche Ideen, wie man es beheben kann?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/aws/aws-cli/issues/602#issuecomment -65198065.

@wolfeidau und ja, ich habe zu früh gesprochen. Das lokal pip installierte awscli gibt erneut die SignatureDoesNotMatch-Fehler aus. Huch!

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'

Tritt dieses Problem nur auf, wenn eine Anfrage wiederholt wird? Oder passiert dies jedes Mal, wenn Sie den Befehl deregister-instances-from-load-balancer ausführen?

@jamesls es passiert jetzt jedes Mal :(

Ich weiß, dass dieses Problem geschlossen ist, wollte aber mitteilen, dass dieser Fehler bei der Ausführung in einer VM im Ruhezustand angezeigt wird. In solchen Fällen holt die Systemuhr nicht ständig auf, wenn Sie Ubuntu verwenden. Aktualisieren Sie einfach die Zeit zum Beheben (zB sudo ntpdate -s time.nist.gov).

hallo, gibt es da eine endgültige lösung?

+1

Bei Verwendung von Version 1.7.8 der CLI wurde der gleiche SignatureDoesNotMatch-Fehler angezeigt, als ich Folgendes versuchte:
$ aws iam list-users

Und dafür einen AuthFailure bekommen:
$ aws ec2 describe-security-groups

Nachdem ich meine Schlüssel gelöscht und neue ausprobiert habe, funktionieren beide Befehle.

Dies ist der alte geheime Zugangsschlüssel, der möglicherweise die Ursache für meine Probleme war, beachten Sie die Prozent-, Plus- und Schrägstrich-Zeichen: H2J7/oT3Fib15SwFVB1s3EnTCmg+SC7wF7qoP+dw%

:+1: @gsterndale. Mein Zugangsschlüssel mit % darin hat nicht funktioniert. Ich musste neue Schlüssel generieren.

Dieses Problem habe ich auch schon mehrfach erlebt. Jedes Mal, wenn ich den Schlüssel neu generierte, bis ich einen ohne Sonderzeichen darin hatte (insbesondere hatte ich Probleme mit dem + Zeichen im Geheimnis), wurde das Problem behoben.

Ehrlich gesagt verschwanden alle meine Probleme mit dem Signieren von Schlüsseln, als ich den Befehl auf einem Ubuntu-Rechner anstelle einer lokalen Mac-Homebrew-Installation ausführte.

Ich bin sehr neu bei AWS und habe dieses Problem sofort auf dem Knoten js festgestellt

              ^

SignatureDoesNotMatch: Die von uns berechnete Anfragesignatur stimmt nicht mit der von Ihnen angegebenen Signatur überein. Überprüfen Sie Ihren AWS Secret Access Key und die Signaturmethode. Konsultieren Sie die s
Vize-Dokumentation für Details.

Der kanonische String für diese Anfrage hätte lauten sollen
'POST
/

host:email.us-west-2.amazonaws.com
x-amz-content-sha256:89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39
x-amz- Datum:20150809T053346Z

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

Der String-to-Sign hätte sein sollen
'AWS4-HMAC-SHA256
20150809T053346Z
20150809/us-west-2/ses/aws4_request
0b908b0248bae550b814b37629a418707742416377816b5a5e78e1897b72293e'

+1

Ich habe dieses Problem für alle aws s3-Befehle (awscli 1.8.6 auf Ubuntu 14.04 LTS).
Gibt es bekannte Lösungen? Ich habe versucht, meine Anmeldedatendatei zu löschen und aws configure auszuführen, neu zu starten und awscli neu zu installieren.

@mcobzarenco , hast du neue Schlüssel ausprobiert?

@gsterndale Ich habe den obigen Kommentar über Schrägstriche in alten Schlüsseln gesehen, aber das ist nicht der Fall und meine Schlüssel wurden kürzlich generiert (im Juni 2015). Ich habe dieses Problem nur auf AWS Ubuntu 14.04 LTS. Auf meinem Laptop (14.04) funktioniert awscli (gleiche Version) einwandfrei.

@mcobzarenco Ich glaube nicht, dass es am Alter der Schlüssel liegt, sondern an den Sonderzeichen darin. Als ich ursprünglich Schlüssel erstellt habe, hatten sie zufällig Prozent-, Plus- und Schrägstrichzeichen. Beim Debuggen des Problems habe ich versucht, Schlüssel zu löschen und neue zu erstellen. Diese neuen hatten glücklicherweise keine dieser Charaktere und sie funktionieren.

bin gerade unter Ubuntu auf dieses Problem gestoßen. Als ich die Schlüssel per cli eingegeben habe, hat es sie in ~/.aws/config gespeichert, aber das '+'-Zeichen entfernt. Durch manuelles Bearbeiten der Datei, um das "+" hinzuzufügen, konnte ich eine Verbindung herstellen.

@gsterndale Danke für den Tipp, ich kann bestätigen, dass das Generieren eines neuen Schlüssels, der nicht + auch für mich funktioniert hat. Die Lösung von @stebl ist schön, wenn es umständlich ist, die Schlüssel zu ersetzen.

Ich hatte das gleiche Problem bei der Verwendung von AWS SDk mit Knoten js. Um dieses Problem zu beheben, habe ich genau die hier beschriebenen Schritte befolgt
http://aws.amazon.com/developers/getting-started/nodejs/

Ich denke, AWS SDK wurde mit einer bestimmten Version von node js entwickelt, eine Nichtübereinstimmung in node js führt zu Problemen wie diesen.

Ich habe das gleiche Problem und ja, es wurde mit einer Taste ohne Sonderzeichen gelöst (in meinem speziellen Fall + ).

Wir sind auf diesen Fehler gestoßen (wobei ein Computer Instanzen mit awscli beschreiben konnte, der andere jedoch einen Zugriffsverweigerungsfehler mit demselben Zugriffsschlüssel erhielt. Auf dem letzteren Computer gaben iam list-users diesen SignatureDoesNotMatch-Fehler aus). Behoben durch Korrigieren der Systemuhrzeit auf dem Computer mit dem Problem.

Wie @tukaaa sagte, gibt es einen Fehler, wenn der geheime Zugriffsschlüssel ein nicht alphabetisches Zeichen (wie +) enthält. Ich finde es schlimm, irgendwo zu entkommen ;-(

@ebuildy Können Sie bestätigen, auf welcher Version der CLI Sie dies sehen ( aws --version )? Wenn dies eine Grundversion der CLI ist, werde ich dieses Problem erneut öffnen.

Ich bekomme das auf aws-cli/1.9.1 Python/3.5.0 Windows/7 botocore/1.1.8

Ich hatte das gleiche Problem auf einer Windows-Box, bei der ein Schlüssel ohne Nicht-Alpha-Zeichen verwendet wurde. Ich hatte überprüft, dass es sich nicht um einen Kopier- / Einfügefehler handelte, indem ich denselben Einfügepuffer in einer anderen Box verwendet habe. Das Deinstallieren / Neuinstallieren der AWS-Cli und das Löschen der Anmeldeinformationen / Konfigurationsdateien und das erneute Ausführen der AWS-Konfiguration haben das Problem behoben.

Habe das gerade auf aws-cli/1.10.3 Python/2.7.10 Darwin/14.5.0 botocore/1.3.25 .

Das Neugenerieren eines Schlüssels ohne Sonderzeichen hat das Problem behoben. FWIW war in meinem Fall das Sonderzeichen / und ich habe eine INI-Datei verwendet.

Ok, Wiedereröffnung, wir werden uns damit befassen.

@Ich kann bestätigen, dass ich das gleiche Problem habe, das @gsterndale beschreibt.

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

Aber mein Schlüssel enthält keine Sonderzeichen.

Ich erhalte den gleichen Fehler bei der Verwendung des s3-cli-Knotenmoduls. Mein geheimer Schlüssel enthält ein [ .

Ich habe endlich herausgefunden, was los ist. Ich habe den Tasten versehentlich mehrere Zeichen hinzugefügt. Das ist der Grund.

Ich hatte dieses Problem mit dem folgenden Szenario; sowohl auf rhel7 als auch auf ubuntu. Ich denke, es hat etwas mit Nicht-Alpha-Zeichen zu tun, wie andere bereits erwähnt haben

• s3-Bucket geschützt für eine einzelne Rolle
• ec2-Instanz mit dieser Rolle muss dieselbe Rolle übernehmen, bevor auf den geschützten s3-Bucket zugegriffen wird

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`

Ich glaube, etwas mit der --query hat die Anmeldeinformationen durcheinander gebracht. Wenn Sie die Befehle manuell ausführen und die Werte kopieren und einfügen; dann die Umgebungsvariablen setzen schien es gut zu funktionieren.

Ich hatte das gleiche Problem beim Ausführen von awscli Version 1.10 auf einem Mac (installiert über pip) im Vergleich zu Ubuntu (Amazon Image) awscli Version 1.2.9. aws configure --profile user erzeugt jeweils zwei verschiedene Konfigurationen. Version 1.10 produzierte zwei Dateien: config und Credentials. Version 1.2.9 hat gerade eine Konfigurationsdatei erstellt (aber mit den Anmeldeinformationen). Als ich die Anmeldeinformationen und die Konfigurationsdatei von Version 1.10 gelöscht und die Konfigurationsdatei von Version 1.2.9 kopiert habe, funktionierte alles, sogar mit Sonderzeichen und der Ausführung von awscli Version 1.10. Die von Version 1.2.9 erzeugte Konfigurationsdatei ist

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

Kann bestätigen, dass es an nicht-alphanumerischen Zeichen liegt.

Ich habe das gleiche Problem mit einem geheimen Schlüssel, der ein + enthält. Ich bin jedoch nicht der Besitzer des S3-Kontos und kann nicht einfach ein neues erstellen. Hat jemand eine andere Lösung gefunden, als einen neuen Schlüssel ohne Sonderzeichen zu erstellen?

tl; dr Lösung: Erstellen Sie die Anmeldeinformationen wiederholt neu, BIS Ihr aws_secret_access_key KEINE nicht-alphanumerischen Zeichen enthält ... in meinem Fall enthielt aws_secret_access_key ein + (Pluszeichen)

Ich habe gerade eine Neuinstallation durchgeführt ... dasselbe Problem ... dies ist auf Ubuntu ... es ist kein lokales Betriebssystemproblem, es ist ein Amazon API-Problem, also ignorieren Sie andere Kommentare, die besagen, dass das Entfernen von OSX es behebt

AWS ec2 Beschreibungsinstanzen

Beim Aufrufen der DescribeInstances-Operation ist ein Fehler aufgetreten (AuthFailure): AWS konnte die bereitgestellten Zugangsdaten nicht validieren

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

aws ec2 describe-security-groups

Beim Aufrufen der DescribeSecurityGroups-Operation ist ein Fehler aufgetreten (AuthFailure): AWS konnte die bereitgestellten Zugangsdaten nicht validieren

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

aws ecr get-login

Beim Aufrufen des GetAuthorizationToken-Vorgangs ist ein Fehler aufgetreten (InvalidSignatureException): Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen bereitgestellten Signatur überein. Überprüfen Sie Ihren AWS Secret Access Key und die Signaturmethode. Weitere Informationen finden Sie in der Servicedokumentation.

Der kanonische String für diese Anfrage hätte lauten sollen
'POST
/

Inhaltstyp : Anwendung/x-amz-json-1.1
host:ecr.us-east-1.amazonaws.com
x-amz- Datum:20160615T182955Z
x-amz- target:AmazonEC2ContainerRegistry_V20150921.GetAuthorizationToken

Inhaltstyp;Host;x-amz-Datum;x-amz-Ziel
44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a'

Der String-to-Sign hätte sein sollen
'AWS4-HMAC-SHA256
20160615T182955Z
20160615/us-east-1/ecr/aws4_request
86c2e3c850acd6765a1ca6aa626c6e9a6c85284f3954f45e170f51b5b89961c7'

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

aws iam list-users

Beim Aufrufen der ListUsers-Operation ist ein Fehler aufgetreten (SignatureDoesNotMatch): Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen angegebenen Signatur überein. Überprüfen Sie Ihren AWS Secret Access Key und die Signaturmethode. Weitere Informationen finden Sie in der Servicedokumentation.

Der kanonische String für diese Anfrage hätte lauten sollen
'POST
/

host:iam.amazonaws.com
x-amz- Datum:20160615T183516Z

host;x-amz-date
b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2'

Der String-to-Sign hätte sein sollen
'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-generischer Botocore/1.4.28

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

cat /root/.aws/credentials
[Ursprünglich]
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

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

LÖSUNG :
Nach dem Löschen und Erstellen neuer Anmeldeinformationen
wo aws_secret_access_key KEIN Pluszeichen (+) hatte, war alles weit über den Befehlen, die funktionierten OK

Ich hatte das gleiche Problem. Das erneute Erstellen von Anmeldeinformationen, bis ich keine Sonderzeichen darin hatte, funktionierte für mich.

Ich habe festgestellt, dass beim Kopieren und Einfügen der Anmeldeinformationen am Ende ^ M-Zeichen enthalten sind, die den Fehler verursacht haben.

Einen geheimen Schlüssel ohne + es auch für mich behoben...

Hinweis - Wenn dieses Problem unter (boot2docker VM'd) Docker auftritt, kann es sein, dass die VM-Uhr nicht synchron ist.
Siehe: http://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host

Ich habe das gleiche Problem. Was ist, wenn ich keine Berechtigung zum Regenerieren der Anmeldeinformationen habe. Alle möglichen Korrekturen auf andere Weise?

UPDATE: Ich habe dies behoben, indem ich rm -rf .aws/cli/cache/

Dieses Problem habe ich jetzt auch. Beim Versuch, eine Rolle zu übernehmen

Ausführung:
aws-cli/1.11.17 Python/2.7.10 Darwin/16.1.0 botocore/1.4.74

Edit: Habe jetzt auch nochmal versucht zu aktualisieren, gleiches Problem:
aws-cli/1.11.18 Python/2.7.12 Darwin/16.1.0 botocore/1.4.75

Ausgabe:

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'

Das gleiche Problem besteht auch bei der neuesten (aktuellen) Version der AWS CLI. Ich habe gerade meine 1.8.3 CLI auf 1.11.19 aktualisiert - und konnte keine Befehle mit einem neuen Benutzer/Schlüsseln ausführen, die ich erstellt habe. Musste etwa 5 Schlüssel erneut verwenden, bevor ich ein Paar bekam, bei dem der geheime Schlüssel keine nicht alphabetischen Zeichen hatte. Sobald ich über ein solches Paar gestolpert bin - CLI funktioniert einwandfrei.

Sehr ärgerlich - ich wünschte, Amazon würde keine ungültigen Schlüssel generieren, die sie nicht verarbeiten können.....

@mpopova-yottaa hast du versucht, den awe-cli-Cache vollständig zu leeren? Versuchen Sie, das gesamte ~/.aws Verzeichnis zu löschen (machen Sie eine Kopie Ihrer Konfigurations-/Anmeldedateien)

aws ec2 describe-instances läuft für mich, aber beim Versuch, einen Wolkenformationsstapel zu erstellen:

```Ausnahme im Thread "main" com.amazonaws.services.cloudformation.model.AmazonCloudFormationException: Die von uns berechnete Anfragesignatur stimmt nicht mit der von Ihnen angegebenen Signatur überein. Überprüfen Sie Ihren AWS Secret Access Key und die Signaturmethode. Weitere Informationen finden Sie in der Servicedokumentation.

Der kanonische String für diese Anfrage hätte lauten sollen
'POST
/

amz-sdk-invocation-id:18d13b66-80ae-f676-c0cf-dbf875edb1aa
amz-sdk- wiederholen:3/345/470
host: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- Datum:20161127T194448Z

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

Der String-to-Sign hätte sein sollen
'AWS4-HMAC-SHA256
20161127T194448Z
20161127/us-west-1/cloudformation/aws4_request
cb0286a8727afcc465171ab991accde0aaa7210e160a9ba3196e2a5e4305f428' (Dienst: AmazonCloudFormation; Statuscode: 403; Fehlercode: SignatureDoesNotMatch; Anforderungs-ID: f52abbd4-b4d9-11e6-b989-d5c3d505d

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

Der geheime Schlüssel enthält nur alphanumerische Zeichen, also stecke ich fest.

@aebrow4 Es ist der Cache für awe-cli. Versuchen Sie zu löschen: .aws/cli/cache/

@cultavix es gibt kein cli Verzeichnis in .aws

Ich habe diesen Fehler beim Ausführen von aws glacier upload-archive mit --archive-description "`date`" . Wenn ich --archive-description "`date +%Y/%m/%d`" , funktioniert es einwandfrei, es scheint also ein Problem mit der Flucht zu geben.

Ich hatte ein ähnliches Problem:

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

Ich habe versucht, die Uhrzeit mit einem NTP-Server zu synchronisieren (erfolgreich), aber das hat das Problem nicht behoben. Das Regenerieren von Schlüsseln, bis ich einen Satz ohne Sonderzeichen hatte, hat dies behoben.

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

Ich habe das gleiche Problem mit awscli und Python-Beispielcode (boto3).
Beachten Sie, dass ich IBM Object Storage S3-Api-kompatibel verwende. Ich kann Buckets und deren Inhalt auflisten, aber nicht hochladen (sowohl für Python-Code als auch für CLI).
Ich habe das Szenario mit ruby aws-sdk getestet und es funktioniert einwandfrei (Upload/Download).
-- Aufbau
aws-cli/1.2.9 Python/3.4.3 Linux/3.19.0-33-generic

Habe gerade das gleiche Problem mit einem Skript, das ich seit Monaten zum Hinterlegen mehrteiliger Uploads in Glacier verwende. Kann immer noch gut über aws cli einzahlen, sodass die Anmeldeinformationen weiterhin funktionieren, aber das Skript mit boto3 schlägt fehl mit:

"botocore.Exceptions.ClientError: Beim Aufrufen der Operation InitiateMultipartUpload ist ein Fehler aufgetreten (InvalidSignatureException): Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen bereitgestellten Signatur überein. Überprüfen Sie Ihren AWS Secret Access Key und die Signaturmethode. Weitere Informationen finden Sie in der Servicedokumentation."

aws --Version ist
aws-cli/1.11.38 Python/2.7.10 Darwin/15.6.0 botocore/1.5.1

(Ja, ich habe alles aktualisiert, weil ich dachte, dass es das Problem beheben könnte ... kein Glück.)

Ein neues Schlüsselpaar ohne Sonderzeichen zu bekommen (in meinem Fall war es + ) hat das Problem für mich behoben

hier eine weitere Bestätigung der falschen Behandlung von + im geheimen Schlüssel.

Hallo zusammen, hier ist ein Skript, mit dem ich versucht habe, dieses Problem zu reproduzieren: https://gist.github.com/jamesls/00ef7fcc0ac39ba8b06956d165c42f6d . Das macht das Skript:

• Erstellt ein neues access_key/secret_key-Paar über aws iam create-access-key in einer Schleife, bis Credentials gefunden werden, die entweder ein + oder ein / Zeichen enthalten.
• Es erstellt ein neues "testcreds" -Profil mit diesen neu generierten Zugangsdaten
• Es versucht, verschiedene AWS CLI-Befehle aufzurufen, um sicherzustellen, dass diese Anmeldeinformationen funktionieren

Dies geschieht in einer Endlosschleife, bis ein API-Aufruf fehlschlägt. Bisher habe ich es nicht geschafft, es zum Scheitern zu bringen. Geheimschlüssel mit + und / funktionieren bei mir.

An dieser Stelle haben wir bestätigt, dass es definitiv möglich ist, secret_keys mit einem + oder / verwenden das bricht, wenn + vorhanden ist. Beim erneuten Lesen der Kommentare in diesem Thread könnte es ein Problem mit der Eingabe von Anmeldeinformationen in die Datei ~/.aws/config oder ~/.aws/credentials . Vielleicht gibt es eine plattformspezifische Sache, die Zeichen ändert, die + oder / .

Für alle, bei denen dieses Problem immer noch auftritt, wäre es sehr hilfreich, wenn Sie einige zusätzliche Informationen bereitstellen könnten:

1. Wie erhalten Sie Anmeldeinformationen (Kopieren/Einfügen von der Konsole, aws iam create-access-key , CSV-Datei von der Konsole usw.)?
2. Wie konfigurieren Sie die CLI, um diese Anmeldeinformationen zu verwenden? Führen Sie aws configure und geben Sie die Werte ein, wenn Sie dazu aufgefordert werden? Tun Sie dies programmgesteuert, indem Sie aws configure set ausführen? Bearbeiten Sie ~/.aws/config und/oder ~/.aws/credentials manuell? Die verschiedenen AWS_* Umgebungsvariablen setzen?

Bonus-Dinge, die nach Möglichkeit noch hilfreicher wären:

1. Wenn Sie andere SDKs verwenden, funktionieren diese Anmeldeinformationen, die in der CLI nicht funktionieren, in anderen AWS SDKs?
2. Wenn Sie ein Testkonto oder einen IAM-Testbenutzer haben, schlägt die Ausführung des Skripts, das ich zum Testen verwende , bei Ihnen fehl?

Alle zusätzlichen Informationen, die uns helfen könnten, dieses Problem von unserer Seite zu reproduzieren, wären großartig.

Ich habe dieses Problem immer noch. Um Ihre Fragen zu beantworten:
Anmeldeinformationen in der Amazon-Konsole erstellt und in ~/.aws/credentials ausgeschnitten / eingefügt (mit Emacs auf einem Mac bearbeitet)

Von der Fehlerbehebung, die ich bisher gemacht habe (und ich bin ein Neuling darin ...) ist die 'Canonical String' korrekt, aber die 'String-to-Sign' ist falsch, da sie eine andere letzte Zeile hat. Dh wenn ich den Rückgabewert von auth.py string_to_sign ausdrucke, unterscheidet sich die von 'sha256(canonical_request.encode('utf-8')).hexdigest())' erzeugte Zahl von der Zahl, die im zurückgegebenen Fehler "The String -to-Sign hätte sein sollen" .

Es gibt keine Sonderzeichen in meinen Zugangsdaten und die funktionieren auch, wenn man andere Tools verwendet, zB CrossFTP (was ich nicht verwenden möchte!!!)

Alle Einblicke würden sehr geschätzt!!

@samato88 das scheint dort ein anderes Problem zu sein. Wenn Sie Debug-Informationen weitergeben könnten (stellen Sie sicher, dass Sie alle vertraulichen Informationen entfernen), würde dies hilfreich sein.

Das string_to_sign wird nicht durch den secret_access_key beeinflusst. Wenn wir eine Anfrage signieren, nehmen wir die HTTP-Anfrage, die wir senden werden, konvertieren sie in eine Zeichenfolge (dh die Zeichenfolge ot sign) und signieren diese Zeichenfolge dann mithilfe des geheimen Schlüssels mit dem geheimen Schlüssel (wobei wir einige überspringen Details hier). Alle Probleme mit der zu signierenden Zeichenfolge wären also von diesem Problem getrennt.

Könnten Sie ein weiteres Problem öffnen und die Ausgabe von --debug bereitstellen (oder die vollständige Anfrage und Fehlermeldung vom Dienst einfügen)? Wir prüfen das gerne für Sie.

Danke jamesls - ich habe ein separates Thema geöffnet unter:
https://github.com/aws/aws-cli/issues/2474

Alle Einblicke sehr geschätzt.

Wenn Ihre Systemzeit um mehr als 5 Minuten abweicht, können Sie CLI . nicht verwenden

lauf einfach... sudo ntpdate -s time.nist.gov

dann versuch es nochmal

Ich hatte das gleiche Problem, mein geheimer Schlüssel enthält ein "+"-Zeichen. Ich habe meine .aws/credentials-Datei gelöscht und aws configure erneut ausgeführt. Danach funktionierte meine Abfrage an die sqs-Warteschlange, um eine Nachricht zu erhalten.

Danke @AlexParra03 . Ich hatte das gleiche Problem und Ihre Kommentare haben mir bei der Lösung geholfen.... :-)

@robotzero erinnerst du dich, wie du deine Zugangsdaten eingegeben hast? Haben Sie aws configure und dann die Werte aus der Webkonsole kopiert/eingefügt?

Ja, ich habe AWS configure ausgeführt und die Werte kopiert und eingefügt.

Ja, ich hatte ein + in meinem Geheimnis, was diesen Fehler immer noch verursachte. Das Erstellen neuer Schlüssel ohne Sonderzeichen hat das Problem behoben.

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

Hatte ein + und ein / in meinem Geheimnis. Geheimnisse ohne diese haben das Problem für mich gelöst.

Hatte dieses Problem auch.

$ 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

Hatte ein "+" in den Anmeldeinformationen. Wurde durch Neugenerieren des Zugriffsschlüssels ohne sie behoben. Als Anmerkung: "/" ist ein schönes Zeichen.

@adityanatraj @shwetapurushe @damienrj könnt ihr alle diese Fragen hier beantworten? An dieser Stelle versuchen wir, weitere Informationen über Ihre Umgebung und die Eingabe von Anmeldeinformationen zu erhalten. Wie in diesem Kommentar erwähnt, reproduziert das Generieren eines geheimen Schlüssels mit + das Problem für uns nicht, daher hängt es möglicherweise mit einer Kombination aus Ihrer Umgebung und/oder der Eingabe von Anmeldeinformationen zusammen.

Mit anderen Worten, wir brauchen mehr Informationen von den Leuten, damit wir Fehler beheben können.

@jamesls

1. Wie habe ich die Zeugnisse bekommen?

Ich habe die Anmeldeinformationen erhalten, indem ich sie von der Webkonsole kopiert habe.

1. Wie konfiguriere ich CLI, um sie zu verwenden?

Ich habe die beiden Dateien manuell erstellt:

~/.aws/config

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

~/.aws/credentials

[default]
aws_access_key_id = ACCESS_KEY_HERE 
aws_secret_access_key = SECRET_ACCESS_KEY_THAT_BREAKS_WITH_A_+_SIGN

Entschuldigung, ich kann bei den Bonusfragen nicht helfen, da ich meine Zugriffsschlüssel mit "+"-Zeichen gelöscht habe, sodass das Problem nicht auftritt.

@adityanatraj danke, jedes bisschen hilft.

Der nächste Schritt, der uns bei der Fehlerbehebung helfen würde, besteht darin, herauszufinden, ob dies nur ein Problem mit der CLI oder ein Problem mit den Anmeldeinformationen selbst ist. Für alle, bei denen dieses Problem immer noch auftritt, wäre es sehr hilfreich, wenn Sie diese Anmeldeinformationen in anderen AWS SDKs ausprobieren könnten. Um dabei zu helfen, habe ich ein Beispiel-Repo/Skript zusammengestellt, das dies einfach macht, wenn Sie dies nicht selbst einrichten möchten: https://github.com/jamesls/aws-creds-test . Klonen Sie einfach das Repository und führen Sie 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.

Für Personen, die auf dieses Problem stoßen, führen Sie bitte das Testskript aus und geben Sie die Ausgabe frei.

Dieselbe Ausnahme ist mir bei einer PutObject-Anforderung (C#) passiert, wenn die Objektmetadaten Unicode-Zeichen enthielten.

Ich hatte das gleiche Problem. Neue geheime Schlüssel mit + und / funktionieren nicht. Ich habe neue Schlüssel ohne diese Zeichen generiert und sie funktionieren gut.
Ihr Testskript ist für Linux und ich verwende Windows.
Ich habe meine Anmeldeinformationen mit Control-C und Control-V mit Windows-Shell und _aws configure_ eingefügt.
und ich habe nur _aws cp_ verwendet

Habe dies auch getestet und es funktioniert gut, solange der geheime Schlüssel keine Symbole hat, wie oben erwähnt.

Ich hoffe, dass dies bald behoben wird. Es ist mühsam, Anmeldeinformationen zu regenerieren, bis ich eine habe, die funktioniert!

Ich habe gestern ein Support-Ticket an AWS gestellt und heute scheint es gelöst zu sein

Habe ich mehrfach getestet und + und/scheint beides jetzt zu funktionieren? Ich kann diesen Fehler nicht mehr reproduzieren.

Ich hatte das gleiche Problem auf meinem Pi.
Mit dem neusten awscli (aws-cli/1.11.85 Python/3.4.2 Linux/4.9.24-v7+ botocore/1.5.48) hatte ich noch das Problem:

root@pi :~# aws s3 ls s3://
Beim Aufrufen des ListBuckets-Vorgangs ist ein Fehler aufgetreten (SignatureDoesNotMatch): Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen bereitgestellten Signatur überein.
Überprüfen Sie Ihren geheimen Zugriffsschlüssel und die Signaturmethode. Weitere Informationen finden Sie unter REST-Authentifizierung und SOAP-Authentifizierung für Details.

Auch mit einem geheimen Schlüssel ohne Sonderzeichen (+ oder /) funktionierte der Zugriff nicht. Die Uhrzeit war immer synchron, leider war das auch nicht das Problem.

In der Datei ".aws/config" habe ich eine gültige Region hinzugefügt (nur zum Testen..) und plötzlich funktionierte es. Da ich kompatiblen s3-Speicher verwende (nicht s3 von Amazon)

[Ursprünglich]
aws_secret_access_key = MYKEY
aws_access_key_id = MEINEID
region = us-east-1 <-- Es gab vorher einen "Dummy"-Wert.

Wie es aussieht, muss die Region einen "richtigen" Wert haben. Wenn ich es wieder in etwas anderes wie "dummyvalue" ändere, erhalte ich den gleichen Fehler wie oben erwähnt.
Mit dem Wert "us-east-1" funktioniert es jetzt!
Hoffe das hilft jemandem.

Ich bin auch gerade darauf gestoßen. Scheint auch ein Problem mit einem '+' im geheimen Schlüssel zu sein. Wenn ich die Creds in Umgebungsvariablen habe, erhalte ich den Fehler. Wenn ich sie in die Datei ~/.aws/credentials einfüge (durch manuelle Bearbeitung), erhalte ich den Fehler nicht.

[Bearbeiten] Habe gerade bemerkt, dass sich die Umgebungsvariablen in einer Datei befinden, die für dos formatiert ist (ff=dos in vim). Dies lag daran, dass ich die .csv-Datei gerade heruntergeladen und bearbeitet hatte, um die Einträge in Umgebungsvariablen zu ändern. Als ich die Datei in 'ff=unix' neu formatierte, bekam ich den Fehler nicht mehr. Der einzige Unterschied zwischen den 2 ist der Zeilenumbruch, dos verwendet "CR-NL", während Unix nur "NL" ist. Ich vermute, dass es tatsächlich das "CR"-Zeichen war, das das Problem war.

ich auch, und bestätige auch das "+"-Problem

Wenn Sie bei der Verwendung von Docker für Mac darauf stoßen, können Sie Docker einfach neu starten, um die Systemzeitabweichung zu beheben.

Ich stand vor dem gleichen Problem.
Habe das Geheimnis überprüft und es hatte +/ drin.
Musste ein neues ID-Paar ohne Sonderzeichen erstellen, damit es funktioniert

Das Erstellen neuer Schlüsselpaare, bis ich eines ohne Sonderzeichen hatte, löste es auch für mich; Sonderzeichen (insbesondere +) funktionieren in ~/.aws/credentials einfach nicht.

Generierter Schlüssel ohne Sonderzeichen (insbesondere + ) hat das Problem auch für mich behoben.

Das Formatieren der Datei gemäß dem Kommentar von

Das Löschen des Schlüssels und das Erstellen eines neuen hat bei mir funktioniert.

Habe gerade diesen Fehler erhalten. Aktualisierte Systemzeit, die mehr als 6 Minuten von GMT entfernt zu sein schien. Das Problem wurde sofort behoben.

Es war so seltsam und schwierig für mich.
Ich hatte mit diesem Problem zu kämpfen und habe viele Male versucht, es zu lösen.
Im Moment hat es plötzlich funktioniert! Ich war überrascht, also habe ich einen neuen Eimer gemacht, aber es hat nicht funktioniert. Da ich nichts getan hatte, außer den Code zu ändern, wartete ich einfach stundenlang. Endlich hat es gut funktioniert, obwohl ich nichts gemacht habe. ich kann es nicht glauben...

Als ich aws configure in einer Bash-Shell unter Windows 7 benutzte, stellte ich fest, dass ich zwei aws_secret_access_key Zeilen in meinem .aws/credentials und die zweite Zeile war, wo ich eine Menge Müll falsch eingegeben hatte . Habe die zweite Zeile gelöscht und alles funktioniert.

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

Ich sehe dieses Problem auf Linux Mint hier, ohne + in meinem Schlüssel oder Geheimnis.

Ausgabe des Testskripts:

/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

Nach dem Upgrade von awscli auf 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

Ich habe gerade meine Schlüssel neu erstellt - Mein neuer enthält immer noch ein '+', kann aber jetzt den cli . verwenden

Könnte so einfach sein

@ DanAbbz92 in der Tat, ich habe jetzt zufällig die gleiche Lösung gefunden. Keine Ahnung, warum die alten Schlüssel nie funktionierten, aber die neuen waren nach dem gleichen Verfahren in Ordnung.

Ich hatte ein ^V in meinem geheimen Schlüssel von einem fehlerhaften Einfügeversuch. Es kann ratsam sein, eine stärkere Warnung bei der Überprüfung auf fehlerhafte Zeichen in den Schlüsseln auszusprechen. Wird weitere unnötige Eskalationen verhindern.

Dieses Problem wurde 2014 gemeldet. Heute ist der 26. Oktober 2017. Ich bin auf dieses Problem gestoßen, mein Geheimnis hatte ein "+". Ich habe einen neuen Schlüssel erstellt und in ~/.aws/configure . abgelegt
Komm auf Amazon, hast du jemals vor, diesen Fehler zu beheben

Ich bin heute auf dieses Problem gestoßen, nachdem ich die cli installiert und aws configure . Meine Schlüssel enthielten keine Sonderzeichen, aber das Folgende hat mein Problem behoben:

• rm -r ~/.aws/
• den .aws-Ordner und die credentials Datei neu erstellt und die Anmeldeinformationen manuell wieder hinzugefügt

tl;dr aus- und wieder einschalten hat bei mir funktioniert ¯_(ツ)_/¯

Für Leute, die Hadoop verwenden, die hier landen: Ein verwandter Fehler wurde für Hadoop 2.8.0 behoben:
" s3:" URLs werden unterbrochen, wenn der geheime Schlüssel einen Schrägstrich enthält, selbst wenn sie codiert sind

Hallo, heute habe ich das gleiche Problem.
Auf der Box stand die falsche Uhrzeit. Nach der Aktualisierungszeit funktioniert alles.

Hinzufügen eines weiteren "ich auch"

Ich hatte einen geheimen Schlüssel mit zwei '+'-Zeichen und der funktionierte von meiner .aws/credentials-Datei auf meiner Windows-VM (bei Verwendung von einer .NET-Anwendung), aber als ich awscli von brew auf meinem MacBook Pro installiert habe , und kopierte die .aws-Dateien (Testen auf Dateicodierungen, Zeilenendeformate usw.), schlug mit SignatureDoesNotMatch fehl.

Ich habe versucht, die Anmeldeinformationen neu zu erstellen, bis ich einen geheimen Schlüssel ohne Nicht-Alphanumerik erhalten habe, und jetzt funktioniert es über die awscli auf meinem Mac. Diese Anmeldeinformationen zurück auf meinen Windows-Rechner zu kopieren und die .NET-Anwendung auszuführen, funktioniert immer noch.

Ich habe auf beiden Computern keine Änderungen an der Zeit vorgenommen (der Mac verwendet bereits NTP und die Windows-VM sieht so aus, als ob sie etwa 12 Minuten hinter der tatsächlichen Zeit läuft)

Ich habe awscli installiert mit: brew install awscli

und aws --version gibt zurück: aws-cli/1.14.30 Python/3.6.4 Darwin/16.7.0 botocore/1.8.34

Nun, ich habe heute Nachmittag Code auf Lambdas übertragen (2018-02-01 15:48 EST mit Lambda in us-east-1).
Jetzt um 18 Uhr erhalte ich auf jedem System im Büro Signaturfehler.
Rückblickend auf diesen Thread: Meine Zeiten sind korrekt, nichts hat sich geändert, Anmeldeinformationen sind weniger als ein Jahr alt, funktionieren seit dem Tag ihrer Einrichtung, verwenden die Homebrew-Version aws-cli/1.14.30 Python/3.6.4 Darwin/17.4.0 botocore/1.8.34 (versuchte ein Downgrade auf 1.14. 2x Version, keine Liebe)

Das ist malarky

Habe das gleiche Problem und das Generieren neuer Schlüssel ohne Sonderzeichen (wie /, + usw.) gelöst.

Danke an @hellais für den Input!

Hatte gerade das gleiche Problem, habe es durch Korrigieren der Uhr meines Laptops gelöst. Offenbar war ich in Verzug.

Ich habe gerade dieses Problem erlebt und es scheint, dass mein NTP-Client 10 Minuten im Rückstand war. Ich habe ein ntpdate gemachtund alles ist jetzt behoben.

Ich kann bestätigen, dass es funktioniert hat, meine Zugangsschlüssel neu zu erstellen, bis ich einen ohne Sonderzeichen darin habe. Was für ein lächerlicher Fehler, wow.

Da dies ein so lange andauerndes Problem ist, wäre es nicht klug, die Fehlermeldungen zu aktualisieren, um den Benutzern einen Link zu einer möglichen Fehlerbehebung zu geben, z. B. um Ihre Schlüssel neu zu erstellen? Anstelle von etwas, das darauf hindeutet, dass das Problem viel komplexer ist als "Ja, wir haben einen Fehler, wenn Ihre Schlüssel Sonderzeichen enthalten, sorry!".

gleiches Problem hören:

Versionen:

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

Befehl:

aws s3 ls
habe folgenden Fehler erhalten:
Unknown Signature Version: s3v3.

keine Lösung:

Ich habe meinen Umhang aktualisiert und erstelle ein Geheimnis ohne besonderen Charakter

Update - behoben durch folgendes

aws configure set default.s3.signature_version s3v4

Ja, das ist immer noch ein Problem - mein geheimer Schlüssel endete mit einem + Zeichen und keine Lösung, die meiner Meinung nach funktionierte. Neue Schlüssel ohne + am Ende des geheimen Schlüssels neu generiert und es hat gut funktioniert.

Wie um alles in der Welt ist das noch ein Thema?

Beim Aufrufen des CreateMultipartUpload-Vorgangs ist ein Fehler aufgetreten (SignatureDoesNotMatch): Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen bereitgestellten Signatur überein. Überprüfen Sie Ihren Schlüssel und die Signaturmethode.
bitte helfen.

Mein Geheimnis beginnt mit dem Zeichen + und ich wusste bis heute nicht, dass es dieses Problem gibt. Ich verwende Boto3-Python, um auf mein s3 zuzugreifen. Es funktioniert nicht, wenn ich Anmeldeinformationen als Rohstrings übergebe, aber es funktioniert gut, wenn ich es aus config.ini als Variable mit configparser.RawConfigParser() lade. Natürlich löst auch das Generieren eines neuen Secrets ohne + Zeichen am Ende oder am Anfang dieses Problem.

Wenn dies jedoch (aus irgendeinem Grund) nicht behoben werden kann, ändern Sie die Ausnahmemeldung möglicherweise in etwas wie "Wir erlauben kein +-Zeichen, generieren Sie eine neue, wenn Sie auf diese Weise darauf zugreifen möchten".

Ich verwende aws cli auf osx und hatte auch ein Geheimnis, das nicht richtig zu sein schien. Mein ursprüngliches hatte ein + und ein = darin und ich erhielt den SignatureDoesNotMatch Fehler beim Versuch, cp Dateien in s3 zu übertragen. Ich habe Schlüssel neu generiert und mein neues Geheimnis ist jetzt eine alphanumerische Zeichenfolge. Fügen Sie einfach eine weitere Bestätigung hinzu, dass die Regeneration funktioniert. :erleichtert:

In der Hoffnung, dass dies Aufschluss geben könnte, zeigt sich dieses Problem (das + in geheimen Schlüsseln nicht behandelt) mit dieser Version auf 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

tritt aber bei dieser Version unter Ubuntu nicht auf

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

Begann im Januar 2014 und jetzt im Juni 2018, über 4 Jahre und ich hatte das gleiche Problem mit dem Fehler SignatureDoesNotMatch . Die Lösung für mich war die gleiche wie bei allen Mehrheitslösungen hier, einen neuen geheimen Schlüssel ohne Sonderzeichen erhalten, da mein früherer Schlüssel einen Doppelpunkt hat : , versuchte die Zeitsynchronisierung, funktionierte jedoch nicht für mich. Ich verwende WSL.

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

Nur aktualisieren, was @gchiu im April 2017 sagte: Es ist immer noch im Juni 2018 der Fall, dass Geheimnisse mit dem Schrägstrich (/) dazu führen können, dass der PHP-Client nicht funktioniert (PHP 7 unter Windows 10 in meinem Fall) _Signaturen stimmen nicht überein_ Fehler. Generieren Sie in dieser Situation einfach ein anderes, sichereres Schlüsselpaar.

Ich war ungefähr 30 Minuten davon verblüfft.

Habe dieses Problem verfolgt und die Ortszeit usw. überprüft - alles war gut.

In meiner Verzweiflung die ~/.aws/credentials Datei zerstört und erneut angemeldet (im Wesentlichen die Datei neu erstellt) und voila, funktioniert einfach.

Frage mich, warum es diesen Fehler überhaupt auslöst!

BEARBEITEN:
Scheint in meinem Fall nicht mit dem geheimen Schlüssel zusammenzuhängen; es waren alles meist einfache Saiten.

+1 zu diesem Problem, mein Schlüssel begann mit = . Einen Schlüssel neu generiert, der nur ein / enthielt und alles war gut. Ich habe versucht, den Schlüssel in " Markierungen einzuschließen, aber ohne Erfolg.

Nicht etwas, was ich von der AWS CLI erwarten würde.

Wenn ich das gleiche Problem hier hinzufüge, kann ich nicht glauben, dass das / in meinem Schlüssel dies verursacht hätte. Danke für die verschwendete Zeit!

Ich hatte dieses Problem. Ich glaube, es war das Ergebnis der anfänglichen Installation der AWS-Cli als Root-Benutzer. Die Lösung schien darin zu bestehen, die aws-cli zu deinstallieren, sowohl den .aws-Ordner im Home-Ordner des aktuellen Benutzers als auch im Stammordner zu löschen und dann 'aws configure' erneut als aktueller Benutzer auszuführen.

Ich habe dieses Problem beim Ausführen eines Bash-Skripts mit einem systemd-Timer auf Ubuntu festgestellt. Beim manuellen Ausführen des Skripts mit meinem Benutzer hat alles gut funktioniert. Der Timer würde jedoch weiterhin den Fehler (SignatureDoesNotMatch) ausgeben. Ich bemerkte dann, dass (SignatureDoesNotMatch) für jeden als Root ausgeführten aws-Befehl erstellt wurde und dass 'aws configure' keine neuen bereitgestellten Werte speicherte.

Um das Problem zu beheben, habe ich mich als root 'su -i' angemeldet, zu 'cd ~/.aws/' geändert und die Konfiguration mit 'sudo rm -r Credentials' entfernt, 'aws configure' erneut ausgeführt und diesmal die neuen Werte wurde gerettet. Ab da funktionierte wieder alles wie erwartet!

Kann bestätigen, dass dieses Problem unter aws-cli/1.15.4 Python/2.7.15rc1 Linux/4.15.0-42-generic botocore/1.12.8 weiterhin besteht.

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.

Und es stellte sich heraus, dass in meinem Geheimnis ein + steckte. Ich habe mich regeneriert und jetzt ist alles in Ordnung. Wann können wir mit einem Fix für dieses @jamesls rechnen? Oder kann ich irgendwie helfen?

Das gleiche in meiner aws-cli, weil der geheime Schlüssel + enthielt ... (wie oben beschrieben) Nach dem Regenerieren eines neuen Schlüssels ... (wie ich aus dem Kommentar von delmartechdude oben gesehen habe). ... das Problem gelöst worden.

Meine zwei Cent. Es gab mir diesen Fehler, weil ich versuchte, Inhalte mit beschleunigten Übertragungen auf diese Weise auf s3 hochzuladen (in der Vergangenheit funktionierte es): --endpoint-url http://imaat.s3-accelerate.amazonaws.com ( --endpoint-url http://<bucket-name>.s3-accelerate.amazonaws.com ) wie in den Eigenschaften des Beschleunigungsendpunkts angegeben :

Befolgen Sie die Anweisungen in den offiziellen Dokumenten: https://docs.aws.amazon.com/es_es/AmazonS3/latest/dev/transfer-acceleration-examples.html Ich habe den letzten Teil ersetzt durch: --endpoint-url http://s3-accelerate.amazonaws.com und führe den Befehl aus aws configure set s3.addressing_style virtual um den Hostnamen dynamisch aufzubauen. Überprüfen Sie: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#addressing -style

Ich weiß nicht warum, aber jetzt funktioniert es. Mein Bucket-Name ("imaat") hat keine Sonderzeichen, die zu DNS-Fehlern führen können, aber bei den neuesten CLI-Updates ist er aus irgendeinem Grund fehlgeschlagen.

Beim Hinzufügen eines Profils per Textbearbeitung wurde dieser Fehler aufgetreten. Aktualisieren der Profilzugriffs-ID und des Geheimnisses über einen AWS-Konfigurationssatz und es hat funktioniert. Dies ist für ein Geheimnis mit '+' darin und aws-cli/1.16.23 Python/2.7.15 Windows/10 botocore/1.12.13

@dave-miles Du bist auf der Suche nach etwas, danke für deinen Kommentar! Ich erweitere Ihren Befund unten:

Ich bin auf dieses Problem mit einigen Docker-Images gestoßen. Ursprünglich habe ich ein ADD im Dockerfile verwendet, um die Datei ~/.aws/credentials in den Container einzufügen.

Wenn wir dies tun würden, würden wir beim Versuch, von s3 herunterzuladen, auf den SignatureDoesNotMatch-Fehler stoßen.

Ich habe die ADD-Zeile im Dockerfile entfernt, neu aufgebaut und einen neuen Docker-Container gestartet. In diesem neuen Container habe ich aws configure set aws_access_key_id <access key id goes here> und aws configure set aws_secret_access_key <secret access key goes here> manuell ausgeführt. Dies war das erste Mal, dass die Anmeldeinformationen in diesem Container eingegeben wurden (dh der Container war ein "frisches" Centos-Image).

Nachdem ich die aws configure set Befehle verwendet hatte, konnte ich erfolgreich von s3 herunterladen.

Für jeden, der dies mit einer Dockerdatei verwendet, können Sie RUN-Anweisungen in der Dockerdatei verwenden, um die beiden Befehle auszuführen, oder Sie können eine ADD-Anweisung verwenden, um ein Skript in Ihren Docker-Container zu verschieben:

#!/bin/sh

aws konfigurieren set aws_access_key_id _access-key-id-goes-here_
aws konfigurieren set aws_secret_access_key _secret-access-key-goes-here_

Ich hatte das gleiche Problem wie @villasenor - ein + im geheimen Schlüssel würde den Fehler beim Konfigurieren des awscli mit env vars im Docker verursachen. Drehen der Tasten hat das Problem behoben.

Dito hier, aber es gibt keine Sonderzeichen im Zugangsschlüssel oder geheimen Schlüssel.
Ein neues Set für denselben IAM-Benutzer neu generiert, und die neuen können Buckets auflisten, die alten nicht.

Dies trat sowohl bei AWS cli- als auch bei Java SDK-Aufrufen auf. Die Vermutung, dass der Fehler nicht in den Clients liegt ...

Beide Sets sind noch live. Wenn jemand bei Amazon mehr Details wissen möchte, bitte Kontakt aufnehmen.

Das ist meinem Kollegen auch gerade aufgefallen. Ich habe versucht, zu debuggen, indem ich einen Zugriffsschlüssel erstellt habe, bis ich einen mit einem + oder / am Anfang erhalten habe. Konnte aber nicht reproduzieren.

Ich habe das bei einem Kollegen erlebt. Wir haben festgestellt, dass dies speziell bei Ubuntu 18.04 mit + oder / im geheimen Schlüssel auftritt.

Habe heute den gleichen Fehler erhalten, derzeit mit Windows 10. Wenn ich jedoch denselben Zugriffsschlüssel auf einem anderen Laptop (Mac) verwende, funktioniert es bei mir einwandfrei. Dann habe ich den Zugangsschlüssel innerhalb von WSL ausprobiert, was auch in Ordnung ist. Ich bin mir nicht sicher, warum, und der AWS-Schlüssel enthält kein Sonderzeichen.

Ich habe diesen Fehler mit einem Satz Zugriffsschlüssel und nicht mit dem anderen.
Wie in mehreren anderen Beiträgen erwähnt, ist hier mein Schlüssel als '/' drin. Für mich scheint dieses Problem ein einfaches Problem zu sein, bei dem entweder der Server oder die Clients den RFC-URI-Kodierungsstandard kodieren/dekodieren und der andere ihn nicht verwendet.
Ich plane, diese erwähnten Testskripte auszuführen und zu versuchen, Fehler zu reproduzieren.

Für andere Leute hier ist der Fehler aufgetreten, aber ich hatte falsche Anmeldeinformationen in meinem Ordner ~/.aws. Es sucht dort zuerst und dann nach Umgebungsvariablen.

Ich erlebe dies unter Windows 10 mit Git Bash. Mit Powershell funktioniert es einwandfrei. Der Python-Aufruf ist offensichtlich anders, aber es ist dasselbe Python- und Python-Modul. Ich habe auch + und / in meinem Schlüssel.

Ich hatte gerade dieses Problem und für mich bestand die Lösung darin, die Leerzeichen zu entfernen. Beispiel.
statt der Vorgabe von:
[profilename]
aws_access_key_id = MYAWSACCESSKEYID
aws_secret_access_key = MYAWSSECRETACCESKEY
Ich habe es geändert in:
[profilename]
aws_access_key_id=MYAWSACCESSKEYID
aws_secret_access_key=MYAWSSECRETACCESKEY

Beachten Sie das Fehlen von Leerzeichen um das =. Dies hat es für mich behoben und ich habe + und / in meinem Schlüssel übrigens auch.

Alles in allem gibt es hier einige großartige Tipps zur Fehlerbehebung. Ich werde diese im Abschnitt Fehlerbehebung im CLI-Benutzerhandbuch in eine Seite umwandeln. Danke für die Beiträge!

Hallo zusammen,

Ich sehe, dass es hier viele Antworten gibt, aber für mich waren es die Sonderzeichen im AWS Secret Access Key. Meins begann mit "=+", aber als ich ein neues ohne Sonderzeichen aus der Webkonsole generierte, funktionierte es sofort.

Ich führe awscli in einer Zsh-Shell unter Ubuntu unter Windows aus:

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

Ich hoffe, das ist hilfreich für andere.

Danke
Jonathan

Habe gerade 4 Stunden Debugging darin versenkt, bis ich diesen Thread gefunden habe. Ich konnte die s3-Cli lokal ohne Probleme verwenden, aber beim Ausführen in Circleci bekam ich diesen Fehler: SignatureDoesNotMatch ..

Wie andere vorgeschlagen haben, enthielt mein geheimer Zugangsschlüssel ein + Zeichen, und nachdem ich einen neuen Schlüssel generiert hatte, begann alles zu funktionieren.

Ohne diesen Thread wäre das Debuggen fast unmöglich gewesen

Danke @blbradley . Es war genau das Problem, das ich hatte.

hatte das gleiche Problem - die Lösung bestand darin, Windows-Umgebungsvariablen mit veralteten AWS-Anmeldeinformationen zu löschen

Ich hatte das Problem auch auf Python3 boto3.
Meins beginnt mit =/

Ich bin in einer virtuellen Maschine, die Zeit und Region des Hosts ähnlich der Zeit und Region des Gastes macht, um das Problem zu lösen.

Wollte nur einstimmen, dass mich das heute auch auf einem neu erstellten Schlüssel traf - und nach viel Frust hier gelandet und sah, dass ein / im Schlüssel erwähnt wurde. Tatsächlich war das das Problem - neuer Schlüssel ohne funktioniert. Wtf?!

Ich kann nicht glauben, dass dieses Problem 2014 eröffnet wurde und es immer noch keine Lösung dafür gibt. Dieser Fehler hat mich gezwungen, einen neuen Satz AWS-Anmeldeinformationen für mich selbst zu erstellen, ich habe sogar versucht, das '/' zu codieren, aber es hat nicht funktioniert :(

Das Entfernen der Anmeldeinformationen mit dem "/" hat das Problem für mich behoben. Danke an alle für den Hinweis.

Einfach jetzt im Jahr 2020 treffen. Geheimschlüssel hat ein '+'.

aws-cli — entwickelt von aws project — scheitert mit gültigen aws-Schlüsseln... für 6 Jahre?

Gleiches Problem im Januar 2020. Der geheime Schlüssel hat einen Schrägstrich "/".

Ich habe mithilfe der AWS IAM-Konsole einen neuen Satz von Anmeldeinformationen generiert und sichergestellt, dass der geheime Schlüssel vollständig alphanumerisch war, kein "/", kein "+" usw. Ich habe meinen alten geheimen Schlüssel durch den neuen geheimen Schlüssel in meiner Datei ~/.aws/credentials ersetzt und es dann erneut versucht.

Dies hat es gelöst.

Gleiches Problem hier im Jahr 2020. Aber ich kann keine alphanumerischen Zeichen entfernen, da sie Teil meiner Anmeldeinformationen selbst sind, und ich habe keine Kontrolle darüber.

Generieren Sie einfach die Anmeldeinformationen, bis Sie die Zeichen loswerden. Es dauert normalerweise nur ein oder zwei weitere Versuche.

Maurice

Von: columb1a [email protected]
Gesendet: Dienstag, 21. Januar 2020 13:47
An: aws/aws-cli [email protected]
Cc: Maurice Bizzarri [email protected] ; Kommentar [email protected]
Betreff: Re: [aws/aws-cli] SignatureDoesNotMatch-Fehler (#602)

Gleiches Problem hier im Jahr 2020. Aber ich kann keine alphanumerischen Zeichen entfernen, da sie Teil meiner Anmeldeinformationen selbst sind, und ich habe keine Kontrolle darüber.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an 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 & reserviert = 0 oder abmelden 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 .

Ich hatte zum ersten Mal Zeitüberschreitungsprobleme und nach der Aktualisierung meiner awscli trat dieses Problem auf. Sie dachten, 6 Jahre reichen aus, damit es funktioniert...

Ich habe auch diese Vue.js-App über gitlab im AWS S3-Bucket bereitgestellt. Kann mir jemand sagen, was zu tun ist?
msg:fatal error: Beim Aufrufen der ListObjectsV2-Operation ist ein Fehler aufgetreten (SignatureDoesNotMatch): Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen angegebenen Signatur überein. Überprüfen Sie Ihren Schlüssel und die Signaturmethode.

Ich hatte keine nicht-alphanumerischen Zeichen, aber das Arbeiten mit Profil funktionierte für ein einzelnes Profil nicht. Ich habe die Anmeldeinformationen mit der Konsole neu generiert und die neuen haben gerade funktioniert.

Auch heute noch solche Fehler zu bekommen und die Anmeldeinformationen ohne Sonderzeichen ('+' oder '/') neu zu generieren, funktioniert für mich.

Ich habe immer noch das gleiche Problem, aber es passiert plötzlich, ich arbeite mit Get- und Put-Operationen und einer funktioniert, der andere nicht. und ja, mein geheimer Schlüssel enthält keine Sonderzeichen. irgendeine Hilfe? Ich rufe zuerst getIntent (Amazon Lex-Modell-API) auf, um die Prüfsumme der Intents abzurufen, und rufe dann putIntent auf, um diese Intent zu aktualisieren. Die Get-Methode funktioniert (nicht immer), aber die Put-Methode zeigt das gleiche Problem der Signatur, während wenn ich die Get-Methoden-API aus dem Code entfernt habe, die Put-Methode 2 von drei Mal funktioniert.

Ich hatte dieses Problem, ich empfehle Ihnen, neue Schlüssel zu generieren
und konfigurieren Sie Ihr AWS-Profil neu

aws konfigurieren

AWS-Zugriffsschlüssel-ID [ * * * * QD5E]: AWS_ACCESS_KEY_ID
AWS Secret Access Key [ * * * * ANjA]: AWS_SECRET_ACCESS_KEY
Standardregionsname [eu-west-3]: AWS_REGION
Standardausgabeformat [json]: OUTPUT_FORMAT

Hallo !

Ich erhalte dasselbe Problem, wenn ich eine vorsignierte URL verwende, die an meinen Client zurückgegeben wird
Die URL wird im Server generiert (für eine begrenzte Zeit). Der Server ist Python und ich sehe dort keinen Fehler, aber der Client ist JS - ruft nur die URL ab und öffnet sie. Ein Teil der URL sind generierte Anmeldeinformationen für diese Ressource)

Der Fehler ist ein und aus, daher denke ich, dass er mit dem zusammenhängt, was hier über spezielle Schlüssel in den Anmeldeinformationen gesagt wird, aber da ich Anmeldeinformationen verwende, die auf dem Server generiert wurden, kann ich sie nicht ändern!

Gibt es eine Möglichkeit, dies im Code zu berücksichtigen? die Sonderschlüssel irgendwie parsen?

Hallo !

Ich erhalte dasselbe Problem, wenn ich eine vorsignierte URL verwende, die an meinen Client zurückgegeben wird
Die URL wird im Server generiert (für eine begrenzte Zeit). Der Server ist Python und ich sehe dort keinen Fehler, aber der Client ist JS - ruft nur die URL ab und öffnet sie. Ein Teil der URL sind generierte Anmeldeinformationen für diese Ressource)

Der Fehler ist ein und aus, daher denke ich, dass er mit dem zusammenhängt, was hier über spezielle Schlüssel in den Anmeldeinformationen gesagt wird, aber da ich Anmeldeinformationen verwende, die auf dem Server generiert wurden, kann ich sie nicht ändern!

Gibt es eine Möglichkeit, dies im Code zu berücksichtigen? die Sonderschlüssel irgendwie parsen?

@maya-harel Sie können die Anmeldeinformationen von IAM ändern -> Benutzer wählen den von Ihnen erstellten Benutzer aus und generieren die Registerkarte Sicherheitsanmeldeinformationen für den geheimen Schlüssel neu.

Auch das Timing im Code ist wirklich fatal. Rufen Sie für jede Anfrage, die Sie im Back-End stellen, die aktuelle Zeit ab, um sie im Header zum Generieren der Signatur zu verwenden.

Abgesehen davon gab es viele blinde Vorschläge zur Neugenerierung Ihrer IAM-Anmeldeinformationen für Benutzer, die ausdrücklich gesagt haben, dass dies keine Option für sie ist.

Dies ist für die Benutzer nicht hilfreich und lenkt von der Tatsache ab, dass dies ein bekannter Fehler ist, der weiterhin aws-cli-Benutzer betrifft, die versuchen, gültige IAM-Anmeldeinformationen zu verwenden.

Läuft auch darauf ein.
$ aws --version
aws-cli/1.16.300 Python/2.7.16 Linux/4.14.152-127.182.amzn2.x86_64 botocore/1.13.36

Meine Tasten sind komplett alphanumerisch, keine Sonderzeichen.

Die Schlüssel funktionieren von der Shell aus, wenn sie jedoch über Jenkins in einem Makefile-Ziel verwendet werden, tritt dieser Fehler auf. Nicht sicher, was hier passiert.

Mein geheimer Schlüssel enthält sowohl / als auch + . Ich bin auf dieses Problem gestoßen und habe versucht:

• Durch aws-cli > aws iam get-user (unter Verwendung der ~/.aws/credentials Datei)
• boto3 (über Python 3.6.8)
  
  
  
  • Hartcodierte Schlüssel
  
  
  • Umgebungsvariable
  
  
  • Argument boto3.Session(profile_name=PROFILE) (das aus ~/.aws/credentials gezogen wird)
  
  

All dies führt zum Fehler SignatureDoesNotMatch .

Ich kann den Schlüssel derzeit nicht regenerieren.

Was ich nicht verstehe ist, dass ich das S3-Protokoll in Cyberduck (https://cyberduck.io/) verwenden kann und es wie erwartet funktioniert. Wie kann das sein?

Dies muss einer der frustrierendsten Fehler sein, auf die ich gestoßen bin, und es ist verrückt, dass er nicht behoben wurde. Ein Cred ohne "+" zu bekommen hat bei mir in CircleCI funktioniert.

Stürzt es immer noch ab? habe das selbe problem, wow kann ich nicht machen...

Ja, es ist frustrierend. Mein geheimer Schlüssel mit einem + funktionierte in einer Jenkins-Pipeline nicht, aber als ich einen neuen generierte, der nur wenige / , funktionierte es gut.

Ich hatte dieses Problem bei der im Paket installierten Version von awscli unter Ubuntu 16.04. Ich habe es behoben, indem ich awscli als Python-Pip-Paket installiert habe.
Für Anweisungen folgen Sie diesem Link im Abschnitt Installieren von AWS CLI mit Python PIP

_ Aufgetretenes Problem _

1) Der InvalidSignatureException- Fehler ist nach dem Regenerieren des Zugriffsschlüssels aufgetreten
2) Das partielle Fehlerprotokoll ist wie unten angegeben.

$ python SetupAWS.py list_things
Traceback (letzter Anruf zuletzt):
Datei "SetupAWS.py", Zeile 222, in
list_things()
Datei "SetupAWS.py", Zeile 182, in list_things
Dinge = client.list_things()['Dinge']
Datei "c:Program Files (x86)Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", Zeile 316, in _api_call
return self._make_api_call(operation_name, kwargs)
Datei "c:Program Files (x86)Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", Zeile 626, in _make_api_call
raise error_class(parsed_response, operation_name)
botocore.Exceptions.ClientError: Beim Aufrufen der ListThings-Operation ist ein Fehler aufgetreten (InvalidSignatureException): Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen bereitgestellten Signatur überein. Überprüfen Sie Ihren AWS Secret Access Key und die Signaturmethode. Weitere Informationen finden Sie in der Servicedokumentation.

_ Ursachenanalyse _

1) Wie von vielen in ihren obigen Kommentaren vorgeschlagen, führte das Vorhandensein von "+" in meinem geheimen Zugriffsschlüssel zu dem obigen Fehler.

_ Auflösung _

1) Als IAM-Benutzer einen neuen Zugriffsschlüssel generiert und überprüft, dass der neue geheime Zugriffsschlüssel kein "+" in der Zeichenfolge enthält.
2) Führen Sie den Befehl aws configure aus und stellen Sie die neuen Werte bereit.
3) Führen Sie den SetupAWS.py list_things aus , der mein Ding erfolgreich aufgelistet hat, wie unten gezeigt.

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

Diese Ausgabe ist seit sechs Jahren offen, und ich danke Ihnen für Ihre Geduld, Beharrlichkeit und die von Ihnen bereitgestellten Informationen. Einige der zugrunde liegenden Ursachen wurden durch Ihre Kommentare (https://github.com/aws/aws-cli/issues/602#issuecomment-520469209) identifiziert und in das Kapitel Fehlerbehebung des Befehlszeilen-Benutzerhandbuchs zusammengestellt. Zu diesen Ursachen zählen Taktversatz und die falsche Handhabung von Tasten mit Sonderzeichen durch einige Betriebssysteme.

Ich habe versucht, dies in verschiedenen Umgebungen zu reproduzieren. Ich habe Ubuntu 16.04, Ubuntu 18.04 und Amazon Linux 2 mit Python 3.6.8 und 3.8.3 verwendet. Während viele Kommentatoren Python 2 verwendet haben, habe ich nicht versucht, es zu reproduzieren, da es nicht mehr unterstützt wird. Ich habe die neueste v1 aws-cli (1.18.80 zum Zeitpunkt des Schreibens) sowie eine ältere Version (1.11.78) verwendet, auf die in dieser Ausgabe verwiesen wird. Ich habe das von @jamesls bereitgestellte Skript (https://github.com/aws/aws-cli/issues/602#issuecomment-281866173) Anmeldedatenpaare erstellt, bis es auf eines mit Sonderzeichen stößt, und sie bis zu laufen lassen jeweils eine Stunde. Bei mir ist kein SignatureDoesNotMatch Fehler aufgetreten. Ich habe gelegentlich AuthFailure Fehler beim describe-instances-Befehl erhalten, aber ein erneuter Versuch des Befehls mit denselben Anmeldeinformationen ist erfolgreich.

Die große Anzahl von Kommentaren macht es für neue Benutzer, die zu diesem Problem kommen, schwierig, Anfragen von unserem Entwicklerteam für Vorschläge zur Fehlerbehebung zu finden. Um unser Team und die Community bei der Ermittlung einer Ursache für diesen Fehler zu unterstützen, schließe ich dieses Problem und erstelle eine spezielle GitHub-Problemvorlage, die Anleitungen und Kommentaranforderungen für Benutzer enthält, die auf diesen Fehler stoßen.

Wenn dieser Fehler auftritt, gehen Sie bitte zur Registerkarte "Probleme", klicken Sie auf die Schaltfläche "Neues Problem" und verwenden Sie die Vorlage für einen SignatureDoesNotMatch Fehlerbericht (oder verwenden Sie den unten stehenden Link).

Aufgrund der unterschiedlichen Benutzerumgebungen, in denen dieser Fehler auftritt, reichen Sie bitte ein separates Problem ein, anstatt ein vorhandenes zu kommentieren.

Klicken Sie hier, um einen SignatureDoesNotMatch Fehlerbericht einzureichen