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 following error message:

Permission denied (publickey).

Or, in verbose mode (ssh -v user@host), you may see:

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

The connection fails even though the public key has been correctly added to the server's ~/.ssh/authorized_keys file.

Root Causes

The most common cause is incorrect file permissions on the server side. SSH is very strict about permissions for security reasons. The following conditions can cause this error:

• The ~/.ssh directory has permissions that are too permissive (e.g., 777 or 755). It must not be writable by group or others.
• The ~/.ssh/authorized_keys file has permissions that are too open (e.g., 644 is acceptable, but 600 is recommended).
• The user's home directory is writable by group or others, which SSH considers insecure.
• The authorized_keys file is owned by the wrong user or group.
• The SSH server configuration (sshd_config) has PubkeyAuthentication set to no or AuthorizedKeysFile points to a non-existent file.

Step-by-Step Fix

Follow these steps on the server (the machine you are trying to connect to):

1. Log in to the server using an alternative method (password, console, or another user with sudo).
2. Check current permissions:

   ls -la ~ | grep -E '^\.ssh|home'
   ls -la ~/.ssh/

3. Fix home directory permissions: The home directory should not be writable by group or others.

   chmod go-w ~

4. Fix .ssh directory permissions: It must be owned by the user and have 700 permissions.

   chmod 700 ~/.ssh
   chown $USER:$USER ~/.ssh

5. Fix authorized_keys file permissions: The file should have 600 permissions and be owned by the user.

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

6. Verify permissions:

   ls -la ~/.ssh/

   Expected output:

   drwx------ 2 user user 4096 Jan 1 12:00 .
   -rw------- 1 user user 400 Jan 1 12:00 authorized_keys

7. Test the connection from the client again:

   ssh -i ~/.ssh/id_rsa user@host

Alternative Fixes

Check SSH Server Configuration

If permissions are correct but the issue persists, check the SSH daemon configuration:

sudo grep -E '^(PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication)' /etc/ssh/sshd_config

Ensure PubkeyAuthentication yes and AuthorizedKeysFile .ssh/authorized_keys. If you changed the config, restart SSH:

sudo systemctl restart sshd

Use StrictModes no (Not Recommended)

As a temporary workaround, you can set StrictModes no in sshd_config, but this reduces security. Only use for testing.

Check SELinux or AppArmor

On systems with SELinux (e.g., CentOS, RHEL), the context of ~/.ssh/authorized_keys may be incorrect. Restore it:

restorecon -Rv ~/.ssh

Or check with:

ls -Z ~/.ssh/authorized_keys

Client-Side Checks

Ensure the private key on the client has correct permissions (600):

chmod 600 ~/.ssh/id_rsa

Prevention

• Always use ssh-copy-id to install public keys, as it automatically sets correct permissions.
• Never change permissions of ~/.ssh or authorized_keys manually unless you know the exact requirements.
• Regularly audit SSH configuration and permissions using tools like ssh-audit.
• Use configuration management (Ansible, Puppet) to enforce correct permissions across servers.
• Enable logging on the SSH server to detect permission issues early: set LogLevel VERBOSE in sshd_config.