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
.sshdirectory orauthorized_keysfile. SSH is strict about permissions to prevent security risks. - Wrong ownership of the
.sshdirectory or its contents. The files must be owned by the user attempting to log in. - Misconfigured SSH server settings in
sshd_config, such asPubkeyAuthentication noorAuthorizedKeysFilepointing to the wrong location. - Incorrect key format or extra whitespace in the
authorized_keysfile. - 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) orsudo 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
usernamewith the actual user):- Home directory:
chmod 755 /home/username(or700for stricter security) .sshdirectory:chmod 700 ~/.sshauthorized_keysfile:chmod 600 ~/.ssh/authorized_keys
- Home directory:
- Correct ownership – Set ownership to the user:
chown -R username:username ~/.ssh
- Check SSH configuration – Edit
/etc/ssh/sshd_configand ensure:PubkeyAuthentication yesAuthorizedKeysFile .ssh/authorized_keysPasswordAuthentication no(if using only keys)
sudo systemctl restart sshd
- Validate key content – Ensure the public key in
authorized_keysis 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 noinsshd_configas a temporary workaround.
Prevention
- Always use
ssh-copy-idto install keys automatically. - Set correct permissions immediately after creating
.sshdirectory. - 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.