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"

#cloud-config
cloud_final_modules:
- [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"

#!/bin/bash
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]

Conclusion

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