Permission denied (publickey).

Prefixed with `user@host:`. The parenthesised list shows the methods the server still allows, e.g. `(publickey,password)` or `(publickey,gssapi-keyex,gssapi-with-mic)`.

What it means

The SSH connection and host verification succeeded, but the server accepted none of the public keys the client offered, and public-key authentication is the only method it allows (the list in parentheses). The client never learns why a key was refused — that reason is only in the server's log. On GitHub, GitLab and Bitbucket the same message means none of your keys is registered on the account (or deploy key) for that repository.

Why it happens

• The right key is not offered

  common

  The key is not in the agent, not at a default path (`~/.ssh/id_ed25519`, `id_ecdsa`, `id_rsa`), and not named with `-i` or `IdentityFile`. With many keys in the agent, the server may disconnect (MaxAuthTries) before the right one is tried.

• The key is not in authorized_keys of that user

  common

  Installed for another user or host, removed during a reinstall, or (for Git hosting) added to a different account than the one owning the repository access.

• sshd ignores authorized_keys because of permissions

  occasional

  With `StrictModes yes` (the default), a group- or world-writable home directory, `~/.ssh` or `authorized_keys` makes sshd refuse the file. The server log says "Authentication refused: bad ownership or modes".

• The key's signature algorithm is not accepted

  occasional

  RSA keys used with the SHA-1 `ssh-rsa` algorithm by old clients and libraries are rejected by OpenSSH 8.8+ servers; DSA keys are gone entirely in OpenSSH 10. The server logs "not in PubkeyAcceptedAlgorithms".

• Wrong remote user name

  occasional

  `ssh server` logs in with your local user name. Cloud images expect `ubuntu`, `ec2-user`, `admin`; Git hosting always expects `git@`.

How to fix it

1. 1.

   See which keys are offered

   `ssh -v` lists every key the client offers and whether the server accepted it; `ssh -G` shows the effective user and identity files after all config is applied.

   ssh -v deploy@server.example.com 2>&1 | grep -E "Offering|Server accepts|Authentications that can continue|send_pubkey_test"
   ssh-add -l                                  # keys the agent offers
   ssh -G deploy@server.example.com | grep -E "^(user|identityfile|identitiesonly) "

2. 2.

   Pin the identity per host

   `IdentityFile` plus `IdentitiesOnly yes` offers exactly one key and avoids "Too many authentication failures" with large agents.

   # ~/.ssh/config
   Host server.example.com
     User deploy
     IdentityFile ~/.ssh/deploy_ed25519
     IdentitiesOnly yes

3. 3.

   Fix the server side and read its log

   Install the public key for the right user with strict modes and check sshd's log for the specific refusal reason.

   # On the server: install the key and fix modes (sshd ignores keys in group/world-writable paths)
   install -d -m 700 ~/.ssh && cat deploy_ed25519.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
   sudo journalctl -u ssh --since "10 min ago" | grep -E "Authentication refused|not in PubkeyAccepted|Failed publickey"

← Browse the full signature error database