Fix SSH Permission Denied with Public Key Authentication

Symptoms

When attempting to connect to a remote 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 correctly generated and placed the public key on the server.

Root Causes

The most common causes for this error are:

• Incorrect permissions on the ~/.ssh directory or authorized_keys file on the server.
• Wrong ownership of the .ssh directory or authorized_keys file (must be owned by the user).
• Public key not appended to ~/.ssh/authorized_keys correctly.
• SSH server configuration (sshd_config) disables public key authentication or restricts key types.
• Private key permissions on the client are too permissive (SSH requires private key to be readable only by the user).
• Key format mismatch (e.g., OpenSSH vs. legacy PEM format).

Step-by-Step Fix

1. Verify Client Private Key Permissions

On your local machine, ensure the private key file (e.g., ~/.ssh/id_rsa) has strict permissions:

chmod 600 ~/.ssh/id_rsa

Also check the .ssh directory itself:

chmod 700 ~/.ssh

2. Check Server-Side Permissions

Log into the remote server (using another method like password or console) and run:

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

Ensure the ~/.ssh directory and authorized_keys file are owned by your user (not root):

chown $USER:$USER ~/.ssh
chown $USER:$USER ~/.ssh/authorized_keys

3. Verify Public Key Content

Check that the public key (~/.ssh/id_rsa.pub) is correctly appended to ~/.ssh/authorized_keys on the server. Each key should be on a single line. Use:

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

If you manually edited the file, ensure no extra whitespace or line breaks.

4. Check SSH Server Configuration

On the server, open /etc/ssh/sshd_config and verify these settings are present and uncommented:

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

If you change sshd_config, restart the SSH service:

sudo systemctl restart sshd

5. Test with Verbose Output

Run SSH with -vvv to see detailed logs:

ssh -vvv user@server

Look for lines indicating which keys are offered and why they are rejected (e.g., bad permissions).

Alternative Fixes

• Use ssh-copy-id: Automate key deployment: ssh-copy-id user@server
• Check SELinux: On RHEL/CentOS, SELinux may block SSH. Temporarily set to permissive to test: sudo setenforce 0. If it works, restore context: restorecon -Rv ~/.ssh
• Key type issues: If using older clients, try generating an RSA key with ssh-keygen -t rsa -b 2048 instead of Ed25519.
• Agent forwarding: If using an SSH agent, ensure the key is added: ssh-add ~/.ssh/id_rsa

Prevention

• Always use ssh-copy-id to transfer public keys to avoid manual permission errors.
• Set up a cron job or script to periodically check .ssh permissions.
• Use StrictModes yes in sshd_config (default) to enforce correct permissions.
• Document your SSH key management process for team members.