Permission denied (publickey): SSH diagnostic guide for key rejection

The recognizable failure

You run ssh user@hostname and the connection ends with Permission denied (publickey). No password prompt appears. The useful takeaway is that the server received an authentication attempt, evaluated one or more public keys, and rejected all of them before falling back to other methods.

Publickey authentication requires a matching pair: a private key on the client and the corresponding public key in the server's ~/.ssh/authorized_keys for the target user. The SSH daemon, sshd, will silently refuse a key if the file layout is insecure, the key is not offered, or the key type is not allowed.

Cause to symptom table

Ordered checks

1. Confirm what the client actually offers

Run on the client machine as the user who should connect. No special permissions required.

ssh -vvv user@hostname

Look for which identity files are tried and whether an agent is used. If you rely on ssh-agent, verify it holds the key:

ssh-add -l

An empty list means the agent is running with no keys loaded. Load a specific key with ssh-add /path/to/private/key. Risk: the private key is loaded in memory for the session.

2. Verify server-side file layout

Run these commands on the server as the target user, or as root with caution. The home directory and .ssh must be owned by the user, not root or another user.

ls -ld ~

ls -ld ~/.ssh

ls -l ~/.ssh/authorized_keys

Expected values for OpenSSH are ~/.ssh mode 700 and authorized_keys mode 600. sshd will ignore keys if permissions are too open. Setting 777 on .ssh causes the daemon to reject the key entirely.

Correct ownership if needed:

chown user:user ~

chown user:user ~/.ssh ~/.ssh/authorized_keys

Correct permissions if needed:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

Rollback: note original modes before changing, or restore from backup.

3. Confirm the public key matches

On the server, ensure the public key string in ~/.ssh/authorized_keys matches the client's private key. The file should contain one key per line, with no leading spaces or line breaks. Check the file is readable by the user only.

On the client, the public key is typically ~/.ssh/id_ed25519.pub or similar. Compare the key comment and fingerprint, not the whole file.

4. Check sshd configuration constraints

Run on the server as root or with sudo.

grep -E '^PubkeyAuthentication|^AuthorizedKeysFile|^PubkeyAcceptedKeyTypes' /etc/ssh/sshd_config

Common blockers: PubkeyAuthentication no, a custom AuthorizedKeysFile path that does not exist for the user, or a PubkeyAcceptedKeyTypes list that excludes the key type you are using, e.g., RSA keys on a server that only allows Ed25519.

After editing sshd_config, reload sshd. Risk of locking out access if misconfigured.

5. Read server authentication logs

Run on the server as root or with sudo.

tail -n 50 /var/log/auth.log

On Red Hat-based systems the path is often /var/log/secure. Look for messages from sshd for the target user and timestamp of the attempt. Log entries commonly indicate bad ownership or modes, or that a key was rejected.

Fixes tied to findings

• No key offered. Start ssh-agent in the session, or specify the key explicitly: ssh -i /path/to/private/key user@hostname. Verify with ssh-add -l.
• Permissions too open. Tighten to 700/600 as above. Do not use 777.
• Wrong ownership. Change ownership of home, .ssh, and authorized_keys to the target user.
• Key type rejected. Either generate a key type accepted by the server or adjust PubkeyAcceptedKeyTypes in sshd_config and reload.
• Key missing or malformed. Append the correct public key to ~/.ssh/authorized_keys with one line, no extra whitespace.

Escalation criteria

Escalate when permissions, ownership, key presence, and sshd settings are correct and logs show no ownership or mode errors, yet authentication still fails. Possible next areas are SELinux or AppArmor denials, filesystem ACLs, or a mismatch between the client's ~/.ssh/config Host entry and the actual hostname, causing a different key to be used.

Limitations: this guide covers standard OpenSSH publickey rejection. It does not cover network-level blocking, man-in-the-middle host key verification failures, or non-standard authentication backends. Verify the result by retrying with ssh -o PreferredAuthentications=publickey user@hostname and confirming a successful login without a password prompt.