Fix SSH Permission Denied Public Key Authentication

Symptoms

When attempting to connect to a remote server using SSH public key authentication, you receive an error similar to:

Permission denied (publickey).

The connection fails even though the public key appears to be correctly placed in the authorized_keys file. The SSH server may also log messages like Authentication refused: bad permissions or Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Root Causes

The most common causes are:

Incorrect file permissions on the .ssh directory or authorized_keys file. SSH is strict about permissions to prevent security risks.
Wrong ownership of the .ssh directory or its contents. The files must be owned by the user attempting to log in.
Misconfigured SSH server settings in sshd_config, such as PubkeyAuthentication no or AuthorizedKeysFile pointing to the wrong location.
Incorrect key format or extra whitespace in the authorized_keys file.
SELinux or AppArmor restrictions blocking key-based authentication.

Step-by-Step Fix

Check SSH server logs – On the server, view logs:
```
sudo tail -f /var/log/auth.log
```
(Debian/Ubuntu) or
```
sudo tail -f /var/log/secure
```
(RHEL/CentOS). Look for specific error messages.
Verify file permissions – On the server, ensure the following permissions are set (replace username with the actual user):
- Home directory: chmod 755 /home/username (or 700 for stricter security)
- .ssh directory: chmod 700 ~/.ssh
- authorized_keys file: chmod 600 ~/.ssh/authorized_keys
Correct ownership – Set ownership to the user:
```
chown -R username:username ~/.ssh
```
Check SSH configuration – Edit /etc/ssh/sshd_config and ensure:
- PubkeyAuthentication yes
- AuthorizedKeysFile .ssh/authorized_keys
- PasswordAuthentication no (if using only keys)
Then restart SSH:
```
sudo systemctl restart sshd
```
Validate key content – Ensure the public key in authorized_keys is a single line, no extra spaces, and matches the private key. Use:
```
ssh-keygen -y -f ~/.ssh/id_rsa
```
to verify the public key.
Test with verbose output – From the client, run:
```
ssh -vvv user@server
```
to see detailed debug messages indicating where authentication fails.
Check SELinux/AppArmor – If SELinux is enforcing, restore context:
```
restorecon -Rv ~/.ssh
```
For AppArmor, check profiles in /etc/apparmor.d/.

Alternative Fixes

Use ssh-copy-id – If permissions are correct but key not installed, use:
```
ssh-copy-id user@server
```
This sets proper permissions automatically.

Manually copy key – Append the public key to authorized_keys:

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

Disable strict mode (not recommended) – Set StrictModes no in sshd_config as a temporary workaround.

Prevention

Always use ssh-copy-id to install keys automatically.
Set correct permissions immediately after creating .ssh directory.
Regularly audit SSH configuration and permissions.
Use automation tools (Ansible, Puppet) to enforce consistent settings.
Keep SSH server updated to avoid bugs.

Additional Tips

File/Directory	Required Permission	Owner
`/home/username`	755 or 700	username
`~/.ssh`	700	username
`~/.ssh/authorized_keys`	600	username
`~/.ssh/config`	600	username

By following these steps, you should resolve the 'Permission denied' error and restore SSH public key authentication.