Need help?

Our experts have had an average response time of 11.7 minutes in August 2021 to fix urgent issues.

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

EC2 Server Refused our Key in Amazon Elastic Compute Cloud

by | Jul 18, 2021

Stuck with the error, EC2 Server refused our key? We can help you.

We may come across this error while we connect to Amazon Elastic Compute Cloud (Amazon EC2) instance using SSH.

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see how we can fix this error.


EC2 Server refused our key

There are multiple reasons why an SSH server (sshd) refuses a private SSH key.

The following are some common reasons you might receive this error:

  • An incorrect user name for the AMI while connecting to the EC2 instance.
  • The user we try to access the instance was deleted from the server or the account was locked.
  • Permissions issues on the instance or a missing directory.
  • An incorrect private key file for the EC2 instance.
  • Change in SSH server settings in /etc/ssh/sshd_config.
  • The operating system couldn’t mount (/etc/fstab) home directories.


How to fix this error?

Moving ahead, let us see how our Support Techs fix this error in different scenarios.


An incorrect user name for the AMI

Suppose we get this error while we use PuTTY to connect, then we verify that we connect with the appropriate user name for the AMI.

The appropriate user names are as follows:

For Amazon Linux 2 or the Amazon Linux AMI: ec2-user.
For a CentOS AMI: centos.
For a Debian AMI: admin.
For a Fedora AMI: fedora.
For a RHEL AMI: ec2-user or root.
For a SUSE AMI: ec2-user or root.
For an Ubuntu AMI: ubuntu.

However, if the ec2-user and root don’t work, we check with the AMI provider.


The user was deleted from the server or the account was locked

In case the user was deleted from the server, we add the user back as a new user.

1. To do so, we connect to the Linux instance via SSH.

2. Then we use the adduser command:

$ sudo adduser new_user

Here, we replace the new_user with the new account name.

In the case of an Ubuntu instance, we include the –disabled-password option to avoid adding a password to the new account:

$ sudo adduser new_user --disabled-password

3. After that, for folders and files to have the correct permissions we change the security context to the new_user account:

$ sudo su - new_user

4. We create a .ssh directory in the new_user home directory:

$ mkdir .ssh

5. Eventually, to change the .ssh directory’s permissions to 700, we use the chmod command:

$ chmod 700 .ssh

6. Then we use the touch command to create the authorized_keys file in the .ssh directory:

$ touch .ssh/authorized_keys

7. To change the .ssh/authorized_keys file permissions to 600, we run:

$ chmod 600 .ssh/authorized_keys


Permissions issues on the instance or a missing directory

Our Support Techs suggest four methods to verify permissions and directories on the instance:

Method 1: Use the EC2 Serial Console

If we have the EC2 Serial Console for Linux, then we can use it to troubleshoot supported Nitro-based instance types.

We can access it using the Amazon EC2 console or the AWS Command Line Interface (AWS CLI).

However, before we begin, we need to must grant access to it at the account level. Then, we must create AWS IAM policies granting access to the IAM users.

In addition, every instance that uses it must include at least one password-based user.

Method 2: Use AWS Systems Manager Session Manager to log into the instance and check permissions

Our Support Techs recommend installing an SSM Agent to use this method.

1. Initially, we open the AWS Systems Manager console.

2. We go ahead and start a session.

3. Then we use the stat command to make sure the permissions of the files under the home directory are correct.

The correct permissions are:

  • Linux home directory: /home.
  • User’s home directory: /home/ec2-user/.
  • .ssh directory permission: /home/ec2-user/.ssh.
  • authorized_keys file permission: /home/ec2-user/.ssh/authorized_keys.

For example, here we can see the stat command and the resulting output.

$ stat /home/ec2-user/
File: '/home/ec2-user/'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 10301h/

We need to change the user name according to the specific AMI.

Method 3: Automatically correct issues by running the AWSSupport-TroubleshootSSH document

AWSSupport-TroubleshootSSH automation document installs the Amazon EC2Rescue tool on the instance.

Then it checks and corrects few issues that cause remote connection errors.

Method 4: Use user data to fix permissions on the instance

1. To do so, we open the Amazon EC2 console, and then select the instance.

2. We select Instance State > Stop instance.

3. Then we select Actions > Instance Settings > Edit User Data.

4. After that, in the User Data field we copy the following script. Eventually, we click Save.

Make a note to change ec2-user to the user name for the AMI.

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

- [scripts-user, always]

Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

chown root:root /home
chmod 755 /home
chown ec2-user:ec2-user /home/ec2-user -R
chmod 700 /home/ec2-user /home/ec2-user/.ssh
chmod 600 /home/ec2-user/.ssh/authorized_keys

We need to copy the entire script and should not add extra spaces.

5. Finally, we start the instance and then SSH into the instance.

[Need help with the fix? We’d be happy to help]



In short, we saw how our Support Techs fix the error, EC2 Server refused our key.


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.


var google_conversion_label = "owonCMyG5nEQ0aD71QM";


Submit a Comment

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

Privacy Preference Center


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]


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


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


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.