Why do I receive the error "Server refused our key" when I try to connect to my EC2 instance through SSH?

6 minute read

I receive the error "Server refused our key" when I connect to my Amazon Elastic Compute Cloud (Amazon EC2) instance through SSH.

Short description

There are multiple reasons why an SSH server (sshd) refuses a private SSH key. The following are some common reasons that you receive this error:

You use the incorrect private key file when you try to connect to your Amazon EC2 instance. For more information, see Why do I receive the errors "imported-openssh-key" or "PuTTY Fatal Error" when I connect to my Amazon EC2 Linux instance?
SSH server settings in /etc/ssh/sshd_config were changed. For more information, see How do I use SSH to access my EC2 instance after changing the instance's sshd_config file?
The operating system couldn't mount (/etc/fstab) home directories. For more information, see Why is my EC2 Linux instance going into emergency mode when I try to boot it?

Resolution

You use the incorrect username for your AMI when you try to connect to your Amazon EC2 instance

The usual usernames are ec2-user, ubuntu, centos, root, or admin. For a list of valid usernames, see Error: Server refused our key or No supported authentication methods available.

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

If the user that tries to access the instance is deleted from the server, add the user back as a new user. For more information, see How do I add new user accounts with SSH access to my Amazon EC2 Linux instance?

There are permissions issues on the instance or you're missing a directory

There are four methods to verify permissions and directories on the instance:

Method 1: Use the EC2 serial console

If you turn on Amazon EC2 serial console for Linux, then you can use the serial console to troubleshoot supported Nitro-based instance types. You can access the serial console through the Amazon EC2 console or the AWS Command Line Interface (AWS CLI). For more information, see Configure access to the EC2 Serial Console.

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

Note: Installation of the SSM Agent is required to use this method. For more information on Session Manager and a complete list of prerequisites, see Setting up Session Manager.

Open the AWS Systems Manager console.
Start a session.

Use the stat command to make sure the permissions of the files under the home directory are correct. The following is a list of the correct permission examples:
Linux home directory, /home, (0755/drwxr-xr-x).
User's home directory, /home/ec2-user/, (0700/drwx------).
.ssh directory permission, /home/ec2-user/.ssh, (0700/drwx------).
authorized_keys file permission, /home/ec2-user/.ssh/authorized_keys, (0600/-rw-------).
The following is an example of the stat command and the output. In this example, ec2-user is the username. Change the username to your specific AMI:

$ stat /home/ec2-user/  File: '/home/ec2-user/'
  Size: 4096          Blocks: 8          IO Block: 4096   directory
Device: 10301h/66305d    Inode: 18322       Links: 3
Access: (0700/drwx------)  Uid: (  500/ec2-user)   Gid: (  500/ec2-user)

If the permissions don't match the preceding values, then run the following commands:

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

End the session.
SSH to your instance.

Method 3: To automatically correct issues that cause the error, run the AWSSupport-TroubleshootSSH document

AWSSupport-TroubleshootSSH automation document installs the Amazon EC2Rescue tool on the instance. And then the automation document checks for and corrects issues that cause remote connection errors during a Linux machine connection through SSH. For more information, see I'm receiving errors when trying to connect to my EC2 instance using SSH. How can I use the AWSSupport-TroubleshootSSH automation workflow to troubleshoot SSH connection issues?

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

Important:

This recovery procedure requires you to stop and start your instance. When you do this, the data on instance store volumes is lost. For more information, see Root volumes for your Amazon EC2 instances.
If your instance is part of an Amazon EC2 Auto Scaling group, then the instance might end when stopped. This can also occur on instances launched by services that use AWS Auto Scaling, such as Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk. Instance end in this scenario depends on the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, then remove the instance from the Auto Scaling group before you start the resolution steps. You can add the instance back to the Auto Scaling group after you complete the resolution steps.
A stop and restart of the instance changes the public IP address of your instance. It's a best practice to use an Elastic IP address instead of a public IP address when you route external traffic to your instance.
You can't change the SSH key with user data if your instance's root device is an instance store volume. For more information, see Root volumes for your Amazon EC2 instances.
Updates to your instance's user data applies to all distributions that support cloud-init directives. Cloud-init must be installed and configured. For more information, see SSH - Configure SSH and SSH keys on the Cloud-init website.

Complete the following steps:

Open the Amazon EC2 console, and then choose your instance.
Choose Instance State, and then choose Stop instance.
Note: If Stop is not available, either the instance is already stopped or its root device is an instance store volume.
Choose Actions, choose Instance Settings, and then choose Edit User Data.

Copy the following command into the User Data field, and then select Save. Make sure to copy the entire command, and don't add extra spaces.
Note: The following command uses the username ec2-user. Change ec2-user to the username for your 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
--//

Start the instance, and then use SSH to connect to the instance.
Note: By default, the user data command runs one time per instance. This procedure changes the default behavior to add the public key to every reboot, stop, or start of the instance. To restore the default behavior, remove the custom user data. It's a best practice to follow the security protocols and allow user data to run after the first boot of an instance. Modify the user data of an instance with the ModifyInstanceAttribute API method. To restrict access to this method, use IAM policies.