Fixing the SSH "Permission denied (publickey)" Error: A Step‑by‑Step Diagnostic Guide

Why This Guide Matters

When a Linux system refuses a connection with Permission denied (publickey), the culprit is almost always a mis‑configured key or permission issue. The error is terse but can hide several independent problems: the client may not be sending the right key, the server may be rejecting it, or the file permissions might be too lax. This guide walks you through a systematic diagnostic process that isolates the root cause, applies the correct fix, and tells you when to involve a higher‑level administrator.

Cause / Diagnostic Table

#	Possible Cause	Diagnostic Indicator
1	Client key not found or not loaded	Debug output shows Offering public key but no Authenticated line.
2	Server denies key due to sshd_config settings	Server logs contain Authentication refused: bad ownership or modes or no matching key.
3	Key file permissions too open	OpenSSH logs Authentication refused: bad ownership or modes even if the key is correct.
4	User mismatch or wrong authorized_keys entry	Logs show Authentication refused: bad ownership or modes or no matching key for the requested username.

Ordered Diagnostic Checks

1. Capture Verbose Debug Output

Run the following on the client (replace user@host with your target):

ssh -vvv user@host

Run with sudo if you suspect root‑initiated sessions. Look for the line Offering public key and the subsequent response. If you see Authentication refused: bad ownership or modes, you’re likely dealing with permission problems on the server side.

2. Verify Local Key Presence and Agent Loading

Check that your private key exists in ~/.ssh and is either loaded into ssh-agent or specified explicitly:

# List keys known to ssh-agent
ssh-add -l

# If no keys appear, load the desired key
ssh-add ~/.ssh/id_rsa

# Or bypass the agent entirely
ssh -i ~/.ssh/id_rsa user@host

If ssh-add -l shows no keys, the client will not offer any public key, causing the failure.

3. Inspect Server Authentication Configuration

On the server, confirm that PubkeyAuthentication is enabled and that AuthorizedKeysFile points to the correct location. Typical defaults are:

# /etc/ssh/sshd_config
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

After any change, reload the daemon:

sudo systemctl reload sshd

Do not restart the service while you have active sessions; a reload preserves them.

4. Verify File and Directory Permissions

OpenSSH is strict: the .ssh directory must be 700 and authorized_keys 600. World‑readable permissions trigger a refusal.

# On the client
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

# On the server (as the target user)
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Correct any deviations:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Targeted Fixes

• Missing or unloaded key: Add the key to ssh-agent or specify it with -i. Verify with ssh-add -l that the key is listed.
• Server denies key due to config: Ensure PubkeyAuthentication yes and that AuthorizedKeysFile is correct. Reload sshd after edits.
• Permission issues: Set 700 on ~/.ssh and 600 on authorized_keys on both client and server.
• User mismatch: Confirm the username in your connection string matches the user whose authorized_keys contains the key. If you’re using a non‑default user, prepend the username to the key entry.

Verification Steps

1. Run ssh -vvv user@host again. A successful authentication will display Authenticated and the session will start.
2. On the server, check the authentication log:

   sudo journalctl -u sshd | tail -n 20
   # or
   sudo tail -n 20 /var/log/auth.log
   

   Look for Accepted publickey for user.
3. Re‑run the permission checks to ensure 700 and 600 remain intact.

Escalation Criteria

• Persistent failures after applying all fixes and debug shows bad ownership or modes: Involve the system or hosting provider; there may be deeper filesystem ACLs or SELinux/AppArmor restrictions.
• No debug output after key addition: Suspect network or firewall blocking the SSH port (22) or interfering with the key exchange. Verify connectivity with telnet host 22 or nc -vz host 22.
• Server logs show repeated authentication failures for the same key: Coordinate with the security team to check for account lockouts or intrusion detection alerts.

Practical Example

Suppose you connect as alice to 10.0.0.5 and receive the error. You discover that ~/.ssh/id_rsa exists but ssh-add -l returns No identities added.. You add the key:

ssh-add ~/.ssh/id_rsa
ssh -vvv alice@10.0.0.5

The debug output now shows Offering public key and Authentication succeeded (publickey).. On the server, you confirm the key is present in /home/alice/.ssh/authorized_keys and that the directory is 700 and the file 600. The connection succeeds.

Limitations & Caveats

• These steps assume OpenSSH 8.x or later on both client and server. Older versions may have slightly different log messages.
• When using SELinux, additional context checks may be required; the bad ownership or modes message can also stem from SELinux denials.
• Reloading sshd via systemctl reload sshd is safe for active sessions, but a full restart (systemctl restart sshd) will drop them.
• Never set key files to 644 or higher; OpenSSH will reject them outright.

Conclusion

By following the ordered checks, applying the targeted fixes, and verifying through both client debug output and server logs, you can reliably resolve most instances of Permission denied (publickey). When the issue persists beyond these steps, the escalation criteria point you to the next level of support.