SSH's "Permission denied (publickey)" and how to read it with ssh -v

What it is

The OpenSSH client prints user@host: Permission denied (publickey). once every authentication method the server was willing to try has ended in rejection. The method names in parentheses are simply what the server offered to attempt, not what actually failed for a specific reason; the message itself carries no detail about which key was tried or why it did not work.

Why it matters

Because the message is deliberately generic (revealing more would help an attacker enumerate valid usernames or keys), fixing it by guessing wastes time; the actual cause is one of a small set of things, and ssh -v names it directly instead of leaving it to trial and error.

How to apply

• Diagnose with verbosity first: ssh -v (or -vvv for more detail) shows exactly which keys the client offered, in what order, and how the server responded to each ("Offering public key", "Server accepts key", "Authentications that can continue"). Read this transcript before changing any configuration.
• Common causes, least to most invasive fix:
  1. Wrong remote username - connecting as your local account name when the server expects a different one (e.g. ec2-user, git). Pass -l user or fix the User entry in the relevant Host block.
  2. The right key exists on disk but was not among those offered. By default ssh tries keys from an agent and default filenames; point it explicitly at the right one with -i path/to/key together with IdentitiesOnly yes (documented in ssh_config(5)), so ssh does not also throw unrelated keys at the server and risk the server's own attempt limit before reaching the right one.
  3. Server-side permissions: sshd_config(5) documents StrictModes, which makes sshd reject authentication if the home directory, ~/.ssh or authorized_keys are writable by anyone other than their owner. Check and correct ownership and modes (typically 700 for ~/.ssh, 600 for authorized_keys) from the server side, using its own auth log to confirm this is the cause.
  4. Since OpenSSH 8.8, client and server no longer use RSA signatures with SHA-1 (the ssh-rsa algorithm) by default, per the OpenSSH 8.8 release notes. RSA keys themselves keep working through rsa-sha2-256/512, supported since OpenSSH 7.2; failures appear when one end is 8.8+ and the other only speaks ssh-rsa (very old servers, appliances, old SSH libraries). Prefer upgrading that end or switching to an ed25519 key; only as a temporary, weakening stopgap re-enable it for that one host with PubkeyAcceptedAlgorithms +ssh-rsa (OpenSSH 8.5+ name) in a Host block, not globally.
• Not a fix: retrying repeatedly, or copying a private key insecurely between machines instead of provisioning a proper key or using agent forwarding.

Pitfalls

• Chasing a client-side fix when the actual cause is server-side authorized_keys permissions, which only the server's own logs reveal.
• Assuming a key "still works" because it worked yesterday, when an OpenSSH upgrade on either end changed accepted algorithms overnight.