Why am I getting a "Server refused our key" error when I try to connect to my EC2 instance using SSH?

7 minute read

I'm receiving the "Server refused our key" error when connecting to my Amazon Elastic Compute Cloud (Amazon EC2) instance using 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 might receive this error:

You're using the incorrect user name for your AMI when connecting to your EC2 instance. The usual user names are ec2-user, ubuntu, centos, root, or admin.
The user trying to access the instance was deleted from the server or the account was locked.
There are permissions issues on the instance or you're missing a directory.
You're using the incorrect private key file when connecting to your EC2 instance. For more information, see the Verify that the private key is correct section in Why am I receiving "imported-openssh-key" or "Putty Fatal Error" errors when connecting to my Amazon Elastic Compute Cloud (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 the Dependency failed errors section in Why is my EC2 Linux instance not booting and going into emergency mode?

Resolution

You're using the incorrect user name for your AMI when connecting to your EC2 instance

For a list of valid user names, see Error: Server refused our key or No supported authentication methods available.

The user trying to access the instance was deleted from the server or the account was locked

If the user trying to access the instance was 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 for verifying permissions and directories on the instance:

Method 1: Use the EC2 Serial Console

If you’ve turned on EC2 Serial Console for Linux, then you can use the serial console to troubleshoot supported Nitro-based instance types. The serial console helps you troubleshoot boot issues, network configuration, and SSH configuration issues. The serial console connects to your instance without requiring a working network connection. You can access the serial console using the Amazon EC2 console or the AWS Command Line Interface (AWS CLI).

Before using the serial console, you must grant access to it at the account level. Then, you must create AWS Identity and Access Management (IAM) policies granting access to your IAM users. Also, every instance using the serial console must include at least one password-based user. If your instance is unreachable and you haven’t configured access to the serial console, follow the instructions in Method 2, 3, or 4. For information on configuring the EC2 Serial Console for Linux, see Configure access to the EC2 Serial Console.

Method 2: Use AWS Systems Manager Session Manager to log into 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.

1. Open the AWS Systems Manager console.

2. Start a session.

3. 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 permissions:

Linux home directory, /home, for example, should be (0755/drwxr-xr-x).
User's home directory, /home/ec2-user/, for example, should be (0700/drwx------).
.ssh directory permission, /home/ec2-user/.ssh, for example, should be (0700/drwx------).
authorized_keys file permission, /home/ec2-user/.ssh/authorized_keys, for example, should be (0600/-rw-------).

The following is an example of the stat command and the resulting output. In this example, ec2-user is the user name. Change the user name according 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)

4. 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

5. End the session.

6. SSH to your instance.

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

AWSSupport-TroubleshootSSH automation document installs the Amazon EC2Rescue tool on the instance, and then checks for and corrects some issues that cause remote connection errors when connecting to a Linux machine 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 Determine the root device type of your instance.
If your instance is part of an Amazon EC2 Auto Scaling group, then the instance might terminate when stopped. This might also occur on instances launched by services that use AWS Auto Scaling, such as Amazon EMR, AWS CloudFormation, AWS Elastic Beanstalk, and so on. Instance termination 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 temporarily remove the instance from the Auto Scaling group before starting the resolution steps.
Stopping and restarting 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 routing external traffic to your instance.
You can't change the SSH key using user data if your instance's root device is an instance store volume. For more information, see Determine the root device type of your instance.
Updating your instance's user data applies to all distributions that support cloud-init directives. Cloud-init must be installed and configured for these instructions to be successful. For more information about the cloud-init SSH module, see SSH - Configure SSH and SSH keys in the Cloud-init documentation.

1. Open the Amazon EC2 console, and then select your instance.

2. 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.

3. Choose Actions, choose Instance Settings, and then choose Edit User Data.

4. Copy the following script into the User Data field, and then select Save. Make sure to copy the entire script, and don't add extra spaces.

Note: The following script uses the user name ec2-user. Change ec2-user to the user name 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
--//

5. Start the instance and then SSH into the instance.

Note: By default, the user data script runs once 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. As a best practice, consider the security implications of allowing user data to run after the first boot of an instance. You can modify the user data of an instance with the ModifyInstanceAttribute API method. To restrict access to this method, use IAM policies.