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

Last updated: 2020-04-01

I'm trying to connect to my Amazon Elastic Compute Cloud (Amazon EC2) instance using SSH but I'm getting a "Server refused our key" error. How can I fix this?

Short Description

There are multiple reasons you might receive the Server refused our key error:

  • You're using the incorrect user name for your AMI when connecting to your EC2 instance.
  • There are permissions issues on the instance or you're missing a directory.
  • The user trying to access the instance was deleted from the server.


Verify that you're using the correct user name for your AMI.

For a list of valid user names, see Troubleshooting Connecting to Your Instance - Error: Server Refused our key or No supported authentication methods available.

Verify that the correct permissions are set for the instance and that no directories are missing.

There are three methods for verifying permissions and directories on the instance:

Method 1: 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 Getting Started with 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, 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.    Terminate the session.

6.    SSH to your instance.

Method 2: Automatically correct issues causing the error

Run the AWSSupport-TroubleshootSSH automation 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 How can I use the AWSSupport-TroubleshootSSH Automation workflow to troubleshoot SSH connection issues?

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


  • Don't perform procedures that require a stop and restart of your EC2 instance if your instance is instance store-backed or has instance store volumes containing data. This recovery procedure requires you to stop and start your instance. Doing this means that data on instance store volumes is lost. For more information, see Determining the Root Device Type of Your Instance.
  • If your instance is part of an Amazon EC2 Auto Scaling group, or if your instance is launched by services that use AWS Auto Scaling, such as Amazon EMR, AWS CloudFormation, AWS Elastic Beanstalk, and so on, then stopping the instance could terminate the instance. 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, 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 Determining 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 Configure ssh and ssh keys.

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

2.    Choose Actions, choose Instance State, and then choose Stop.

Note: If Stop is disabled, either the instance is already stopped or its root device is an instance store volume.

3.    Choose Actions, choose Instance Settings, and then choose View/Change 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"

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

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 AWS Identity and Access Management (IAM) policies.

Check if the user was deleted from the server

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?