Introduction

Permission denied (publickey) when connecting to an EC2 instance means the SSH server rejected your authentication attempt. The instance is usually reachable, but the username, key, or authorized public key does not match what the server expects.

Start With The Exact SSH Command

The most common mistake is connecting with the wrong username or wrong private key file.

ssh -i my-key.pem [email protected]

The correct username depends on the AMI:

• 'ec2-user for many Amazon Linux images'
• 'ubuntu for Ubuntu images'
• 'centos for CentOS images'
• 'admin for some appliance images'

If the key is correct but the username is wrong, SSH still fails with the same public-key error.

Check The Key Pair Association

When an EC2 instance launches, AWS injects the selected public key into the instance. If you try to use a different private key later, authentication fails even though the instance is healthy.

Make sure the .pem file you are using belongs to the same key pair selected at instance launch. If you lost that private key, AWS cannot recover it for you. At that point, recovery usually means using Systems Manager, attaching the volume elsewhere, or rebuilding access.

Fix Local File Permissions

OpenSSH refuses overly permissive private-key files.

chmod 400 my-key.pem
ssh -i my-key.pem [email protected]

If the permissions are too open, the client often warns about it before even attempting proper authentication.

Verify The Instance Is Actually Reachable

A security-group problem normally produces timeout or connection-refused behavior, not a public-key rejection. Still, it is worth confirming that inbound SSH is allowed from your current IP.

nc -vz 203.0.113.10 22

If port 22 is reachable and the error remains Permission denied (publickey), focus on authentication rather than networking.

Use Verbose SSH Output

The fastest way to see what is happening is to run SSH in verbose mode.

ssh -vvv -i my-key.pem [email protected]

The debug output shows which key files the client offered, which username it used, and whether the server rejected the offered public key. That is often enough to reveal a wrong key path, the wrong username, or an SSH agent offering unrelated keys first.

SSH Agent Can Interfere

If your SSH agent is loaded with many keys, the server may reject attempts before the correct key is used. Force a specific key identity when needed.

ssh -o IdentitiesOnly=yes -i my-key.pem [email protected]

That tells the client to use only the provided identity instead of cycling through agent-loaded keys.

If The Key On The Instance Is Wrong

Sometimes the instance's authorized_keys file has been modified or the home directory permissions are broken. If you still have another way into the machine, verify:

• the correct public key is in the user's ~/.ssh/authorized_keys
• the home directory and .ssh permissions are sane
• you are targeting the right login user for that home directory

If you do not have alternate access, Systems Manager Session Manager is often the cleanest recovery path when it is already enabled.

Common Recovery Paths

If you cannot authenticate and cannot use Session Manager, common recovery patterns are:

• stop the instance and attach its root volume to another instance for repair
• use EC2 Instance Connect if the AMI and setup support it
• rebuild the instance with the correct key pair if recovery time exceeds rebuild time

The right choice depends on how critical the instance state is and what AWS features were enabled beforehand.

Common Pitfalls

The most common mistake is using the wrong login user. Another is assuming the .pem filename on disk proves it matches the launched instance; it does not. Developers also often chase security groups when the error message already points to authentication. Finally, SSH agents with multiple identities can confuse diagnosis unless you force the intended key explicitly.

Summary

• 'Permission denied (publickey) means SSH authentication failed, not usually that networking failed.'
• Verify the login username, private key, and instance key-pair association first.
• Fix local key permissions with chmod 400.
• Use ssh -vvv and IdentitiesOnly=yes to diagnose what the client is offering.
• If the instance no longer trusts your key, recovery requires another access path such as Session Manager or volume repair.