Why do I receive the "Server refused our key" error message 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.

Resolution

The SSH server (sshd) might refuse a private SSH key for one of the following reasons:

You used the incorrect private key file when you connected to your Amazon EC2 instance. To troubleshoot this issue, see Why do I receive the errors "imported-openssh-key" or "PuTTY Fatal Error" when I connect to my Amazon EC2 Linux instance?
Someone changed the SSH server settings in /etc/ssh/sshd_config. To troubleshoot this issue, see How do I use SSH to access my EC2 instance after changing the instance's sshd_config file?
The operating system (OS) couldn't mount the /etc/fstab home directories. To troubleshoot this issue, see Why is my EC2 Linux instance going into emergency mode when I try to boot it?
You used the incorrect username for your Amazon Machine Image (AMI) when you connected to your Amazon EC2 instance. For a list of valid usernames, see Error: Server refused our key or No supported authentication methods available.
Someone deleted the user from the server. To troubleshoot this issue, add the user back to the server as a new user.

You might also receive the Server refused our key error message if your instance has permissions issues or is missing a directory. To verify your instance permissions and directories, use one of the following methods.

Use the EC2 Serial Console

If you activated the EC2 Serial Console for Linux, then you can use the serial console to troubleshoot supported Nitro-based instance types.

Use Systems Manager to log in to the instance and check the permissions

Prerequisite: Install the AWS Systems Manager Agent (SSM Agent). Also, make sure that your configuration adheres to the prerequisites for Session Manager, a capability of AWS Systems Manager.

To use Session Manager to troubleshoot your instance, complete the following steps:

Open the Systems Manager console.
Start a session.

To make sure that the files under the home directory have the correct permissions, run the following command:

stat /home/ec2-user/  
ls -ld /home               # Should show drwxr-xr-x (755)
ls -ld /home/ec2-user      # Should show drwx------ (700)
ls -ld /home/ec2-user/.ssh # Should show drwx------ (700)
ls -l /home/ec2-user/.ssh/authorized_keys # Should show -rw------- (600)

Note: Replace ec2-user with correct username for your AMI.
In the output, check the Access to make sure that your configuration uses the following permissions:
The /home Linux home directory must have 0755/drwxr-xr-x permissions.
The /home/ec2-user/ user's home directory must have 0700/drwx------ permissions.
The /home/ec2-user/.ssh .ssh directory permission must have 0700/drwx------ permissions.
The /home/ec2-user/.ssh/authorized_keys authorized_keys file permission must have 0600/-rw------- permissions.
Example output:

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)

To update your configuration's permissions, 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

Note: Replace ec2-user with correct username for your AMI.

End the session.
Use SSH to connect to your instance.

Run the AWSSupport-TroubleshootSSH runbook

To automatically correct issues that cause errors, run AWSSupport-TroubleshootSSH. The runbook installs the Amazon EC2Rescue tool on the instance, and then identifies and corrects issues that cause remote connection errors during 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?

Use user data to fix permissions on the instance

Important: Before you stop and start your instance, take the following actions:

Create a backup of your Amazon Elastic Block Store (Amazon EBS) volume.
Note: If your instance is instance store-backed or has instance store volumes that contain data, then Amazon EC2 deletes the data when you stop the instance. You can't change the SSH key with user data if your instance's root device is an instance store volume.
Temporarily remove the instance from its Amazon EC2 Auto Scaling group when you're completing the resolution steps.
Note: If you stop an instance that's in an EC2 Auto Scaling group, then you might terminate the instance based on your scale-in protection settings. Instances that you launch with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk might be in an Auto Scaling group.
Set the instance shutdown behavior to Stop to make sure that the instances don't terminate when you stop them.
Install and configure cloud-init. For more information, see Configure SSH and SSH keys on the cloud-init website.
Important: Updates to your instance's user data affect all distributions that support cloud-init commands.

Note: When you stop and start an instance, the instance's public IP address changes. It's a best practice to use an Elastic IP address to route external traffic to your instance instead of a public IP address. If you use Amazon Route 53, then you might need to update the Route 53 DNS records when the public IP address changes.

To use user data to fix permissions issues, complete the following steps:

Open the Amazon EC2 console.
In the navigation pane, choose Instances, and then select your instance.
Choose Instance state, and then choose Stop instance.
Note: If you can't choose Stop instance, then the instance is already stopped or its root device is an instance store volume.
Choose Actions, and then choose Instance settings.

Choose Edit user data, and then enter the following command:

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
--//

Note: Replace ec2-user with the correct username for your AMI. Don't add extra spaces when you enter the preceding command.

Choose Save.
Start the instance, and then use SSH to connect to the instance.

By default, the user data command runs one time for each instance. The preceding steps change the default behavior to add the public key at each reboot, stop, or start of the instance. To restore the default behavior, remove the custom user data commands. It's a best practice to allow user data to run after the instance's first boot. You can use the ModifyInstanceAttribute API to modify an instance's user data. To restrict access to the ModifyInstanceAttribute API, use AWS Identity and Access Management (IAM) policies.