GrepBoard/Manuals
51 manuals ·

Find why SSH says Permission denied (publickey)

·Ubuntu 24.04 · OpenSSH 9.6p1 (reproduced with a separate sshd)·6 steps

Read ssh -v to see which key was offered, then use the sshd log lines (Authentication refused, Failed publickey) to find permission, user or key-line problems.

output
alice@server1: Permission denied (publickey).

That one line is all the client prints, so the cause is in the server log. The server output below comes from a separate sshd started with -e; only the user and paths were changed to alice and /home/alice/.ssh.

[1] Connect with -v on the client and see which key was offered. Offering public key is the key sent; if the server takes it, Server accepts key follows. No such line means the server rejected that key.

console
$ ssh -v alice@server1debug1: Will attempt key: /home/bob/.ssh/id_ed25519 ED25519 SHA256:tlR0lx+Gl7RrUcp9VHU+p+/qMk325ndyJO7Diu4hVi0 explicitdebug1: Offering public key: /home/bob/.ssh/id_ed25519 ED25519 SHA256:tlR0lx+Gl7RrUcp9VHU+p+/qMk325ndyJO7Diu4hVi0 explicitalice@server1: Permission denied (publickey).

[2] Read the sshd log on the server. On Ubuntu 24.04 the unit is named ssh.

console
# journalctl -u ssh -e --no-pager

[3] If the log has Authentication refused: bad ownership or modes, it is a permission problem. StrictModes (default yes) checks the home directory, ~/.ssh and authorized_keys, and refuses to use the file if other users can write to it (man sshd). directory or file at the end of the message says what to fix, and the path is the culprit.

output
Authentication refused: bad ownership or modes for directory /home/alice/.sshAuthentication refused: bad ownership or modes for file /home/alice/.ssh/authorized_keysAuthentication refused: bad ownership or modes for directory /home/alice

These came from ~/.ssh at 777, authorized_keys at 666, and the home directory at 777, in that order. Changing the file's owner to another account also produced for file. namei -l shows owners and modes at a glance.

console
$ cd ~ && namei -l .ssh/authorized_keysf: .ssh/authorized_keysdrwxrwxrwx alice alice .ssh-rw------- alice alice authorized_keys

[4] Fix the permissions. The home directory only needs no write bit for group and others, ~/.ssh should be 700, and the file 600. If the owner is wrong, set it with chown.

console
$ chmod go-w ~$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys

Connect again. The client prints Server accepts key and Authenticated, and the server logs Accepted publickey.

output
Authenticated to server1 ([203.0.113.5]:22) using "publickey".Accepted publickey for alice from 203.0.113.5 port 35016 ssh2: ED25519 SHA256:tlR0lx+Gl7RrUcp9VHU+p+/qMk325ndyJO7Diu4hVi0

[5] If there is no Authentication refused but the login is still denied, raise LogLevel to VERBOSE and read the fingerprint on the Failed publickey line. Compare it with the keys in the server file using ssh-keygen -lf.

console
$ ssh-keygen -lf ~/.ssh/authorized_keys256 SHA256:tlR0lx+Gl7RrUcp9VHU+p+/qMk325ndyJO7Diu4hVi0 alice@laptop (ED25519)
output
Failed publickey for alice from 203.0.113.5 port 33644 ssh2: ED25519 SHA256:qQpllHwKs2mollfgNesirV7N0A1zzwYbngi4lpa+Qms

A different fingerprint means the client offered the wrong key. Pin it with ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes and check that the .pub line of that key is in the server file. If the fingerprint matches and the login still fails, go to the table.

[6] Other causes:

SymptomWhat the server showsCheck / fix
Wrong user nameInvalid user alice from … (INFO)Check the account name you connect as
Key line broken into two linesOnly Failed publickey (no matching key found even at DEBUG1)Paste the whole .pub line again. One key per line
authorized_keys missingCould not open user 'alice' authorized keys '…': No such file or directory (DEBUG1)Check path and file name
AuthorizedKeysFile points elsewhereSame as aboveCheck authorizedkeysfile in sshd -T

The path the server really uses:

console
# sshd -T | grep -i authorizedkeysfileauthorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

authorized_keys holds one key per line; empty lines and lines starting with # are comments (man sshd).

Analyze your auth.log (SSH) log in the browser ↗ — nothing is uploaded.

#ssh#sshd#publickey