SSH Permission Denied (Publickey) Error on AWS EC2: Authorized Keys Modification

Resolve the SSH Permission Denied (Publickey) error on AWS EC2 by verifying that the correct private key is used, ensuring file permissions are strict, and confirming the public key is appended to the ~/.ssh/authorized_keys file. This guide details how to diagnose misconfigurations in key ownership, permission bits, and SELinux contexts that block authentication.

Verify Key Pair Matching and Usage

The most common cause of this error is a mismatch between the private key you are presenting and the public key stored on the server. AWS EC2 instances rely on specific key pairs generated during instance creation or via the AWS Management Console. If you attempt to log in with a different private key than the one associated with the instance, the SSH daemon will reject the connection immediately. Ensure you are using the correct key file. When connecting from a Linux or macOS terminal, use the -i flag to specify the path to your private key file. For example:

ssh -i /path/to/private-key.pem ec2-user@your-instance-ip

If you are using Windows with PuTTY, ensure the .ppk file matches the original key pair. A frequent mistake is generating a new key pair locally and trying to use it against an existing instance without uploading the corresponding public key to AWS. You cannot recover access if the wrong key is used unless you have another method of entry, such as the AWS Systems Manager Session Manager or console serial access.

Check File Permissions on the Server

SSH is extremely sensitive to file permissions for security reasons. If the authorized_keys file or the .ssh directory has permissions that are too open, the SSH daemon will ignore them to prevent unauthorized access. The required permissions are strict:

• The .ssh directory must be owned by the user and have permissions set to 700.
• The authorized_keys file must be owned by the user and have permissions set to 600.
• The home directory should generally not be group or world writable.

To verify and fix these permissions, you can use the AWS EC2 Instance Connect or a rescue instance. If you have root access via another method, run the following commands as the target user:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

Incorrect permissions often occur when files are copied from another machine or created manually without respecting the default umask settings. Always ensure the ownership matches the login user, typically ec2-user for Amazon Linux or ubuntu for Ubuntu instances.

Validate Authorized Keys Content

Even with correct permissions, the content of the authorized_keys file may be corrupted or improperly formatted. Each line in this file represents a single public key. Ensure there are no extra spaces, line breaks within a single key, or trailing characters that might invalidate the key string. You can check the content by viewing the file:

cat ~/.ssh/authorized_keys

Compare the output with the public key you generated or uploaded. If the key was pasted incorrectly, it will not match the cryptographic hash expected by the server. In cases where multiple keys are present, ensure each key is on its own separate line. If you recently modified this file, ensure you did not accidentally delete other valid keys that might be needed for administrative access.

Review SSH Daemon Configuration

Sometimes the issue lies within the sshd_config file on the remote server. Check if PubkeyAuthentication is enabled. It should be set to yes:

PubkeyAuthentication yes

Additionally, verify that StrictModes is enabled. This setting forces sshd to check file permissions and ownership of the user's files and home directory before accepting login. If StrictModes is disabled, it might mask permission errors, but enabling it ensures security standards are met. Restart the SSH service after any changes to apply them:

sudo systemctl restart sshd

For deeper diagnostics, enable verbose logging on the client side by adding the -v flag to your SSH command. This reveals exactly where the authentication process fails, whether at the key exchange stage or the final permission check.

SELinux and Context Issues

On systems like CentOS or RHEL, SELinux may enforce additional restrictions on file contexts. If the authorized_keys file does not have the correct SELinux context, SSH may deny access even if Unix permissions are correct. Use the restorecon command to reset the context to defaults:

sudo restorecon -Rv ~/.ssh

This step is crucial for environments where SELinux is enforcing policies. Without the correct context, the security module treats the file as untrusted, blocking read operations by the SSH daemon.

Related Resources

If you need to set up SSH for a new user account, refer to our guide on Configuring a New User on AWS EC2 with SSH (Ubuntu). For broader troubleshooting of login failures, see Unable to Login via SSH to EC2 Linux Instance on AWS.

Frequently Asked Questions

What if I lost my private key?

You cannot recover the private key if it was never backed up. You must stop the instance, detach the root volume, attach it to a rescue instance, modify the authorized_keys file, and then reattach it. Alternatively, use AWS Systems Manager Session Manager if it was pre-configured.

Why does SSH work with password but not key?

This indicates that PasswordAuthentication is enabled but PubkeyAuthentication is either disabled or the key configuration is incorrect. Check your sshd_config to ensure both methods are allowed if you intend to use passwords, though key-based auth is recommended for security.

Can I use the same key for multiple EC2 instances?

Yes, you can use the same private key to connect to multiple instances provided the corresponding public key is added to the authorized_keys file of each instance. This simplifies management but reduces security isolation between servers.

How do I check SSH logs for errors?

On most Linux distributions, SSH logs are found in /var/log/secure or /var/log/auth.log. Run sudo tail -f /var/log/secure while attempting to connect to see real-time rejection reasons.

Does changing the instance IP affect SSH keys?

No, changing the Elastic IP or public DNS does not affect SSH key authentication. The keys are tied to the user account on the operating system, not the network address. However, ensure your local SSH config or hosts file is updated if you use aliases.