SSH Permission denied (publickey): 5-Minute Cause-and-Fix Diagnosis (EC2)

SSH "Permission denied (publickey)" 5-Minute Diagnosis Guide (Including EC2)

Same Error, Ten Different Causes

If Permission denied (publickey) shows up in your terminal and work stops, the first thing you need to know is this: it does not mean "wrong password." The server is refusing you because it only accepts public-key authentication, and the key you presented failed to prove who you are.

The problem is that the cause of that "proof failure" is not a single place. You might not have offered a key at all (client-side), or the key might be correct but sshd silently ignored it because authorized_keys permissions were outside 700/600 (server-side). Recreating keys or changing permissions at random can actually break a working setup.

The diagnostic sequence in this post is one line: classify by error message → split client vs. server with ssh -vvv → pinpoint the cause with commands on that side. Let's start.

30-Second Triage: Cause Table by Error Message

Match the message on your screen against the table below, then jump straight to the section in the "Where to check" column.

Most cases land on Permission denied (publickey), so start by splitting client vs. server with ssh -vvv.

Client-Side Diagnosis: Keys, ssh-agent, and Username

Finding the Split Point with ssh -vvv

Turn on debug logs first.

ssh -vvv -i ~/.ssh/id_ed25519 ubuntu@<서버IP>

Look for these lines in the output.

debug1: Offering public key: ~/.ssh/id_ed25519 ED25519 SHA256:abc...
   ↑ offered the key to the server → if you got this far, the client key is fine; suspect the server

debug1: Authentications that can continue: publickey
   ↑ the server is allowing publickey only

debug1: Trying private key: ~/.ssh/id_rsa
debug1: No more authentication methods to try.
   ↑ no more keys to offer → key not specified / pair mismatch (client-side)

The decision rule is clear. If Offering public key appears even once, the client offered a key correctly; if it was still rejected, go to the server side (next section). Conversely, if Offering never appears and you go straight to No more authentication methods, it is a client-side problem.

Four Common Client-Side Causes

1. No key specified — You omitted -i, or there is no IdentityFile in ~/.ssh/config.

# Pin it per host in ~/.ssh/config so you don't need -i every time
Host myserver
    HostName 13.x.x.x
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

2. Key not loaded in ssh-agent — Especially if you see Too many authentication failures, the agent is offering a pile of the wrong keys.

ssh-add -l                       # list loaded keys
ssh-add ~/.ssh/id_ed25519        # add the key
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 ubuntu@<IP>  # ignore the agent; use only this key

3. Mismatched key pair — The public key registered on the server does not match the local private key. Check the local public-key fingerprint and compare it with the server's authorized_keys.

ssh-keygen -lf ~/.ssh/id_ed25519.pub

4. Wrong default cloud username — Surprisingly the most common. ssh root@... is rejected even when the key is correct, because the default account differs by AMI.

Switching from ssh root@13.x.x.x to ssh ubuntu@13.x.x.x is often all it takes.

If you still get rejected even though Offering public key appears → go to the next section (server side).

Server-Side Diagnosis: Permissions, sshd_config, and SELinux

If you have another way in (console, EC2 Instance Connect, SSM Session Manager), use it and check the following.

1) Check and Fix Permissions (copy-paste)

If ~/.ssh or authorized_keys permissions are too loose, sshd silently ignores the key for security reasons.

ls -la ~/.ssh
stat -c '%a %U %n' ~ ~/.ssh ~/.ssh/authorized_keys

# Correct to the standard permissions in one shot
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

One trap: if the home directory itself is group- or other-writable, you still get rejected even with 700/600. Home must be 755 or stricter.

chmod 755 ~      # or 750. The group write (20) bit must not be set

2) Check sshd_config

sudo grep -Ei 'PubkeyAuthentication|AuthorizedKeysFile|PermitRootLogin|PasswordAuthentication' /etc/ssh/sshd_config
sudo sshd -t        # syntax check (no output if OK)
sudo systemctl restart sshd

Confirm PubkeyAuthentication yes and that AuthorizedKeysFile is the default (.ssh/authorized_keys). As of 2026, OpenSSH 9.x disables ssh-rsa (RSA+SHA-1) by default, so an old RSA key produces server refused our key. Rather than a temporary workaround, reissue an ed25519 key.

ssh-keygen -t ed25519 -C "you@company"

3) Find the Decisive Log Line

The server log is what tells you the cause in one shot.

# Debian/Ubuntu
sudo tail -f /var/log/auth.log
# RHEL/Amazon Linux
sudo journalctl -u sshd -f

If you see the line below, it is a permissions problem.

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

4) SELinux Context (RHEL-family trap)

If permissions look correct but you are still refused, suspect the SELinux context. Copying authorized_keys by hand often breaks the context.

getenforce                    # if Enforcing, it can affect you
restorecon -Rv ~/.ssh         # restore the correct context

A Practical Note

In production, the most common cases are #1 wrong username (root vs ubuntu) and #2 ownership: creating authorized_keys with sudo so it is owned by root. Checking first whether a key is actually offered with ssh -vvv almost eliminates time wasted on the client/server split.

Post-Recovery Checklist to Prevent Recurrence

Diagnostic order on one page:

1. First-pass classification by error message (table above)
2. ssh -vvv → server if Offering public key appears, client if it does not
3. Client: -i/config, ssh-add -l, username
4. Server: permissions (700/600/home 755), sshd -t, auth.log, SELinux

Follow only this on new server setup and you will almost never see the same error.

• Standardize on ed25519 keys; retire RSA
• ~/.ssh 700, authorized_keys 600, remove group write on the home directory
• Template ~/.ssh/config with per-Host IdentityFile + IdentitiesOnly yes
• Keep an emergency access path — enable EC2 Instance Connect and SSM Session Manager so a key problem cannot lock you out completely

References: Official Docs

The primary source for the behavior, settings, and errors in this post is the following official documentation. Check version-specific options and exact behavior there.

• OpenSSH sshd_config manual (man7.org)

FAQ

Q. Does Permission denied (publickey) mean I typed the wrong password? A. No. It means the server only allows public-key authentication and the presented key failed. Password authentication itself may never have been attempted.

Q. The key is correct and permissions are 700/600, but I am still refused. A. Group write is likely still set on the home directory (chmod 755 ~), or it is an SELinux context issue on RHEL-family systems. Check for a bad ownership or modes line with sudo tail -f /var/log/auth.log and run restorecon -Rv ~/.ssh.

Q. I keep getting blocked on EC2. What is the most common cause? A. Wrong username. Connect with the AMI default account (ec2-user on Amazon Linux, ubuntu on Ubuntu) instead of root. If that still fails, get in with EC2 Instance Connect and inspect authorized_keys directly.