Why am I getting a "Server refused our key" error when I try to connect to my EC2 instance using SSH?
Last updated: 2021-03-12
I'm receiving the "Server refused our key" error when connecting to my Amazon Elastic Compute Cloud (Amazon EC2) instance using SSH. How can I fix this?
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:
- 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 I made changes to my EC2 instance's sshd_config file and now I can't access my instance using SSH. How do I resolve this?
- 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?
You're using the incorrect user name for your AMI when connecting to your EC2 instance
For a list of valid user names, see Troubleshooting Connecting to Your Instance - 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 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
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. End the session.
6. SSH to your instance.
Method 2: 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 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
- 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 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, 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.
1. Open the Amazon EC2 console, and then select your instance.
2. Choose Instance State, and then choose Stop instance.
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 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 AWS Identity and Access Management (IAM) policies.