SSH permission denied (publickey), explained and fixed

This message means the SSH server was reached, the handshake completed, and authentication failed: none of the keys the client offered were accepted for that user on that server. The server is deliberately vague, so the debugging has to happen from the client side, where a verbose connection attempt shows exactly which keys were offered and which the server turned down. Five causes account for nearly every case, and they are all checkable in minutes.

Debug in the open first

  1. Run the connection verbosely: ssh -v user@host (one -v is enough; -vvv for detail). The output shows each identity file offered and the server's response. “Offering public key” lines never answered, answered with failure, or absent entirely each point at a different cause below.

The causes, most common first

  1. The public key is not in the server's authorized_keys for that user, or was pasted with line breaks or truncation; the file must contain the key as one single line per key.
  2. Wrong username. Cloud images use specific default users (ubuntu, ec2-user, debian, admin); authenticating as root or a personal name the server does not have fails identically.
  3. The right key is never offered: the private key is not in ~/.ssh with a standard name, not loaded in the agent (ssh-add -l lists what is loaded), and not specified; add it explicitly with ssh -i ~/.ssh/keyfile user@host to test.
  4. Permissions too open on the server side: sshd ignores credential files it considers unsafe: the home directory, ~/.ssh, and authorized_keys must not be writable by group or others (the standard is 755 or stricter for home, 700 for .ssh, 600 for authorized_keys), and owned by the user.
  5. Permissions too open on the client side: OpenSSH refuses to use a private key file that others can read; “bad permissions” warnings accompany this, and the fix is chmod 600 on the private key.
  6. The server has key authentication restricted or disabled for that user or entirely (PubkeyAuthentication, AuthenticationMethods, or an AllowUsers list), visible in the server's /var/log/auth.log or journal, which records the specific reason the client never sees.

The fixes, in order

  1. Test with the explicit key and user: ssh -i ~/.ssh/thekey -o IdentitiesOnly=yes user@host. This eliminates agent confusion and wrong-default-key problems in one shot; if it works, make it permanent in ~/.ssh/config with Host, User, and IdentityFile entries.
  2. Reinstall the public key correctly where console access exists: ssh-copy-id -i ~/.ssh/thekey.pub user@host (authenticating by whatever method still works), or paste it via the provider's console, verifying it lands as one unbroken line.
  3. Fix the permissions on both ends to the values listed above, including ownership; this is the fix most often missed because the verbose client log only hints at it while the server log states it plainly.

Common questions

Why does the server not say which part failed? Deliberate security design: detailed answers would let an attacker probe for valid usernames and key states. The server's own auth log has the detail; the network response never will.

It worked yesterday with the same key, what changed? Usually the server's authorized_keys or permissions (a home directory made group-writable by an unrelated change is a classic), the key was removed, or the client is now offering a different default key after an agent or config change. The -v output comparison settles it.

Can I just switch to password login? Only if the server allows it; many images disable password authentication entirely. And re-enabling it to dodge a key problem trades a small mystery for a weaker server; the key problem is one of the five causes above and is fixable.

Related errors

Host key verification failed · SSH: Connection refused · Permission denied (Linux)