EDIT: If you are running into this issue, we'd appreciate your help in troubleshooting. I'm updating this comment for better visibility on troubleshooting steps.

Troubleshooting

The first step for troubleshooting this is to determine whether or not the issue is with the credentials themselves or with the CLI. To test this, try using these credentials in other AWS SDKs (javascript, ruby, java, etc). To help with this, I've created a test script that uses the AWS SDK for python and javascript which is available here: https://github.com/jamesls/aws-creds-test . After cloning, just run make install, make test. It will prompt you for credentials (similar to the CLI) and make an API call to 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.

For people running into this issue, please run the test script and share the output.

This should give us better insight into where this issue is occurring:

• If the above script passes for both python and javascript but is failing when using the CLI, likely a CLI issue.
• If the script fails for python but passes for javascript, likely an issue with botocore (which the CLI uses).
• If the above script fails for both python and javascript, likely an issue with the actual credentials.

Thanks in advance for anyone that can help us troubleshoot this issue. Let me know if there's any questions.

This is how it looks like:

thomas@iMac:~ $ echo $AWS_ACCESS_KEY_ID
AKIAXXXXXXXXXXXXXXXX
thomas@iMac:~ $ echo $AWS_SECRET_ACCESS_KEY
abcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa+0
thomas@iMac:~ $ 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

Any updates on this issue? I'm also encountering this error and my credentials file hasn't changed.

I have a similar issue. Jenkins s3 plugin is able to put an object using my credentials, but the aws-cli is giving me the errors below.

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.

I am running into the same issue. If I make up a secret it gives me a different (AuthFailure) error.

[[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

This is pretty much stopping me completely. I can do some things with the ec2-blah-stuff utilities by specifying x509 certs but the help says that's deprecated so I don't want to depend on it. Any help troubleshooting or what ever would really be appreciated.

The first step would be to ensure that your access/secret keys are actually valid. A few things to try:

• Does these same access/secret key credentials work with other tools? (The java/javascript/ruby/python SDK?)
• Do other commands besides "aws s3" work for you? Does "aws ec2 describe-instances" still generate auth errors?

They do not work with other tools (ec2-describe-instance for instance).

I think I have the appropriate rights since using the certs works. To make sure it's not a workstation thing I built an Amazon Linux instance and I'm using the awscli verison that comes with it but getting the same message.

Also an issue for me. I'm using it in a docker container, built with the same Dockerfile.
It works fine when built on an EC2, but does not work when built locally on a coreos vagrant box.

It looks like the issue is with the credentials themselves. I've double checked this, and I'm not able to repro this issue. Double check the credentials on the security credentials page. If someone can provide an exact set of steps that demonstrate the issue, I'd be happy to take another look.

Just had this happening to me and was a result of my system time being off by too much even though it did not report that. Ran ntpdate against pool.ntp.org and fixed this problem for me.

If you are getting this error when cred are setup using env variable, try sudo

If you are in a virtual machine make sure your host os time matches the guest os time. If this is not the case you will get into the error you described.

A very similar error occurs for me with good credentials, whilst listing a bucket which has a _lot_ of keys in it. Here's the error:

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

Here's my output from 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

Note that these credentials work fine with other aws invocations, and in fact this list op runs for a long time (more than an hour) before bailing with this error. I have a file with over 82,000 lines of output in it from the command which eventually failed.

I've been getting this issue, and if I just sleep my script for a second and try again then it goes through. It's almost like it's getting throttled and returning the wrong error or something.

I can report this issue too. Trying to upload a 11 GB file using aws cp foo s3://mybucket/foo/bar I get various errors like:

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.

and

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)

I've checked that my system time is correct. I also noticed considerable slowness (on the level of http requests timing out) on the same system while uploading, so this being a throttling issue does sound reasonable. It also works fine to upload small files with the same credentials, and using the web console from the same machine, so this does appear to be a aws-cli problem.

This happened to me with too with aws-cli 1.5.5, updating aws-cli to 1.6.2 solved it.

Happens to me with 1.6.2

This happened to me today. This is new to me. Been using awl-cli for a few months no problem and no change to the credentials 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

I believe this issue is now fixed via https://github.com/boto/botocore/pull/388, and will be available in the next AWS CLI release.

@jamesls confirmed fixed on awscli version 1.6.4. I was using 1.5.4. Thanks!

I am getting this issue on a fresh 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.

Installed aws-cli 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)

Any ideas on how to fix it?

My solution was to sleep for a few seconds and then try it again, but it
sounds like there may be an update to the tool that fixes it as well.

On Tue, Dec 2, 2014 at 3:38 AM, Mark Wolfe [email protected] wrote:

I am getting this issue on a fresh 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.

Installed aws-cli 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)

Any ideas on how to fix it?

—
Reply to this email directly or view it on GitHub
https://github.com/aws/aws-cli/issues/602#issuecomment-65198065.

@wolfeidau and yeah I spoke too soon. The locally pip installed awscli is giving the SignatureDoesNotMatch errors again. Yikes!

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'

Does this issue happen only when a request is retried? Or does this happen everytime you run the deregister-instances-from-load-balancer command?

