Fix SSH Permission Denied with Public Key Authentication

Symptoms

When attempting to connect to a remote Linux or Unix server using SSH public key authentication, you receive the error: Permission denied (publickey). The SSH client may try multiple keys and fail, or the server may immediately reject the connection without prompting for a password. This typically occurs even though the public key has been correctly added to the ~/.ssh/authorized_keys file on the server.

Root Causes

The most common causes for this error are:

• Incorrect file permissions on the ~/.ssh directory or files (authorized_keys, private key). SSH is very strict about permissions and will reject keys if they are too permissive.
• Wrong ownership of the .ssh directory or files (must be owned by the user, not root).
• sshd configuration issues: PubkeyAuthentication may be disabled, or AuthorizedKeysFile may point to a non-standard location.
• Key format or content problems: The public key in authorized_keys may have extra whitespace, incorrect line breaks, or be truncated.
• SELinux or AppArmor blocking access to the key files.

Step-by-Step Fix

1. Check SSH Server Logs

On the server, examine /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) for detailed error messages. Use:

sudo tail -f /var/log/auth.log

Look for lines containing sshd and Authentication refused or bad permissions.

2. Fix Permissions on the Server

Ensure correct permissions for the user's home directory and .ssh folder:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_rsa   # if private key is on server
chmod 644 ~/.ssh/id_rsa.pub
chmod 755 ~               # home directory should not be writable by group/others

Also verify ownership:

chown -R $USER:$USER ~/.ssh

3. Verify the Public Key

Ensure the public key in authorized_keys matches exactly the one on the client. On the client, run:

cat ~/.ssh/id_rsa.pub

Compare it with the content on the server. Remove any extra spaces or newlines. Each key should be on a single line.

4. Check SSH Daemon Configuration

On the server, edit /etc/ssh/sshd_config and ensure these lines are set:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no   # optional, for key-only access
StrictModes yes

Then restart SSH:

sudo systemctl restart sshd

5. Debug SSH Connection

Run SSH with verbose output from the client:

ssh -vvv user@server

Look for lines like Offering public key and Authentication refused: bad permissions. This pinpoints the issue.

6. Check SELinux Contexts (if applicable)

If SELinux is enforcing, restore default contexts:

restorecon -Rv ~/.ssh

Or temporarily set to permissive to test:

sudo setenforce 0

If that fixes it, adjust SELinux policies permanently.

Alternative Fixes

• Use ssh-copy-id to automatically copy the key with correct permissions: ssh-copy-id user@server.
• Check known_hosts: If the server key changed, remove old entry with ssh-keygen -R server.
• Verify key algorithm: Some older servers may not support Ed25519 keys; use RSA with at least 2048 bits.
• Try password authentication temporarily to rule out key issues: set PasswordAuthentication yes in sshd_config.

Prevention

• Always use ssh-copy-id to add keys automatically.
• Set up a configuration management tool (Ansible, Puppet) to enforce correct permissions.
• Regularly audit ~/.ssh permissions with scripts.
• Use SSH certificates for scalable key management.
• Keep SSH daemon updated and review logs periodically.