Linux 'Permission Denied' fix for SSH public key login

You're trying to SSH into a Linux server with a key pair, and you get this:

Permission denied (publickey)

It's infuriating. You've copied your public key to ~/.ssh/authorized_keys on the server. You've double-checked the key content. The SSH daemon is running. But it still fails. I hit this one hard the first time I set up a headless Ubuntu 22.04 server.

The real fix is almost always permissions. SSH is paranoid about who can read and write your keys and config files. The daemon will reject your key if the permissions on ~/.ssh or authorized_keys are too loose.

Root cause

SSH's sshd checks that ~/.ssh is not group-writable or world-writable. It also checks that authorized_keys is not group-writable or world-writable. If either is, SSH assumes the file could be tampered with and refuses to use the key. This is a security feature, not a bug. The same applies to your private key on the client side.

Common trigger: you copied the key using sudo cp or sudo scp, which left the files owned by root. Or you used chmod 777 out of desperation. Both will fail.

The fix

Log into the server (using a password or console) and run these commands as the user you're trying to SSH to. Replace username with the actual username.

1. Set the home directory's owner and group. Make sure the user owns their home:

sudo chown username:username /home/username

2. Fix the .ssh directory permissions. It must be 700 (read/write/execute for owner only):

chmod 700 /home/username/.ssh

3. Fix the authorized_keys file permissions. Must be 600 (read/write for owner only):

chmod 600 /home/username/.ssh/authorized_keys

4. Verify ownership of .ssh and authorized_keys. They should be owned by the user:

ls -la /home/username/.ssh

You should see something like:

drwx------ 2 username username 4096 Mar 10 14:22 .
-rw------- 1 username username 589 Mar 10 14:22 authorized_keys

5. Check the parent directories. The home directory itself should not be group-writable or world-writable:

ls -la /home/

If it shows drwxrwxr-x, fix it:

sudo chmod 755 /home/username

6. Restart the SSH daemon. On most systems:

sudo systemctl restart sshd

On older systems without systemd:

sudo service ssh restart

7. Test the connection. From the client:

ssh -i ~/.ssh/id_rsa username@server-ip

If still fails, run SSH in debug mode on the client:

ssh -vvv -i ~/.ssh/id_rsa username@server-ip

Look for lines like Authentication refused: bad permissions or Permission denied (publickey).

What if it still fails?

Check these three things:
- Is the public key in authorized_keys exactly as generated? No extra spaces, line breaks, or trailing newlines. Use a single line per key.
- Is PasswordAuthentication no set in /etc/ssh/sshd_config? If so, you won't get a password prompt. Double-check the key path on the client.
- Is SELinux or AppArmor blocking? On RHEL/CentOS 8, SELinux can block SSH key reads. Run restorecon -R -v /home/username/.ssh to fix SELinux contexts. On Ubuntu, AppArmor profiles for SSH are rare but check sudo aa-status.

One last thing: if you're using a non-default SSH port, specify -p 2222 (replace with your port). I've wasted time assuming port 22 when the server used 2222.

That's it. Get those permissions right, and SSH will trust your keys again.