Why am I getting a "Server refused our key" error when I try to connect to my EC2 instance using SSH?
Last updated: 2022-11-21
I'm receiving the "Server refused our key" error when connecting to my Amazon Elastic Compute Cloud (Amazon EC2) instance using SSH.
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 I made changes to my EC2 instance's sshd_config file. 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 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
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
- 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 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 IAM policies.