@jamesls it happens everytime now :(

I know this issue is closed but wanted to share that you can see this error when running in a VM which hibernates. In such cases, the system clock doesn't consistently catch up if you're using Ubuntu. Just update the time to fix (i.e. sudo ntpdate -s time.nist.gov).

hello, is there any final fix on this?

+1

Using version 1.7.8 of the CLI I was seeing the same SignatureDoesNotMatch error when trying the following:
$ aws iam list-users

And getting an AuthFailure for this:
$ aws ec2 describe-security-groups

After deleting my keys and trying new ones, both commands work.

This is the old secret access key that may have been the cause of my problems, note the percent, plus and forward slash characters: H2J7/oT3Fib15SwFVB1s3EnTCmg+SC7wF7qoP+dw%

:+1: @gsterndale. My access key with % in it didn't work. I had to generate new keys.

I have also experienced this issue multiple times. Every time regenerating the key until I got one without any special character in it (in particular I was having issues with the + sign in the secret) fixed it.

Truthfully all of my signing key problems melted away when I switched from running the command on an ubuntu machine instead of a local mac homebrew installation.

I am very new to AWS , faced this issuse right away on node js

              ^

SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the s
vice documentation for details.

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

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

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

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20150809T053346Z
20150809/us-west-2/ses/aws4_request
0b908b0248bae550b814b37629a418707742416377816b5a5e78e1897b72293e'

+1

I am having this problem for all aws s3 commands (awscli 1.8.6 on ubuntu 14.04 LTS).
Are there any known solutions? I tried deleting my credentials file and run aws configure, rebooting, reinstalling awscli.

@mcobzarenco, have you tried new keys?

@gsterndale I saw the comment above about having slashes in old keys, but that's not the case and my keys were recently generated (in June 2015). I only have this problem on AWS Ubuntu 14.04 LTS. On my laptop (14.04) awscli (same version) works fine.

@mcobzarenco I don't think it's the age of the keys, rather the special characters in them. When I originally created keys, they happened to have percent, plus and forward slash characters. While debugging the issue I tried deleting and creating new keys. These new ones luckily did not have any of these characters and they work.

just ran into this problem on ubuntu. When I entered the keys via cli, it stored them in ~/.aws/config, but stripped away the '+' character. Manually editing the file to add the '+' allowed me to connect.

@gsterndale Thanks for the tip, I can confirm that generating a new key that doesn't contain + worked for me as well. @stebl's solution is nice if it's inconvenient to replace the keys.

I faced the same issue when using AWS SDk with node js. To resolve this issues I followed exactly the same steps mentioned here
http://aws.amazon.com/developers/getting-started/nodejs/

I think AWS SDK is developed with particular version of node js, mismatch in node js will result in issues like this.

I has the same issue and yes, is was solved by using a key without special symbols (the + in my specific case)

We encountered this error (where one machine could describe-instances using awscli but the other got an an access denied error with the same access key. On the latter machine iam list-users gave this SignatureDoesNotMatch error). Resolved by correcting the system clock time on the machine with the problem.

As @tukaaa said, there is a bug if secret access key contains a non alphabet character (such as +). I think a bad escaping somewhere ;-(

@ebuildy Can you confirm what version of the CLI you're seeing this on (aws --version)? If this is a reason version of the CLI I'll go ahead and reopen this issue.

I am getting this on aws-cli/1.9.1 Python/3.5.0 Windows/7 botocore/1.1.8

I was having the same issue on one Windows box, using a key without any non-alpha chars in it. I'd checked it wasn't a copy / paste error by using the same paste buffer on another box. Uninstalling / re-installing the AWS cli and deleting the credentials / config files, then re-running aws configuration fixed it.

Just saw this on aws-cli/1.10.3 Python/2.7.10 Darwin/14.5.0 botocore/1.3.25.

Regenerating a key without special characters fixed it. FWIW in my case special character was / and I was using an INI file.

Ok reopening, we'll dig into this.

@I can confirm I have the same issue as @gsterndale describes.

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

But my key does not contain any special symbols.

I am getting the same error using the s3-cli node module. My secret key contains an [.

I finally found out what's wrong. I accidentally added several characters to the keys. That's the reason.

I was facing this issue with the following scenario; both on rhel7 and ubuntu. I think it has something to do with non-alpha characters as others have mentioned

• s3 bucket protected for a single role
• ec2 instance with said role needs to assume same role before accessing protected s3 bucket

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`

I believe something with the --query was messing up the credentials. When running the commands manually and copying and pasting the values; then setting the environment variables it seemed to work just fine.

I had the same problem when running awscli version 1.10 on Mac (installed via pip) versus Ubuntu (Amazon image) awscli version 1.2.9. aws configure --profile user produces two different configurations under each. Version 1.10 produced two files: config and credentials. Version 1.2.9 just produced a config file (but with the credential information). When I deleted the credentials and config file produced by version 1.10 and copied the config file produced by version 1.2.9 everything worked, even with special characters and running awscli version 1.10. The config file produced by version 1.2.9 is

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

Can confirm that it's due to non-alphanumeric characters.

I have the same problem with a secret key containing a +. However I am not the owner of the S3 account and can't easily create a new one. Has anyone found any fix other than creating a new key without special characters?

tl;dr Solution : repeatedly re-recreate credentials UNTIL your aws_secret_access_key does NOT contain non-alphanumeric characters ... in my case aws_secret_access_key contained a + ( plus sign)

I just did a fresh install ... same issue ... this is on Ubuntu ... its not a local OS issue its an Amazon API issue so ignore other comments which say moving off OSX fixes it

aws ec2 describe-instances

An error occurred (AuthFailure) when calling the DescribeInstances operation: AWS was not able to validate the provided access credentials

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

aws ec2 describe-security-groups

An error occurred (AuthFailure) when calling the DescribeSecurityGroups operation: AWS was not able to validate the provided access credentials

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

aws ecr get-login

An error occurred (InvalidSignatureException) when calling the GetAuthorizationToken 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
/

content-type:application/x-amz-json-1.1
host:ecr.us-east-1.amazonaws.com
x-amz-date:20160615T182955Z
x-amz-target:AmazonEC2ContainerRegistry_V20150921.GetAuthorizationToken

content-type;host;x-amz-date;x-amz-target
44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20160615T182955Z
20160615/us-east-1/ecr/aws4_request
86c2e3c850acd6765a1ca6aa626c6e9a6c85284f3954f45e170f51b5b89961c7'

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

aws iam list-users

An error occurred (SignatureDoesNotMatch) when calling the ListUsers 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:iam.amazonaws.com
x-amz-date:20160615T183516Z

host;x-amz-date
b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2'

The String-to-Sign should have been
'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
[default]
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 :
After deleting and creating fresh credentials
where aws_secret_access_key did NOT have plus sign ( + ) all was well above commands started to work OK

I had the same problem. Re-creating credentials until I had no special characters in it worked for me.

I found that when I copied & pasted the credentials they had ^M characters on the end which was causing the error.

Getting a secret key without + fixed it for me too...

Note - if you are seeing this issue under (boot2docker VM'd) docker, it can be that the VM clock is out of sync.
See: http://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host

I'm having the same issue. What if I don't have permissions to regenerate the credentials.. any possible fixes using other ways ?

UPDATE: I fixed this by running rm -rf .aws/cli/cache/

I'm having this issue now as well. When attempting to assume role

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

Edit: Tried also updating again now, same problem:
aws-cli/1.11.18 Python/2.7.12 Darwin/16.1.0 botocore/1.4.75

Output:

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'

The same issue still exists with the latest (up to date) version of AWS CLI as well. I've just upgraded my 1.8.3 CLI to 1.11.19 - and was not able to execute any commands with a new user/keys I've created. Had to re-cycle about 5 keys before I got a pair where the Secret key did not have any non-alphabetical characters. Once I stumbled upon such pair - CLI works fine.

Very annoying - I wish Amazon would not be generating invalid keys that they cannot process.....

@mpopova-yottaa did you try completely clearing the awe-cli cache ? Try deleting the entire ~/.aws directory (make a copy of your config/credential files)

aws ec2 describe-instances runs for me, but when trying to create cloud formation stack:

```Exception in thread "main" com.amazonaws.services.cloudformation.model.AmazonCloudFormationException: 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
/

amz-sdk-invocation-id:18d13b66-80ae-f676-c0cf-dbf875edb1aa
amz-sdk-retry: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-date:20161127T194448Z

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

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20161127T194448Z
20161127/us-west-1/cloudformation/aws4_request
cb0286a8727afcc465171ab991accde0aaa7210e160a9ba3196e2a5e4305f428' (Service: AmazonCloudFormation; Status Code: 403; Error Code: SignatureDoesNotMatch; Request ID: f52abbd4-b4d9-11e6-b989-d5c3d50d5e7b)

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

The secret key only contains alphanumerics, so I am stuck.

@aebrow4 It's down the cache for awe-cli. Try deleting: .aws/cli/cache/

@cultavix there is no cli directory inside .aws

I got this error when running aws glacier upload-archive with --archive-description "`date`". When I use --archive-description "`date +%Y/%m/%d`" it works fine, so there seems to be some escaping issue.

I was having a similar issue:

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

I tried syncing the time with an NTP server (successfully), but this did not resolve the problem. Regenerating keys until I had a set with no special characters fixed it.

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

I have the same issue using awscli and sample python code (boto3).
Note that i'm using IBM object storage S3 api compatible, I can list buckets and their contents but can't upload (both for pyhton code and cli).
I tested the scenario with the ruby aws-sdk and it works fine (upload/download).
-- configuration
aws-cli/1.2.9 Python/3.4.3 Linux/3.19.0-33-generic

Just started having this same issue with a script I've been using for months for depositing multi part uploads into Glacier. Can still deposit fine via aws cli, so credentials still work, but script using boto3 fails with:

"botocore.exceptions.ClientError: An error occurred (InvalidSignatureException) when calling the InitiateMultipartUpload 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."

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

(yes I updated everything thinking that might fix the problem...no such luck.)

getting a new pair of keys without any special characters (it was + in my case) fixed the issue for me

another confirmation here of incorrect handling of + in secret key.

Hi everyone, here's a script that I've used to try and repro this issue: https://gist.github.com/jamesls/00ef7fcc0ac39ba8b06956d165c42f6d . This is what the script does:

• Creates a new access_key/secret_key pair via aws iam create-access-key in a loop until it finds credentials that have either a + or a / char.
• It creates a new "testcreds" profile with these newly generated credentials
• It tries to make invoke various AWS CLI commands to ensure these credentials work

It does this in an infinite loop until an API call fails. So far I haven't been able to get it to fail. Secret keys that have + and / are working for me.

At this point we've confirmed that it's definitely possible to use secret_keys that have a + or / so I don't think the root cause is something as straightforward as a bug in our signing code that breaks when + is present. Rereading the comments in this thread, it might be an issue with how credentials are being entered into the ~/.aws/config or ~/.aws/credentials file. Perhaps there's some platform specific thing that's altering characters that contain + or /.

So for anyone that's still running into this issue, it'd be really helpful if you can provide some additional information:

1. How are you getting credentials (copy/paste from console, aws iam create-access-key, CSV file from console, etc)?
2. How are you configuring the CLI to use these credentials? Are you running aws configure and entering the values when prompted? Are you doing this programmatically by running aws configure set? Are you manually editing ~/.aws/config and/or ~/.aws/credentials? Setting the various AWS_* env vars?

Bonus things that would be even more helpful if possible:

1. If you use other SDKs, do these credentials that don't work in the CLI work in other AWS SDKs?
2. If you have a test account or test IAM user, does running the script I'm using to test ever fail for you?

Any additional info that might help us repro this issue on our end would be great.

I am still having this issue. To answer your questions:
Created credentials in amazon console and cut/paste into ~/.aws/credentials (edited with emacs on a mac)

From the troubleshooting I've done so far (and I'm a novice at this...) the 'Canonical String' is correct, but the 'String-to-Sign' is wrong, having a different last line. I.e. when I print the return value of auth.py string_to_sign, the number produced from 'sha256(canonical_request.encode('utf-8')).hexdigest())' is different than the number reported in the returned error "The String-to-Sign should have been" .

There are no special characters in my credentials, and the do work when using other tools, e.g. CrossFTP (which I don't want to use!!!)

Any insights would be greatly appreciated!!

@samato88 that appears to be a different issue there. If you could share any debug info (making sure to remove any sensitive information) that would help.

The string_to_sign is not influenced by the secret_access_key. When we sign a request, we take the HTTP request we're about to send, convert it to a string (i.e the string ot sign), and then using the secret key, we sign that string with the secret key (skipping a few details here). So any issues with the string to sign would be separate from this issue.

Could you open another issue and provide the --debug output (or include the complete request and error message from the service)? We'd be happy to look into this for you.

Thanks jamesls - I've opened a separate issue at:
https://github.com/aws/aws-cli/issues/2474

Any insights much appreciated.

If your system time is off by more than 5 minutes, you will not be able to use the CLI

just run... sudo ntpdate -s time.nist.gov

then try again

I had the same issue, my secret key contains "+" sign. I've deleted my .aws/credentials file and re-run aws configure. After that my query to sqs queue to receive message worked.

Thanks @AlexParra03 . I had same issue and your comments helped me to resolve.... :-)

@robotzero do you recall how you entered your credentials? Did you run aws configure and then copy/paste the values from the web console?

Yes, I ran aws configure and copy pasted the values.

Yes, I had a + in my secret, which caused this error still. Making new keys without special characters fixed the problem.

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

Had a + and a / in my secret. Secrets without these solved the problem for me.

Also had this issue.

$ 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

Had a "+" in the credentials. Was resolved by regenerating access key without them. As a note: "/" is a fine character to have.

@adityanatraj @shwetapurushe @damienrj can you all answer these questions here? At this point we're trying to get more information about your environment and how you're entering credentials. As mentioned in that comment, generating a secret key with + doesn't repro the issue for us, so it's possibly related to a combination of your environment and/or how you're entering credentials.

In other words, we need more information from people so can troubleshoot what's going on.

@jamesls

1. How did I get the credentials?

I got the credentials by copying them from the web console.

1. How do I configure CLI to use them?

I manually created the two files:

~/.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

Sorry, I can't help with the bonus questions as I've purged my access keys containing '+' signs, so the problem doesn't show up.

@adityanatraj thanks, every bit helps.

The next step that would help us troubleshoot is to figure out if this is an issue with just the CLI or an issue with the credentials themselves. For anyone that's still running into this issue, it would be really helpful if you could try these credentials in other AWS SDKs. To help with this, I've put a sample repo/script together that makes this easy if you don't want to set this up yourself: https://github.com/jamesls/aws-creds-test . Just clone the repo and run 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.

For people running into this issue, please run the test script and share the output.

This same exception happened to me on a PutObject request (C#), whenever the object metadata had Unicode characters.

I had the same issue. New secret keys with + and / don't work. I generated new keys without those characters and they work fine.
Your test script is for linux and I'm running windows.
I pasted my credentials using Control-C and Control-V using windows shell and _aws configure_
and I was only using _aws cp_

Tested this too, and it works fine as long as the secret key has no symbols, as mentioned above.

Hope to see this resolved soon, it's a pain having to keep regenerating credentials until I get one that works!

I raised a support ticket to AWS yesterday, and today it appears to be resolved

I've tested multiple times and + and / both now seem to work? I can no longer reproduce this bug.

I had the same issue on my Pi.
With the newest awscli (aws-cli/1.11.85 Python/3.4.2 Linux/4.9.24-v7+ botocore/1.5.48) I still had the issue:

root@pi:~# aws s3 ls s3://
An error occurred (SignatureDoesNotMatch) when calling the ListBuckets operation: The request signature we calculated does not match the signature you provided.
Check your Secret Access Key and signing method. For more information, see REST Authentication and SOAP Authentication for details.

Even with a secret key that had no special characters (+ or /) the access didn't work. The time was always in sync, unfortunately this wasn't the issue either.

In the ".aws/config" file I added a valid region (just for testing..) and suddenly it worked. Since I'm using compatible s3 storage (not s3 from Amazon)

[default]
aws_secret_access_key = MYKEY
aws_access_key_id = MYID
region = us-east-1 <-- there was a "dummy" value before.

As it looks, the region must have a "correct" value. When I change it back to something different like "dummyvalue" I get the same error as mentioned above.
Now with the value "us-east-1" it works!
Hope this helps someone.

I just ran into this as well. Also seems to be an issue with a '+' in the secret key. If I have the creds in environment variables I get the error. If I put them in the ~/.aws/credentials file (by editing by hand) I don't get the error.

[edit] Just noticed the environment variables were in a file formatted for dos (ff=dos in vim). It was this because I had just taken the .csv file as downloaded and edited it to change the entries into environment variables. When I re-formatted the file into 'ff=unix' I no longer got the error. The only difference between the 2 is the line return, dos uses "CR-NL" while unix is just "NL". My guess is that it was actually that "CR" character that was the problem.

me too, and also confirm the "+" issue

If you run into this when using Docker for Mac, simply restarting Docker will fix the system time discrepancy.

I was facing the same problem.
Checked the secret, and it had +/ in it.
Had to create a new id pair without a special character to get it to work

Creating new keypairs until I got one with no special characters resolved it for me too; special characters (specifically +) simply do not work in ~/.aws/credentials.

Generated key without special characters (specifically + ) fixed the issue for me too.

Formatting file as per @eikenb 's comment does the trick as well.

Deleting the Key and creating new one worked for me.

Just received this error. Updated system time which appeared to be more than 6 minutes off GMT. Fixed the issue immediately.

It was so strange and tricky for me.
I struggled with this problem and I was trying many times to resolve it.
At the moment It suddenly worked! I was surprised so I made new bucket but it didn't work. Because I had done nothing except changing code, I just waited for hours. Finally, it worked well although I did nothing. I can't believe it...

Using aws configure in a bash shell on Windows 7 I found I had two aws_secret_access_key lines in my .aws/credentials and the second line was where I'd mis-typed a load of rubbish. Deleted the second line and it all worked.

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

Seeing this problem on Linux Mint here, with no + in my key or secret.

Output from the test script:

/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

After upgrading awscli to 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

I just recreated my keys - My new one still contains a '+', but now able to use the cli

Could be as easy as that

@DanAbbz92 indeed, I happened to find the same solution around now. No idea why the old keys never worked, but the new ones were fine using the same process.

I had a ^V in my Secret key from a bad paste attempt. It may be prudent to put a stronger warning on checking for bad characters in the keys. Will prevent further unneeded escalations.

This issue was reported in 2014. Today is Oct 26, 2017. I encountered this issue, my secret had a "+" in it. I created a new key and put it in ~/.aws/configure
Come on Amazon, do you ever plan to fix this bug*???

I encountered this issue today after installing the cli and running aws configure. My keys had no special characters in them but the following did fix my problem:

• rm -r ~/.aws/
• recreated the .aws folder and the credentials file and added the credentials back in manually

tl;dr turning it off and on again worked for me ¯_(ツ)_/¯

For people using Hadoop ending up here: A related bug has been fixed for Hadoop 2.8.0:
"s3:" URLs break when Secret Key contains a slash, even if encoded

Hi, today I have caught the same issue.
The box had wrong time on it. After updating time all is working.

Adding another "me too"

I had a Secret key that had two '+' characters in it, and that worked from my .aws/credentials file on my Windows VM (when used by a .NET application), but when I installed awscli from brew on my MacBook Pro, and copied the .aws files across (testing for file encodings, end-of-line formats etc) it failed with SignatureDoesNotMatch.

I tried recreating the credentials until I got a secret key without any non alphanumerics, and now it works from the awscli on my Mac. Copying those credentials back to my Windows machine and running the .NET application, that still works.

I didn't make any changes to the time on either machine (The Mac was using NTP already, and the Windows VM looks likes it's running about 12 minutes behind the actual time)

I installed awscli with: brew install awscli

and aws --version returns: aws-cli/1.14.30 Python/3.6.4 Darwin/16.7.0 botocore/1.8.34

Well, I pushed code to lambdas this afternoon (2018-02-01 15:48 EST with lambda in us-east-1).
Now at 6pm, I'm getting signature errors on every system in the office.
Looking back through this thread: my times are correct, nothing has changed, credentials are under a year old, have been working since the day they were established, using homebrew version aws-cli/1.14.30 Python/3.6.4 Darwin/17.4.0 botocore/1.8.34 (did try a downgrade to a 1.14.2x version, no love)

This is some malarky

Having the same issue and solved genereting new keys without any special characters (like /, + and so on).

Thanks to @hellais for the input!

Just had the same issue, solved it by correcting my laptops clock. Apparently i was behind time.

I just experienced this issue and it appears that my ntp client was 10 minutes behind. I did a ntpdate and all is now fixed.

I can confirm that recreating my access keys until I got one without special characters in it, worked. What a ridiculous bug, wow.

Seeing as this is such a long running issue, would it not be intelligent to update the error messaging to give users a link to a potential fix, like rebuilding your keys? Instead of something which makes out that the issue is far more complex than "yeah we error out when your keys have special chars in them, sorry!".

same issue hear:

Versions:

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

Command:

aws s3 ls
got following error:
Unknown Signature Version: s3v3.

no solution:

i updated my cloak and i generate a Secret without any special Character

update - fixed by following

aws configure set default.s3.signature_version s3v4

Yeah this is still a problem - my secret key ended with a + character and no fix I found worked. Regenerated new keys with no + at the end of the secret key and it worked fine.

How on earth is this still an issue?

An error occurred (SignatureDoesNotMatch) when calling the CreateMultipartUpload operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.
please help.

My secret starts with + sign and I didn't even know there's this issue until today. I use boto3 python to access my s3. It doesn't work when I pass credentials as raw strings but works fine if I load it from config.ini as a variable using configparser.RawConfigParser(). Of course, generating a new secret without + sign at the end or at the beginning will solve this issue too.

Nonetheless, if this (for some reason) can't be fixed maybe change the exception message to something like "we don't allow + sign, generate a new one if you want to access it the way you do".

I am using aws cli on osx and I also had a secret that appeared to not be correct. My original one had a + and an = in it and I received the SignatureDoesNotMatch error when attempting to cp files to s3. I regenerated keys and my new secret is now an alphanumeric string. Just adding another confirmation that regeneration works. :relieved:

In the hope this might provide insight, this problem (not handling + in secret keys) exposes itself with this version on 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

but does not occur with this version on Ubuntu

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

Started Jan 2014 and now June 2018, over 4 years and I had the same problem with SignatureDoesNotMatch error. The solution for me was the same as all the majority solutions here, get a new Secret Key without any special character as for my former key has a colon :, tried the time syncing, but not working for me. I'm using WSL.

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

Just updating what @gchiu said in April 2017: it is still the case in June 2018 that secrets that have the slash (/) character in them may make the PHP client not work (PHP 7 on Windows 10 in my case), returning the _signatures do not match_ error. In this situation, just generate another pair of keys that is safer.

I was flummoxed by this for about 30 mins.

Followed this issue and checked the local time, etc. - all was good.

In desperation, nuked the ~/.aws/credentials file and logged in again (essentially recreating the file) and voila, just works.

Wonder why does it throw this error at all!

EDIT:
Doesn't seem to be related to the secret key in my case; they were all mostly simple strings.

+1 on this issue, my key started with an =. Regenerated a key that only had a / in it and all was well. Tried encasing the key in " marks, but to no avail.

Not something I would expect to see from the AWS CLI.

Adding to the same problem here, I cannot believe that the / in my key would have caused this. Thanks for the time wasted!

I had this problem. I believe it was a result of initially installing the aws cli as the root user. The resolution seemed to be uninstalling the aws cli, deleting both the .aws folder in the current user's home folder as well as in the root folder, and then running 'aws configure' again as the current user.

I experienced this problem when running a bash script using a systemd timer on Ubuntu. When manually running the script with my user, everything worked fine. However, the timer would keep on throwing the (SignatureDoesNotMatch) error. I then noticed that the (SignatureDoesNotMatch) was produced for any aws command running as root and that 'aws configure' did not save new values being provided.

To resolve the problem I logged in as root 'su -i', changed to 'cd ~/.aws/' and removed the configuration with 'sudo rm -r credentials', ran 'aws configure' again and this time the new values was saved. From there everything worked again as expected!

Can confirm that this issue still exists on 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.

And turns out there was a + in my secret. I regenerated and everything is fine now. When can we expect a fix for this @jamesls? Or is there anything I can do to help?

Faced the same on my aws cli because the secret key was containing + ...(as described by above) After regenerating a new key..(as I saw from delmartechdude comment above).... the issue been solved.

My two cents. It was giving me this error because I was trying to upload content to s3 with accelerated transfers this way (it used to work in the past): --endpoint-url http://imaat.s3-accelerate.amazonaws.com (--endpoint-url http://<bucket-name>.s3-accelerate.amazonaws.com) as specified in acceleration endpoint properties:

Following instructions in official docs: https://docs.aws.amazon.com/es_es/AmazonS3/latest/dev/transfer-acceleration-examples.html I replaced that last part with: --endpoint-url http://s3-accelerate.amazonaws.com and run the command aws configure set s3.addressing_style virtual to build the hostname dinamically. Check: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#addressing-style

I don't know why, but now it works. My bucket name ("imaat") doesn't have any special character which may lead to DNS failures, but it failed for some reason with latest cli updates.

Adding a profile via text edit and got this failure. Updating the profile access id and secret via an aws config set and it worked. This is for a secret with '+' in it and aws-cli/1.16.23 Python/2.7.15 Windows/10 botocore/1.12.13

@dave-miles You're on to something, thank you for commenting! I'm expanding on your finding below:

I ran into this issue with some docker images. Originally I was using an ADD in the dockerfile to add the ~/.aws/credentials file into the container.

If we did this, we would run into the SignatureDoesNotMatch error when trying to download from s3.

I removed the ADD line in the dockerfile, rebuilt and launched a new docker container. In this new container, I manually ran aws configure set aws_access_key_id <access key id goes here> and aws configure set aws_secret_access_key <secret access key goes here> This was the first time entering the credentials information in this container (I.E. the container was a "fresh" centos image).

After using the aws configure set commands, I was able to successfully download from s3.

For anyone using this with a dockerfile, you could use RUN statements in the dockerfile to run the two commands or you could use an ADD statement to push a script to your docker container:

#!/bin/sh

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

I had the same problem as @villasenor - a + in the secret key would cause the error when configuring the awscli using env vars in docker. rotating the keys fixed the issue .

Ditto here, but there are no special chars in the access key or secret key.
Regenerated a new set for the same IAM user, and the new ones can list buckets, old ones can not.

This occurred with both AWS cli and Java SDK calls. Suggesting the fault is not in the clients...

Both sets are still live. If anyone at Amazon want's more details please get in contact.

My co-worker just encountered this too. I tried debugging by creating an access key until I got one with a + or / at the start. Wasn't able to repro though.

I had a co-worker experience this. We determined that this occurs specifically Ubuntu 18.04 with + or / in the secret key.

Got the same error today, currently using Windows 10. However, when I use the same access key on another laptop (mac), it works fine for me. Then I tried the access key within WSL, which is also fine. Not sure the reason, and there is no special character in the aws key.

I'm having this error with one set of access keys and not the other.
As mentioned in several other posts here my key as a '/' in it. To me this issue seems like a simple problem of either the server or the clients encoding/decoding using the RFC URI encoding standard and the other not using it.
I plan to run these test scripts mentioned and attempt to reproduce errors.

To other folks here, I ran into the error, but I had incorrect credentials cached in my ~/.aws folder. It looks there first and to environment variables second.

I am experiencing this on Windows 10 using Git Bash. It works just fine with Powershell. The Python invocation is obv different, but its the same Python and Python module. I also have + and / in my key.

I just had this problem and for me, the fix was to remove the spaces. example.
instead of the default of:
[profilename]
aws_access_key_id = MYAWSACCESSKEYID
aws_secret_access_key = MYAWSSECRETACCESKEY
I changed it to:
[profilename]
aws_access_key_id=MYAWSACCESSKEYID
aws_secret_access_key=MYAWSSECRETACCESKEY

note the lack of spaces around the =. This fixed it for me and I have + and / in my key too btw.

All, there are some awesome troubleshooting tips in here. I'm going to turn these into a page in the Troubleshooting section in the CLI Users Guide. Thanks for the contributions!

Hi all,

I can see there are a lot of answers here, but for me it was the special characters in the AWS Secret Access Key. Mine started with "=+", but when I generated a new one without special chars from the web console it started working immediately.

I'm running awscli in a Zsh shell on Ubuntu on Windows:

jonathan@SurfaceBook  ~  aws --version aws-cli/1.16.216 Python/2.7.12 Linux/4.4.0-17134-Microsoft botocore/1.12.206

I hope this is helpful to others.

Thanks
Jonathan

Just sinked 4 hours of debugging into this until i found this thread. I could use the s3 cli locally without any issues, but when running them in circleci I got this error: SignatureDoesNotMatch..

As others have suggested my secret access key contained a + character, and after generating a new key everything started to work.

Would almost have been impossible to debug without this thread

Thanks @blbradley . It was exactly the problem that I had.

had the same problem - the solution was to delete Windows environment variables with obsolete AWS credentials

I had the problem too on Python3 boto3.
Mine starts with =/

I'm in a virtual machine making the host Time&Region similar to the guest Time&Region solves the problem .

Just wanted to chime in that this hit me today as well on a newly created key - and after lots of frustration, landed here and saw mention of a / in the key. Sure enough, that was the issue - new key without it works. Wtf?!

I can not believe this issue's opened in 2014 and still there is no fix for it, this bug forced me to make a new set of AWS credential for myself, I even tried to encode the '/' but it didn't work :(

Eliminating the credential with the "/" fixed the issue for me. Thanks to everyone for pointing this out.

Just hit this in 2020 now. Secret key has a '+'.

aws-cli — developed by aws project — fails with valid aws keys... for 6 years?

Same problem in 2020 January. Secret key has a "/" slash character.

I generated a new credential set, using the AWS IAM console, and ensured that the secret key was all alphanumeric, no "/" no "+" and so on. I replaced my old secret key with the new secret key, in my ~/.aws/credentials file, then retried.

This solved it.

Same issue here on 2020. But I can not remove none alphanumeric characters as they are part of my credentials it self, and I'm not in control of that

Just regenerate the credential until you get rid of the characters. It usually only takes one or two more tries.

Maurice

From: columb1a notifications@github.com
Sent: Tuesday, January 21, 2020 1:47 PM
To: aws/aws-cli aws-cli@noreply.github.com
Cc: Maurice Bizzarri maurice@bizzarrisoftware.com; Comment comment@noreply.github.com
Subject: Re: [aws/aws-cli] SignatureDoesNotMatch error (#602)

Same issue here on 2020. But I can not remove none alphanumeric characters as they are part of my credentials it self, and I'm not in control of that

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://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&reserved=0, or unsubscribehttps://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.

I first ran into timeout issues and after updating my awscli ran into this issue. You thought 6 years is enough to make it work...

am also having this deploying Vue.js app through gitlab to AWS S3 bucket can someone tell me what to do
msg:fatal error: An error occurred (SignatureDoesNotMatch) when calling the ListObjectsV2 operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

I did not have any non-alphanumeric chars, but working with profiled did not work, for a single profile. I regenerated the credentials using the console and the new ones just worked.

Getting such errors as well today, and regenerating the credentials without special characters ('+' or '/') works for me.

I still have the same issue , but it happens suddenly, I work with Get and Put operations and one works, the other doesn't. and yes my secret key doesn't contain any special characters. any help? I first call getIntent (amazon lex models API) to retrieve the intents checksum, then call putIntent to update that that intent. Get method works (Not all the time) but put method appears the same issue of signature, while if I removed Get method API from code, Put method works 2 times out of three.

I had this issue, I suggest you to generate new keys
and re-configure your aws profile

aws configure

AWS Access Key ID [****QD5E]: AWS_ACCESS_KEY_ID
AWS Secret Access Key [****ANjA]: AWS_SECRET_ACCESS_KEY
Default region name [eu-west-3]: AWS_REGION
Default output format [json]: OUTPUT_FORMAT

Hi !

I am getting this same issue when using pre-signed URL returned to my client
The URL is generated in the server (for a limited time). The server is python and I don't see any error there, but the client is JS - only gets the URL and opens it. Part of the URL are generated credentials for this resource)

The error is on and off, so I think it is related to what is said here about special keys in the credentials, but since I am using credentials generated in the server - I cannot change them !

Any way to take care of this in the code ? parse the specials keys somehow ?

Hi !

I am getting this same issue when using pre-signed URL returned to my client
The URL is generated in the server (for a limited time). The server is python and I don't see any error there, but the client is JS - only gets the URL and opens it. Part of the URL are generated credentials for this resource)

The error is on and off, so I think it is related to what is said here about special keys in the credentials, but since I am using credentials generated in the server - I cannot change them !

Any way to take care of this in the code ? parse the specials keys somehow ?

@maya-harel you can change the credentials from IAM -> users select user you have created and re-generate the secret key security credentials tab.

also timing in code is really fatal, for each request you make in back-end, get the current time to use it in header to generate the signature.

As an aside, there have been a lot of blind "regenerate your IAM credentials" suggestions to users who've explicitly said it's not an option for them.

This is not helpful to the users, and distracts from the fact that this is a known bug that continues to affect aws-cli users attempting to use valid IAM credentials.

Running into this as well.
$ aws --version
aws-cli/1.16.300 Python/2.7.16 Linux/4.14.152-127.182.amzn2.x86_64 botocore/1.13.36

My keys are completely alpha-numeric, no special characters.

The keys work from the shell, however when used via Jenkins in a Makefile target, this error occurs. Not sure what is happening here.

My secret key has both / and + in it. Running into this issue and have tried:

• Trough aws-cli > aws iam get-user (using ~/.aws/credentials file)
• boto3 (through python 3.6.8)
  
  
  
  • Hardcoded keys
  
  
  • Envirnoment Variable
  
  
  • Argument boto3.Session(profile_name=PROFILE) (which pulls from ~/.aws/credentials)
  
  

All of these result in the SignatureDoesNotMatch error.

I currently cannot regenerate the key.

What I don't understand is that I can use the S3 Protocol in Cyberduck (https://cyberduck.io/) and it works as expected. How could that be?

This has to be one of the most frustrating bugs I have encountered and it's nuts that it hasn't been fixed. Getting a cred without a "+" worked for me in CircleCI.

Is it still crashing? facing the same problem, wow i cannot be possible...

Yes, it is frustrating. My secret key that had a + didn't work in a Jenkins pipeline, but when I generated a new one, which only had a few of /, worked fine.

I had this issue on package installed version of awscli on Ubuntu 16.04. I fixed it by installing awscli as a python pip package.
For instructions, follow this link under section Installing AWS CLI using Python PIP

_Issue Encountered_

1) Encountered the InvalidSignatureException error after regenerating the Access Key
2) Partial Error log is as provided below.

$ python SetupAWS.py list_things
Traceback (most recent call last):
File "SetupAWS.py", line 222, in
list_things()
File "SetupAWS.py", line 182, in list_things
things = client.list_things()['things']
File "c:Program Files (x86)Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", line 316, in _api_call
return self._make_api_call(operation_name, kwargs)
File "c:Program Files (x86)Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", line 626, in _make_api_call
raise error_class(parsed_response, operation_name)
botocore.exceptions.ClientError: An error occurred (InvalidSignatureException) when calling the ListThings 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.

_Root Cause Analysis_

1) As suggested by many in their comments above, the presence of "+" in my Secret Access Key was resulting in the above error.

_Resolution_

1) Generated new Access Key as an IAM User and verified that the new Secret Access Key does not contain a "+" within the string.
2) Ran the aws configure command and provided the new values.
3) Ran the python SetupAWS.py list_things command, which successfully listed my thing, as shown below,

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

