Authentication Failure Due to Signature Mismatch

If Hadoop cannot authenticate with the S3 service endpoint, the client retries a number of times before eventually failing. When it finally gives up, it will report a message about signature mismatch:

com.amazonaws.services.s3.model.AmazonS3Exception:
 The request signature we calculated does not match the signature you provided.
 Check your key and signing method.
  (Service: AmazonS3; StatusCode: 403; ErrorCode: SignatureDoesNotMatch,

The likely cause is that you either have the wrong credentials for any of the current authentication mechanism(s) — or somehow the credentials were not readable on the host attempting to read or write the S3 bucket.

Enabling debug logging for the package org.apache.hadoop.fs.s3a can help provide more information.

The standard first step is: try to use the AWS command line tools with the same credentials, through a command such as:
```
hdfs fs -ls s3a://my-bucket/
```
Note the trailing "/" here; without that the shell thinks you are trying to list your home directory under the bucket, which will only exist if explicitly created.
Attempting to list a bucket using inline credentials is a means of verifying that the key and secret can access a bucket:
```
hdfs fs -ls s3a://key:secret@my-bucket/
```
Do escape any + or / symbols in the secret, as discussed below, and never share the URL, logs generated using it, or use such an inline authentication mechanism in production.
Finally, if you set the environment variables, you can take advantage of S3A's support of environment-variable authentication by attempting the same ls operation; that is, unset the fs.s3a secrets and rely on the environment variables.
Make sure that the name of the bucket is the correct one. That is, check the URL.
Make sure the property names are correct. For S3A, they are fs.s3a.access.key and fs.s3a.secret.key. You cannot just copy the S3N properties and replace s3n with s3a.
Make sure that the properties are visible to the process attempting to talk to the object store. Placing them in core-site.xml is the standard mechanism.
If using session authentication, the session may have expired. Generate a new session token and secret.
If using environment variable-based authentication, make sure that the relevant variables are set in the environment in which the process is running.

​Authentication Failure Due to Signature Mismatch

Authentication Failure Due to Signature Mismatch