Fix SSH Permission Denied with Public Key Authentication

Symptoms

When attempting to connect via SSH using public key authentication, the connection fails with a 'Permission denied (publickey)' error. The user may have correctly generated and placed the public key on the server, but authentication still fails. Debug output shows the server rejecting the offered key.

Root Causes

The most common root causes are:

• Incorrect file permissions on the ~/.ssh directory or authorized_keys file.
• The authorized_keys file is owned by the wrong user or group.
• The sshd_config file has strict settings like PubkeyAuthentication no or AuthorizedKeysFile pointing to the wrong location.
• SELinux or AppArmor blocking access.
• Key format issues (e.g., old key format not supported).

Step-by-Step Fix

1. Check SSH Debug Output

Run SSH with verbose logging to see where the failure occurs:

ssh -vvv user@server

Look for lines like 'debug1: Authentication refused: bad permissions' or 'debug1: Offering public key'.

2. Verify File Permissions on Server

On the server, ensure the following permissions are set:

• The user's home directory should not be writable by group or others (e.g., chmod go-w ~).
• The ~/.ssh directory must have permissions 700 (drwx------).
• The ~/.ssh/authorized_keys file must have permissions 600 (-rw-------).
• The ~/.ssh directory and its contents must be owned by the user.

Fix with:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

3. Check sshd_config

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

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

Then restart the SSH service:

sudo systemctl restart sshd

4. Verify Key Format

Ensure the public key in authorized_keys is a single line starting with 'ssh-rsa', 'ssh-ed25519', etc. It should match the private key. Check with:

ssh-keygen -l -f ~/.ssh/id_rsa.pub

5. Check SELinux/AppArmor

If SELinux is enforcing, restore contexts:

restorecon -Rv ~/.ssh

For AppArmor, check logs in /var/log/syslog for denials.

Alternative Fixes

• If the key is in an old format, regenerate with ssh-keygen -t ed25519.
• If using a non-standard port, ensure the client specifies it with -p.
• Check if the server has AllowUsers or DenyUsers directives that may block the user.
• Try connecting from a different client to isolate client-side issues.

Prevention

• Always set correct permissions immediately after creating .ssh directory.
• Use ssh-copy-id to copy keys automatically with proper permissions.
• Regularly audit sshd_config and permissions on production servers.
• Enable logging with LogLevel VERBOSE in sshd_config for easier troubleshooting.

Additional Resources

Refer to the OpenSSH manual pages: man sshd_config, man ssh. For SELinux issues, see man restorecon.