SSH Permission Denied: Fix 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 key pair appears correct. Common symptoms include:

• SSH server logs show Authentication refused: bad permissions or no matching key exchange method found
• Client receives Permission denied (publickey) immediately without password prompt
• Key authentication works for some users but not others
• After copying the public key to the server, authentication still fails

Root Causes

1. Incorrect File Permissions

The most common cause is overly permissive permissions on the .ssh directory or authorized_keys file. SSH is strict about these permissions for security reasons.

2. Wrong File Ownership

The .ssh directory and its contents must be owned by the user attempting to log in, not root or another user.

3. SSH Daemon Configuration

The sshd_config file may have PubkeyAuthentication set to no, or AuthorizedKeysFile points to the wrong location.

4. SELinux or AppArmor Interference

Mandatory access control systems can block SSH key authentication even when file permissions are correct.

5. Key Format or Location Issues

The public key may be in an unsupported format, or the private key may have incorrect permissions on the client side.

Step-by-step Fix

Step 1: Check Server-Side File Permissions

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

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

Step 2: Verify File Ownership

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

Replace $USER with the actual username.

Step 3: Check SSH Daemon Configuration

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 SSH: sudo systemctl restart sshd or sudo service ssh restart.

Step 4: Verify SELinux Context (if applicable)

restorecon -R -v ~/.ssh

Or temporarily disable SELinux for testing: sudo setenforce 0. Re-enable after testing.

Step 5: Check Client-Side Private Key Permissions

On the client machine:

chmod 600 ~/.ssh/id_rsa   # or id_ed25519, etc.

Step 6: Test Connection Verbosely

ssh -vvv user@server

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

Alternative Fixes

Use ssh-copy-id

If permissions are correct but keys aren't being accepted, re-copy the key:

ssh-copy-id user@server

Manually Append Public Key

If ssh-copy-id fails, manually append the public key:

cat ~/.ssh/id_rsa.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Check for Multiple Key Attempts

Use ssh -i /path/to/key user@server to specify the exact private key.

Disable StrictHostKeyChecking (Temporary)

For testing only, add -o StrictHostKeyChecking=no to bypass host key verification issues.

Prevention

• Use ssh-copy-id to automatically set correct permissions when copying keys.
• Regularly audit permissions with find ~/.ssh -type f -exec ls -la {} \;
• Keep backups of sshd_config before making changes.
• Test with verbose mode (-vvv) to catch issues early.
• Use key types like ed25519 for better security and compatibility.
• Document SELinux policies if using them, and run restorecon after file operations.
• Set up monitoring for SSH authentication failures in logs (/var/log/auth.log or /var/log/secure).

By following these steps, you can resolve most SSH public key authentication permission denied errors and maintain a secure, reliable key-based login system.