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, the connection fails with the message: Permission denied (publickey). The client may have the correct private key, but the server rejects the authentication attempt. This often occurs even after copying the public key to the server using ssh-copy-id or manually.

Root Causes

The most common root causes include:

• Incorrect file permissions on the .ssh directory or authorized_keys file on the server.
• Wrong ownership of the .ssh directory or files (must be owned by the user).
• SSH daemon configuration issues, such as PubkeyAuthentication no or AuthorizedKeysFile pointing to a wrong location.
• SELinux or AppArmor security contexts blocking access to the authorized_keys file.
• Corrupted or mismatched key pair (public key on server does not match private key on client).
• Strict host key checking or StrictModes setting in sshd_config causing rejection.

Step-by-Step Fix

1. Verify Key Pair

Ensure the public key on the server matches the private key on the client. On the client, run: ssh-keygen -lf ~/.ssh/id_rsa.pub. On the server, check: cat ~/.ssh/authorized_keys. The key strings should match.

2. Check File Permissions on Server

SSH is very strict about permissions. Log into the server as the target user and run:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts (if present)

Ensure the .ssh directory and files are owned by the user: chown $USER:$USER ~/.ssh -R.

3. Verify SSH Daemon Configuration

Check /etc/ssh/sshd_config for these settings:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
StrictModes yes

After changes, restart SSH: sudo systemctl restart sshd or sudo service ssh restart.

4. Check SELinux Context (if enabled)

If SELinux is enforcing, restore default contexts:

restorecon -Rv ~/.ssh

Or check with ls -Z ~/.ssh/authorized_keys; it should be ssh_home_t.

5. Enable Verbose Logging on Client

Run SSH with -vvv to see detailed debug output: ssh -vvv user@host. Look for lines like Authentication refused: bad permissions or Offering public key to pinpoint the issue.

6. Check Server Logs

On the server, examine /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) for SSH entries: sudo tail -f /var/log/auth.log. Look for Authentication refused or Failed publickey messages.

Alternative Fixes

• Disable StrictModes temporarily (not recommended for production) by setting StrictModes no in sshd_config and restarting SSH.
• Use a different key type (e.g., ed25519) if RSA keys are not working due to legacy restrictions.
• Add the public key manually using echo 'ssh-rsa AAA...' >> ~/.ssh/authorized_keys and ensure no extra whitespace.
• Check home directory permissions: The user's home directory should not be writable by group or others (e.g., chmod 755 ~).

Prevention

• Always use ssh-copy-id to copy keys; it sets correct permissions automatically.
• Regularly audit .ssh directory permissions with a script or cron job.
• Keep SSH daemon updated and review sshd_config after system updates.
• Use configuration management tools (Ansible, Puppet) to enforce correct permissions across servers.
• Enable SELinux and properly label SSH files to prevent context drift.

By following these steps, you can resolve most SSH public key authentication issues and maintain secure, reliable remote access.