This issue has been open for six years, and I thank you for your patience, persistence, and the information you have provided. A few underlying causes have been identified through your comments (https://github.com/aws/aws-cli/issues/602#issuecomment-520469209) and compiled into the Command Line User Guide Troubleshooting Errors chapter. These causes include clock skew and some operating systems mishandling keys with special characters.

I attempted to reproduce this using a number of different environments. I used Ubuntu 16.04, Ubuntu 18.04, and Amazon Linux 2, with Python 3.6.8 and 3.8.3. While many commenters used Python 2, I did not attempt to reproduce since it is no longer supported. I used the latest v1 aws-cli (1.18.80 at the time of writing) as well as an older version (1.11.78) referenced in this issue. I used the script provided (https://github.com/aws/aws-cli/issues/602#issuecomment-281866173) by @jamesls that creates new credential pairs until it encounters one with special characters and let them run for up to an hour each. I did not have any occurrences of a SignatureDoesNotMatch error. I received occasional AuthFailure errors on the describe-instances command, but a retry of the command with the same credentials succeeds.

The large number of comments makes it difficult for new users coming to this issue to find requests from our developer team for troubleshooting suggestions. To assist our team and the community in determining a cause of this error, I am closing this issue and creating a specific GitHub issue template that includes guidance and comment requirements for users encountering this error.

If you encounter this error, please head over to the issues tab, click the “New Issue” button, and use the template for a SignatureDoesNotMatch error report (or use the link below).

Due to the variation of user environments where this error occurs, please file a separate issue instead of commenting on an existing one.

Click here to file a SignatureDoesNotMatch error report