SSH Permission denied (publickey): the Server Is Not Refusing Your Key, It Never Saw One

Permission denied (publickey).

The word publickey sends everyone to the same place: generate a new key, copy it again, try again. It almost never helps, because the message is not saying your key was rejected. It is saying that no acceptable method succeeded, and the only method the server was willing to accept is public key.

Those are different statements, and the difference is where the answer lives.

One command settles it

ssh -vvv user@host 2>&1 | grep -iE "offering|authentications that can continue|no such|bad permissions"

Three lines matter in that output.

Authentications that can continue: publickey tells you what the server allows. If password is absent from that list, no amount of typing a password will work: the server has PasswordAuthentication no.

Offering public key: /home/you/.ssh/id_ed25519 tells you what your client actually tried. If no Offering line appears at all, your client never sent a key, and the whole problem is on your side.

Load key ... bad permissions or Permissions 0644 for '...' are too open is the single most common cause on a fresh setup.

Cause 1: permissions, and they are strict for a reason

OpenSSH refuses to use a private key that other users could read. It also refuses to trust an authorized_keys file that others could write.

On the client:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

On the server:

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

The home directory itself matters too. If /home/user is group writable, sshd refuses the whole thing, and the log on the server says Authentication refused: bad ownership or modes. That message never reaches the client, which is why this cause is so often missed: the client is told nothing useful, the server knows exactly what happened.

Cause 2: the client offered a different key

With several keys in ~/.ssh, the client tries them in its own order and stops after a few attempts. Your key may never be offered at all.

Force it:

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

IdentitiesOnly=yes is the part people omit. Without it, -i adds a key to the list rather than restricting the list to that key, and an agent holding a dozen identities can still exhaust the server’s attempt limit before reaching yours.

Once it works, make it permanent in ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Cause 3: the username, not the key

ssh root@host fails with Permission denied (publickey) when the key is installed for ubuntu, and the message says nothing about the user. Cloud images each have their own default account, and PermitRootLogin is commonly disabled.

Before touching keys, confirm which user is supposed to hold that key.

Cause 4: the server does not want that key

Read /var/log/auth.log or journalctl -u ssh on the server while you attempt the connection. This is the step that ends the guessing, because the server states its reason plainly, and the client never receives it.

Two entries are worth recognising: Authentication refused: bad ownership or modes for directory is cause 1, and error: key_read: uudecode failed means authorized_keys is corrupt, usually a public key pasted across several lines. A key in authorized_keys must be exactly one line.

Cause 5: the key type is too old

Recent OpenSSH releases disable ssh-rsa with SHA-1 signatures by default. A key that worked on an older server can fail on a new one with the same unhelpful message.

You can confirm quickly by allowing it for one connection:

ssh -o PubkeyAcceptedKeyTypes=+ssh-rsa user@host

If that works, do not keep it as your fix. Generate a modern key instead:

ssh-keygen -t ed25519 -C "you@example.com"

The order that finds it fastest

1. ssh -vvv and read the Offering lines. No offer means the problem is entirely local.
2. Check permissions on both sides, home directory included.
3. Confirm the username.
4. Read the server log while attempting. It says the real reason.
5. Only then consider the key type or a new key.

Locking down SSH properly once the connection works is a separate matter, and one worth doing: our Linux hardening guide covers the settings, and fail2ban does not secure SSH explains why the popular answer is not the protective one people assume.