Need help?

Our experts have had an average response time of 13.14 minutes in February 2024 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

AWS was not able to validate the provided access credentials – How to fix?

by | Aug 18, 2020

The describe-regions command describes the regions that are enabled for your AWS account. At times this command fails with the error message “AWS was not able to validate the provided access credentials”.

As a part of our Server Management Services, we help our Customers to fix AWS related errors regularly.

Let us today discuss the possible causes and fixes for this error.

What causes error AWS was not able to validate the provided access credentials ?

As we discussed earlier, while trying to run the ‘aws ec2 describe-regions’ command, it at times fails with the error as given below:

1. The version of Session tokens: The AWS Security Token Service (AWS STS) supports an updated version format for session tokens. New AWS Regions not enabled by default use the updated AWS STS format. The global AWS STS endpoint (sts.amazonaws.com) issues tokens in the previous format by default. This error can occur if a session token is trying to use the previous format with an AWS Region not enabled by default.

2. Timestamp of Authentication tokens: If date or time is wrong on the local computer, or date/time is wrong for VM/instance, then the credentials will be invalid and we will get “AWS was not able to validate the provided credentials”.

3. AWS CLI is Boto based: Boto can pick up credentials from all sorts of places. It saves the old authentication values in the file location $HOME/.boto

4. File format issue: File format of sourced bash file containing the environment variables at times causes the ID and SECRET variables to have invisible trailing whitespace. This in turn causes issues with the AWS authentication.

How to fix error AWS was not able to validate the provided access credentials ?

Let us now look at the possible methods to fix the issue:

The version of Session tokens

Tokens obtained from Regional endpoints use the new version format and are valid in all AWS Regions. It is a best practice to use Regional STS endpoints. This is because using an endpoint that is geographically closer to your application means that it can access STS services with lower latency and with better response times.

Use one of the following methods to resolve this issue.

(a) Obtain tokens from a Regional endpoint

(b) Change Region compatibility of session tokens for global endpoint

Timestamp of Authentication tokens

While using the the AWS CLI, we need to set the credentials first. To set credentials use the below command.

$ aws configure

If it is shows the same error again, then we need to check the Machine time and sync with standard time. We can set the time with command below or NTP.

sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

sudo ntpclient -s -i 1 -l -d -h 0.amazon.pool.ntp.org  //To sync the clock for VM/instance

For the machine running the host kernel, OS client sending the API call includes a timestamp in the API call headers. If the difference between the timestamp and AWS clock is too big, the API call will be rejected with “AuthFailure”. Assuming ntpd is installed on the system where you are running the AWS CLI commands, you can try the following commands in order:

date
sudo service ntpd stop
sudo ntpdate time.nist.gov
sudo service ntpd start
ntpstat

After this the OS clock should be synchronized with NTP. Finally, make sure to run the configure command.

AWS CLI is Boto based

Another method to fix the error is to ensure that the login credentials mentioned in .boto file is correct.

cat ~/.boto

[Credentials]
aws_access_key_id=MY*OLD*ACCESS*KEY
aws_secret_access_key=MY*OLD_SECRET*ACCESS*KEY

If not, we need to update the values in .boto file.

Alternate Fixes

If you manage AWS services from AWS CLI command using “aws configure”, you have a credential file generated in the home directory.

#cat /root/.aws/credentials
[default]
aws_access_key_id=XXXXXXXXXX
aws_secret_access_key=XXXXXXXX

Make sure the “aws_access_key_id” and “aws_secret_access_key” are correct as taken from IAM of AWS or create a new access key from IAM and change it accordngly in the credentials file.

Apart from the fixes mentioned above, fixing the file format on the bash sourced file and reloading the environment variables can also help to fix the error. It would also be a good idea to check the permission of the IAM user and ensure it has administrator access policy attached to it via the group.

[Need any further assistance in fixing AWS errors? – We’re available 24*7]

Conclusion

In short, the describe-regions command at times fails with the error message “AWS was not able to validate the provided access credentials”. Today, we saw how our Support Engineers fix this error.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

2 Comments

  1. Carlos Saltos

    Thanks for the help !! … in my case was the computer clock configuration 😉 🙂

    Reply
  2. Tejas Chaudhari

    thanks

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF