Fix SSH "Permission denied (publickey)"

Permission denied (publickey) means the server offered only key authentication and rejected every key you presented. It is almost never a mystery once you read it that way: either you did not send a key the server trusts, or the server cannot use the key you sent. Work the list in order.

First, see what SSH is actually doing

ssh -v user@server

The verbose log shows which keys are offered (Offering public key:) and how the server responds. If you see your key offered and then Authentications that can continue: publickey again, the server does not have your public key. If your key is never offered, the problem is local.

The checklist

1. Is the public key on the server? The server only trusts keys listed in ~/.ssh/authorized_keys for that user. Install it with ssh-copy-id or by hand. This is the single most common cause.

2. Are you offering the right key? If you have several keys, SSH may try the wrong ones and give up. Point at the exact key:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@server

If that works, set IdentityFile and IdentitiesOnly yes in ~/.ssh/config so you do not type it every time.

3. Is the key loaded in the agent? If the key has a passphrase and is not in the agent, some setups will not offer it:

ssh-add -l            # list loaded keys
ssh-add ~/.ssh/id_ed25519

4. Server-side permissions. sshd silently refuses ~/.ssh or authorized_keys if they are too permissive. On the server: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, and make sure the home directory is not group-writable. This is the permissions-too-open failure on the server side, and it produces this exact error.

5. Right user. ssh ubuntu@host and ssh root@host look at different authorized_keys files. The key has to be in the file for the user you are logging in as. Cloud images each have their own default user (see SSH into EC2).

6. Server config forbids it. As a last resort, the server may set PubkeyAuthentication no or restrict users via AllowUsers/AllowGroups in sshd_config. You need existing access to inspect or change that.

The fast path

90% of the time the fix is one of: install the public key on the server (step 1), or tighten the server-side permissions (step 4). Run ssh -v, find which side is failing, and you will know which.

FAQ

See also

• Add an SSH key to a server: get the public key into authorized_keys (step 1 of the checklist).
• Fix SSH "permissions are too open": the permission rules behind step 4.
• Use multiple SSH keys with ~/.ssh/config: pin the right key per host.
• Fix "Host Key Verification Failed": the other SSH wall, on the server-identity side.
• SSH Cheat Sheet: verbose flags and config directives.