SSH Permission Denied (publickey) — How to Fix It

What you're seeing

$ ssh [email protected]
[email protected]: Permission denied (publickey).

You may also see variants like Permission denied (publickey,password) (server allows password fallback but rejected your key) or Permission denied (publickey,gssapi-keyex,gssapi-with-mic) (enterprise SSO environment).

What's causing this error

The server is saying "I got your connection, but none of the authentication methods you offered match what I'm willing to accept for this user." The five real causes, in rough order of frequency:

1. Wrong key being offered. Your ssh-agent is loaded with key A, but the server expects key B. Or ~/.ssh/config is silently pointing at the wrong identity file.
2. Permissions on the local key are too loose. OpenSSH refuses to use a private key that's group- or world-readable. Anything more permissive than 600 is rejected silently.
3. Public key isn't in ~/.ssh/authorized_keys on the server, or is there but the file/directory permissions are wrong.
4. PasswordAuthentication no in sshd_config combined with no matching key — the server literally has no auth path it will accept.
5. Connecting as the wrong user. ssh server.com defaults to your local username; if the remote account is root or ubuntu you'll be rejected even with a correct key.

How to fix it

Step 1: Run ssh in verbose mode

This is the single highest-signal diagnostic. It tells you which keys your client offered, which the server rejected, and which auth methods the server accepts.

ssh -v [email protected]

Look for these lines in the output:

• Offering public key: /Users/you/.ssh/id_ed25519 — your client is presenting this key
• Authentications that can continue: publickey — server's list of accepted methods
• No more authentication methods to try — you ran out

If the key you expect to be offered isn't listed in the output, the problem is on your side (step 2). If it is offered but rejected, the problem is on the server (step 3).

Step 2: Fix client-side issues

Confirm the right key is loaded:

$ ssh-add -l
# If "The agent has no identities":
$ ssh-add ~/.ssh/id_ed25519
# Or explicitly tell ssh which key to use:
$ ssh -i ~/.ssh/id_ed25519 [email protected]

Fix local key file permissions. OpenSSH refuses to use overly-permissive private keys:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ed25519
$ chmod 644 ~/.ssh/id_ed25519.pub

Check your ~/.ssh/config. If you have a config file, an outdated IdentityFile entry can silently override the key you think you're using:

cat ~/.ssh/config

Look for a Host block matching your target and confirm IdentityFile points to the right key.

Step 3: Fix server-side issues

You need shell access to the server to fix these. If you're locked out entirely, use your hosting provider's web console (DigitalOcean, AWS EC2 Serial Console, Hetzner Rescue, etc.).

Confirm the public key is in authorized_keys:

cat ~/.ssh/authorized_keys

The contents of your local ~/.ssh/id_ed25519.pub should be on a single line in that file. If it's not there, add it:

# On the server:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... your-comment" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The permissions are not optional — sshd will silently refuse to read authorized_keys if any of them are wrong.

Verify sshd_config allows key auth:

sudo grep -E "^(PubkeyAuthentication|PasswordAuthentication|AuthorizedKeysFile)" /etc/ssh/sshd_config

You want:

• PubkeyAuthentication yes (or absent — yes is the default)
• AuthorizedKeysFile .ssh/authorized_keys (or absent — this is the default)

If you change sshd_config, restart sshd:

sudo systemctl restart ssh    # Debian/Ubuntu
sudo systemctl restart sshd   # RHEL/CentOS/Fedora

Check SELinux file contexts (RHEL/Fedora/CentOS). If the server uses SELinux and you created ~/.ssh manually, the file contexts may be wrong:

sudo restorecon -R -v ~/.ssh

Common edge cases