Fix SSH Permission Denied with Public Key Authentication

Symptoms

When attempting to connect via SSH using public key authentication, you receive the error: Permission denied (publickey). The connection fails even though the public key is correctly added to the remote server's authorized_keys file. The SSH client may prompt for a password (if password authentication is enabled) or simply disconnect.

Root Causes

This issue typically arises from incorrect file permissions on the .ssh directory or the authorized_keys file on the remote server. Other causes include:

• Incorrect ownership: The .ssh directory and its contents must be owned by the user, not root.
• Wrong permissions: SSH is strict about permissions. The .ssh directory should be 700 (drwx------), and authorized_keys should be 600 (-rw-------).
• SSH daemon configuration: The sshd_config may have PubkeyAuthentication no or AuthorizedKeysFile pointing to a non-standard location.
• SELinux or AppArmor: Mandatory access control can block SSH key authentication.
• Key format or type: Some older SSH servers reject newer key types like Ed25519 or ECDSA.

Step-by-Step Fix

Step 1: Check SSH Debug Output

Run the SSH command with verbose output to get details:

ssh -vvv user@remote_host

Look for lines like debug1: Authentications that can continue: publickey and debug1: Offering public key: .... If you see debug1: key_parse_private2: no hostkey alg or debug1: permissions 0644 for '/home/user/.ssh/authorized_keys' are too open., permissions are the issue.

Step 2: Correct Permissions on Remote Server

Log in via another method (console, password, or another user) and run:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $(whoami):$(whoami) ~/.ssh

If ~/.ssh doesn't exist, create it:

mkdir -p ~/.ssh && chmod 700 ~/.ssh

Step 3: Verify SSH Daemon Configuration

Edit /etc/ssh/sshd_config (or /etc/ssh/sshd_config.d/ on some systems) and ensure these lines are set:

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

Then restart SSH:

sudo systemctl restart sshd

Step 4: Check SELinux Context (if enabled)

If SELinux is enforcing, restore contexts:

restorecon -Rv ~/.ssh

Or set them manually:

chcon -R -t ssh_home_t ~/.ssh

Step 5: Verify Key Pair

Ensure the public key on the server matches the private key on the client. The public key should be a single line starting with ssh-rsa, ssh-ed25519, etc. Append it to authorized_keys if missing:

cat id_rsa.pub >> ~/.ssh/authorized_keys

Alternative Fixes

• Use ssh-copy-id: This tool automatically sets correct permissions: ssh-copy-id user@remote_host
• Disable StrictModes: As a temporary workaround, set StrictModes no in sshd_config (not recommended for production).
• Check home directory permissions: The home directory should not be writable by group or others: chmod go-w ~
• Use a different key type: Generate an RSA key if using Ed25519: ssh-keygen -t rsa -b 4096

Prevention

• Always use ssh-copy-id to install public keys.
• Set up a configuration management tool (Ansible, Puppet) to enforce correct permissions.
• Regularly audit sshd_config with tools like ssh-audit.
• Enable logging and monitor /var/log/auth.log for SSH errors.
• Use SSH certificates for scalable key management.

By following these steps, you can resolve 'Permission denied (publickey)' and ensure reliable SSH key authentication.