Fix SSH Permission Denied with Public Key Authentication on Linux

Symptoms

When attempting to connect to a remote Linux or Unix server via SSH using public key authentication, you receive the error: Permission denied (publickey). The SSH client may prompt for a password (if password authentication is enabled) or simply disconnect. This occurs despite having the correct public key in the remote user's ~/.ssh/authorized_keys file.

Root Causes

The most common causes are:

• Incorrect file permissions on the .ssh directory or authorized_keys file. SSH is very strict about permissions to prevent unauthorized access.
• Wrong ownership of the .ssh directory or files. They must belong to the user logging in.
• Improper key format or extra whitespace in the authorized_keys file.
• SELinux or AppArmor security policies blocking SSH key authentication.
• sshd_config settings that disable public key authentication or restrict key types.
• Wrong key file location or the public key not matching the private key.

Step-by-Step Fix

1. Verify SSH Server Configuration

On the remote server, check /etc/ssh/sshd_config for these lines:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no (optional but recommended for security)

If PubkeyAuthentication is set to no, change it to yes. Then restart SSH: sudo systemctl restart sshd or sudo service ssh restart.

2. Correct File Permissions

Log in as the user (or use sudo -u user). Run:

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

Ensure the home directory is not writable by group or others: chmod go-w ~.

3. Fix Ownership

Set correct ownership:

chown -R user:user ~/.ssh

Replace user with the actual username.

4. Validate Key File Content

Open ~/.ssh/authorized_keys and ensure it contains the public key in one line, starting with ssh-rsa, ssh-ed25519, etc. No extra spaces or line breaks. If you added the key manually, verify it matches the private key on the client.

5. Check SELinux/AppArmor

If SELinux is enforcing, restore default contexts:

restorecon -Rv ~/.ssh

For AppArmor, check logs (dmesg or journalctl) and adjust profiles if needed.

6. Test with Verbose Mode

On the client, connect with ssh -vvv user@host to see detailed debug output. Look for lines like:

debug1: Authentication refused: bad permissions
debug1: Offering public key: /path/to/key
debug1: Server accepts key

This pinpoints the exact rejection reason.

Alternative Fixes

• Use a different key type: Generate an Ed25519 key (ssh-keygen -t ed25519) if RSA is restricted.
• Disable SELinux temporarily: sudo setenforce 0 to test, then re-enable with proper contexts.
• Check sshd logs: sudo tail -f /var/log/auth.log or /var/log/secure for specific errors.
• Re-add the public key: Use ssh-copy-id user@host to automate correct placement and permissions.

Prevention

• Always use ssh-copy-id to add keys; it sets correct permissions automatically.
• Regularly audit .ssh directory permissions with a cron job or script.
• Enable StrictModes yes in sshd_config (default) to enforce permission checks.
• Keep SELinux/AppArmor enabled and configure SSH contexts properly.
• Use key passphrases and consider SSH certificates for large environments.

By following these steps, you can resolve the 'Permission denied' error and ensure reliable SSH public key authentication.