Complete a 3 Question Survey and Earn a re:Post Badge

Help improve AWS Support Official channel in re:Post and share your experience - complete a quick three-question survey to earn a re:Post badge!

How do I resolve the "Permission denied (publickey)" or "Authentication failed, permission denied" errors when I access my EC2 instance?

7 minute read

When I access my Amazon Elastic Compute Cloud (Amazon EC2) instance, I receive the "Permission denied (publickey)" or "Authentication failed, permission denied" error.

Short description

The Permission denied (publickey) and Authentication failed, permission denied errors occur for the following reasons:

You use the wrong username for your Amazon Machine Image (AMI) when you connect.
You have incorrect file permissions in the instance's operating system (OS).
The authorized_keys file has the incorrect SSH public key (.pub) file or you launched your instance without a key.
Your authorized_keys file or .ssh folder isn't named correctly.
Your authorized_keys file or .ssh folder was deleted.
(Ubuntu 20.x only) You use AuthorizedKeysCommand in your SSH configuration.

Resolution

Verify that you have the correct username for your AMI

Make sure that you use a valid username for your AMI.

Verify that the file permissions in the OS are correct and that the correct SSH public key is in the authorized_keys file

To verify your configuration, use one of the following methods.

Use the EC2 serial console

If you activated EC2 serial console for Linux, then you can use the console to troubleshoot supported Nitro-based instance types. The serial console connects to your instance without the need for a network connection. You can access the serial console through the Amazon EC2 console or the AWS Command Line Interface (AWS CLI).

Before you use the serial console, grant access to it at the AWS account level. Then, create AWS Identity and Access Management (IAM) policies that grant access to the console for your IAM users. Each instance that uses the serial console must include at least one password-based user. For information about how to configure the EC2 serial console for Linux, see Configure access to the EC2 serial console.

If your instance is unreachable and you haven't configured access to the serial console, then use another method to verify your configuration.

Note: If you receive errors when you run AWS CLI commands, then see Troubleshooting errors for the AWS CLI. Also, make sure that you're using the most recent AWS CLI version.

Use Systems Manager Session Manager

Note: To use this method, you must install the SSM Agent. For a list of prerequisites to use Systems Manager, see Step 1: Complete Session Manager prerequisites.

Use the AWS Systems Manager Session Manager to log in to the instance and make corrections. Complete the following steps:

Open the Systems Manager console.
Start a session.
To check whether the permissions of the files under the home directory are correct, run the ls -ld command:
```
ls -ld /home/ec2-user/
```
Note: Replace ec2-user with your username based on your instance Amazon Machine Image (AMI).
You receive an output similar to the following example:
```
drwx------ 3 ec2-user ec2-user 4096 Apr  1 08:31 /home/ec2-user/
```
The following example shows a list of the correct required permissions:
For the /home Linux home directory, use (0755/drwxr-xr-x).
For the /home/ec2-user/ user's home directory, use (0700/drwx------).
For the /home/ec2-user/.ssh .ssh directory permission, use (0700/drwx------).
For the /home/ec2-user/.ssh/authorized_keys authorized_keys file permission, use (0600/-rw-------).
On your local computer, verify that you use an SSH public key.

If the signature of the SSH public key isn't in the output, then update the authorized_keys file to allow your SSH key. Run the following command:

echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/ec2-user/.ssh/authorized_keys

Note: Replace the example key with your SSH public key.

To correct permissions, run the following commands on your EC2 instance:

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

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

Run the AWSSupport-TroubleshootSSH Automation runbook

Use AWSSupport-TroubleshootSSH to check for and correct issues that cause remote connection errors 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?

Use a user data script to repair SSH permissions and add the correct SSH public key to the authorized_keys file

Important: To use this method, you must stop the instance. When you stop the instance, the following effects occur:

If your instance is backed by an Amazon Elastic Block Storage (Amazon EBS) instance store or has instance store volumes with data, then the data is lost.
If your instance is part of an Amazon EC2 Auto Scaling group, then Amazon EC2 Auto Scaling might terminate the instance. Instances that you launch with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk might be part of an Auto Scaling group. Instance termination in this case 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 you complete the following steps.
The instance's public IP address changes. It's a best practice to use an Elastic IP address instead of a public IP address when you route external traffic to your instance.

To repair your SSH permissions, complete the following steps:

Open the Amazon EC2 console.
Choose Instances from the navigation pane, and then select the instance that you want to launch.
Stop the instance.
Choose Actions, and then choose Instance settings.
Choose Edit User Data.

For Edit user data, enter the following user data script:

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
OS_USER=os-user
chown root:root /home 
chmod 755 /home
chown $OS_USER:$OS_USER /home/$OS_USER -R
chmod 700 /home/$OS_USER
chmod 700 /home/$OS_USER/.ssh
chmod 600 /home/$OS_USER/.ssh/authorized_keys
--//

Note: Replace os-user with the username associated with the AMI that you used to launch your instance.

Choose Save.
On your local computer, verify that you use an SSH public key.

If the signature of the SSH public key isn't in the output, then add the key to the user data script. If the signature matches, then proceed to the next step.

Example user data script with a SSH public key:

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
OS_USER=os-user
chown root:root /home 
chmod 755 /home
chmod 700 /home/$OS_USER
chmod 700 /home/$OS_USER/.ssh
chmod 600 /home/$OS_USER/.ssh/authorized_keys
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/$OS_USER/.ssh/authorized_keys
chown $OS_USER:$OS_USER /home/$OS_USER -R
--//

Start your instance.

Note: The preceding user data script is set to run on each instance reboot of the instance. After you regain access to your instance, remove the user data script.

(Ubuntu 20.x only) Check the AuthorizedKeysCommand for SSH configuration

In Ubuntu 20.x, EC2 Instance Connect is installed by default. When you configure the AuthorizedKeysCommand and AuthorizedKeysCommandUser settings for SSH authentication, the EC2 Instance Connect installation doesn't update these settings. As a result, you can't use EC2 Instance Connect. To resolve this issue, remove AuthorizedKeysCommand and AuthorizedKeysCommandUser from your SSH configuration.