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 an error similar to:

ssh -i ~/.ssh/id_rsa user@hostname

Output:

Permission denied (publickey).

Or in the server logs (/var/log/auth.log or /var/log/secure):

Authentication refused: bad ownership or modes for directory /home/user/.ssh

This occurs even though the public key is correctly placed in ~/.ssh/authorized_keys.

Root Causes

The most common root causes for SSH public key authentication failure are:

1. Incorrect file permissions on the .ssh directory or authorized_keys file. SSH is very strict about permissions to prevent security breaches.
2. Wrong ownership of the .ssh directory or its contents. The files must belong to the user, not root or another user.
3. Misconfigured sshd_config on the server, such as PubkeyAuthentication no or AuthorizedKeysFile pointing to the wrong location.
4. Incorrect key format or extra whitespace in authorized_keys.
5. SELinux or AppArmor blocking access to the key file.

Step-by-Step Fix

Step 1: Verify SSH Server Configuration

On the server, check the SSH daemon configuration:

sudo grep -E '^(PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication)' /etc/ssh/sshd_config

Expected output:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

If PubkeyAuthentication is set to no, change it to yes and restart SSH:

sudo sed -i 's/^PubkeyAuthentication no/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Step 2: Set Correct Permissions on Server

Log into the server as the target user and run:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/id_rsa.pub   # if present
chmod 600 ~/.ssh/id_rsa       # if present (private key)

Ensure the .ssh directory is owned by the user:

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

Step 3: Verify authorized_keys Content

Check that the public key is correctly added:

cat ~/.ssh/authorized_keys

Each line should contain exactly one public key, starting with ssh-rsa or ssh-ed25519 etc. Remove any extra spaces or newlines.

Step 4: Test Connection Verbosely

From the client, run with verbose output:

ssh -v -i ~/.ssh/id_rsa user@hostname

Look for lines like:

debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Authentication succeeded (publickey).

If you see debug1: send_pubkey_test: no mutual signature algorithm, the server may not support your key type. Consider using Ed25519 keys.

Step 5: Check SELinux Context (if applicable)

On systems with SELinux (e.g., CentOS, RHEL), restore default contexts:

restorecon -Rv ~/.ssh

Check for denials:

sudo ausearch -m avc -ts recent | grep ssh

Alternative Fixes

• Use password authentication temporarily if enabled, to fix permissions: ssh user@hostname (if PasswordAuthentication yes). Then fix permissions.
• Add key via ssh-copy-id which sets correct permissions automatically: ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname.
• Check home directory permissions: The home directory should not be writable by group or others. Fix with chmod go-w ~.
• Disable strict mode (not recommended): Set StrictModes no in sshd_config as a temporary workaround.

Prevention

• Use ssh-copy-id to add keys; it sets correct permissions automatically.
• Automate permission checks with a script or configuration management tool (Ansible, Puppet).
• Regularly audit SSH configuration and permissions using tools like ssh-audit.
• Use Ed25519 keys for better security and compatibility.
• Keep sshd_config minimal and test changes in a staging environment.

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