Fix SSH Permission Denied with Public Key Authentication

Symptoms

When attempting to connect to a Linux/Unix server via SSH using public key authentication, you receive one of the following errors:

• Permission denied (publickey)
• Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
• Authentication failed. Permission denied.

The connection fails even though the correct key pair is in place. Debug output (ssh -vvv user@host) often shows the server rejecting the offered key.

Root Causes

The most common causes are:

1. Incorrect file permissions on the ~/.ssh directory or the authorized_keys file on the server.
2. Wrong ownership of the .ssh directory or its contents.
3. Misconfigured sshd_config disabling public key authentication or restricting key usage.
4. Incorrect key format or missing public key in authorized_keys.
5. SELinux or AppArmor blocking SSH key access.

Step-by-Step Fix

1. Verify Key Pair

Ensure your private key (~/.ssh/id_rsa or similar) is present on the client and the corresponding public key is appended to ~/.ssh/authorized_keys on the server. Check the public key file on the server:

cat ~/.ssh/authorized_keys

If the file doesn't exist, create it and paste your public key:

echo 'ssh-rsa AAAAB3NzaC1yc2E...' >> ~/.ssh/authorized_keys

2. Set Correct Permissions on Server

Log in to the server (via console or another method) and run:

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

Also ensure the home directory is not writable by group or others:

chmod go-w ~

3. Set Correct Ownership

The .ssh directory and its contents must be owned by the user, not root:

chown -R $(whoami):$(whoami) ~/.ssh

4. Check SSH Server Configuration

Edit /etc/ssh/sshd_config and verify these lines are present and uncommented:

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

Then restart SSH service:

sudo systemctl restart sshd

5. Debug with Verbose Mode

On the client, run:

ssh -vvv user@server

Look for lines like:

• debug1: Offering public key: /home/user/.ssh/id_rsa — client is offering the key.
• debug2: we sent a publickey packet, wait for reply
• debug1: Authentication succeeded (publickey) — success.
• debug1: Authentications that can continue: publickey — server still waiting for valid key.

If the server rejects the key, check the server logs (/var/log/auth.log or /var/log/secure) for details like Authentication refused: bad permissions.

Alternative Fixes

Check SELinux Context

If SELinux is enforcing, restore default contexts:

restorecon -Rv ~/.ssh

Use StrictModes

If you want to bypass permission checks temporarily (not recommended for production), set StrictModes no in sshd_config. But fix permissions instead.

Verify Key Fingerprint

On the server, check the fingerprint of the stored key:

ssh-keygen -lf ~/.ssh/authorized_keys

Compare with your client's public key fingerprint:

ssh-keygen -lf ~/.ssh/id_rsa.pub

Prevention

• Always use ssh-copy-id user@server to automatically set correct permissions.
• Never set StrictModes no in production.
• Regularly audit ~/.ssh permissions with stat or ls -la.
• Use a configuration management tool (Ansible, Puppet) to enforce permissions.
• Keep SSH server updated and follow security best practices.

By following these steps, you should be able to resolve SSH permission denied errors and restore key-based authentication.