Fix SSH 'Permission denied (publickey)' on Linux

Quick answer: Run ssh -vvv user@host to see which keys are tried. Then ensure your public key is in ~/.ssh/authorized_keys on the target, and permissions are 700 for .ssh and 600 for authorized_keys.

What's going on?

You're trying to SSH into a Linux server and you get the dreaded 'Permission denied (publickey)'. I've seen this more times than I can count — it tripped me up the first time I set up a remote server too. The core issue is that the SSH server doesn't trust the key you're presenting. Either your public key isn't in the server's ~/.ssh/authorized_keys file, the permissions are wrong (which makes OpenSSH cry), or you're connecting with the wrong username or key file.

This usually happens right after spinning up a new cloud instance (AWS EC2, DigitalOcean Droplet, Linode), or when you've copied keys manually but messed up a line break or an octal permission.

Step-by-step fix

Enable verbose SSH output. Run ssh -vvv user@host. Look for lines like 'Offering public key: /home/you/.ssh/id_rsa' and 'Authentication refused: bad permissions'. That tells you exactly what's failing.
Check your local key exists. ls -la ~/.ssh/. You should see at least id_rsa and id_rsa.pub (or id_ed25519). If not, generate one: ssh-keygen -t ed25519 -a 100.
Copy your public key to the server. The best way: ssh-copy-id user@host. If you can't use that (some distros don't have it), do this manually:
```
cat ~/.ssh/id_rsa.pub | ssh user@host 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'
```
Fix permissions on the server. SSH is paranoid about permissions. On the target machine (if you have any access), set these:
```
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
```
Even if you're root, do this. I've seen chmod 644 on authorized_keys cause the exact 'permission denied' error.
Verify the key content. Make sure your local id_rsa.pub is exactly one line ending with a newline. Open authorized_keys on the server and check it's the same string. No extra spaces, no line breaks in the middle.
Try a different key. If you have multiple keys (like id_rsa and id_ed25519), specify one: ssh -i ~/.ssh/id_ed25519 user@host.
Check server config. As root on the target, look at /etc/ssh/sshd_config. Ensure these aren't commented out or set to 'no':
```
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
```
Then restart SSH: systemctl restart sshd.

If the main fix doesn't work

Sometimes the issue is deeper. Try these alternatives:

Use your root password (if possible). Connect via console (like a web VNC or IPMI) and add your key manually. Or ssh root@host if root has password login enabled (bad security, but sometimes needed for first setup).
Check SELinux or AppArmor. On CentOS/RHEL, SELinux can block SSH key reads. Run restorecon -Rv ~/.ssh as the target user.
Look at client-side config. Your ~/.ssh/config could be overriding the key. Check for IdentityFile directives pointing to non-existent files.
Try password authentication. If the server allows it (uncommon in cloud images), add -o PreferredAuthentications=password to see if you get a password prompt.

Prevention — don't let this happen again

Use ssh-copy-id every time you set up a new server. It sets permissions automatically.
Generate Ed25519 keys — they're shorter, faster, and more secure than RSA 4096.
Add a comment to your key with -C "your_email" so you know which key is which when you look at authorized_keys.
Test your connection before closing the existing session: open a second terminal and try ssh user@host. If it fails, you still have the first session to fix it.

This error is a rite of passage for anyone managing Linux servers. Once you understand the permissions and key file layout, you'll fix it in under a minute. The verbose flag is your best friend — it tells you exactly why the server said no.