← Common fixesTroubleshooting

SSH permission denied (publickey) after disabling passwords

Locking sshd down to key-only is the right move, but it's unforgiving: if your key isn't set up perfectly, you get 'permission denied (publickey)' and no fallback to a password. The message means the server tried every key you offered and accepted none. Confirm a working key before you remove password auth, and use `ssh -v` to see exactly which keys are being tried.

What it means

With `PasswordAuthentication no`, the only way in is a public key whose private half you hold and whose public half is in the target user's `authorized_keys`. The server also enforces strict permissions on `~/.ssh` and honors `AllowUsers`/`AllowGroups`/`PubkeyAuthentication`. Any of those failing means no method succeeds, and sshd reports publickey denial.

Most common causes

  • Key not in authorized_keys. The public key isn't in the target user's `~/.ssh/authorized_keys` (or you're connecting as the wrong user). Add the exact public key for the account you log in as.
  • Wrong permissions on ~/.ssh. sshd refuses keys if `~/.ssh` isn't 700 or `authorized_keys` isn't 600, or the home directory is group-writable. Tighten them.
  • AllowUsers / AllowGroups excludes you. A hardening rule that whitelists accounts will deny everyone else by publickey. Make sure your user is in the allowed set.
  • Pubkey auth disabled or wrong key offered. `PubkeyAuthentication no`, or your client offering a different key than expected. Check with `ssh -v` to see which keys are tried and add `-i` to force the right one.

How to fix it

  1. Run `ssh -v` (or -vvv) and watch which keys are offered and how the server responds.
  2. Confirm the public key is in the right user's `authorized_keys` on the server.
  3. Fix permissions: `~/.ssh` 700, `authorized_keys` 600, home not group-writable.
  4. Check `sshd_config` for `PubkeyAuthentication yes` and any `AllowUsers`/`AllowGroups` that excludes you, and verify a key works *before* disabling passwords.