Fix SSH Permission denied (publickey) error on Linux

You're getting kicked out of SSH with 'Permission denied (publickey)'. Nine times out of ten it's wrong file permissions or the wrong key. Here's how to fix it fast.

1. Wrong permissions on ~/.ssh or authorized_keys

This is the #1 cause. SSH is paranoid about permissions. If your ~/.ssh directory or ~/.ssh/authorized_keys file has world-writable or group-writable permissions, OpenSSH flat-out refuses to use public key authentication. It's a security feature, not a bug.

# Fix permissions on the server (not client)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts  # this one's less critical but keep it sane

Make sure the .ssh directory and the key files are owned by you, not root or someone else. Run ls -la ~/.ssh to check. The owner column should show your username. If it's root, run chown -R youruser:youruser ~/.ssh.

Real-world trigger: You copied authorized_keys from a backup or another server using cp -r, and the permissions got mangled. SSH says nope.

2. Wrong key pasted into authorized_keys

People copy-paste public keys from emails, web UIs, or terminal output and accidentally grab extra whitespace, line breaks, or garbage characters. The key must be exactly one line, starting with ssh-rsa, ssh-ed25519, or ecdsa-sha2-nistp256.

Check the file with cat -A ~/.ssh/authorized_keys. You should see no ^M (carriage return) characters unless you're on a Mac. Each line should end with $. If you see ^M$, run dos2unix ~/.ssh/authorized_keys to strip the Windows line endings.

Quick test: Append the public key manually using:

echo 'ssh-ed25519 AAAAC3... your-comment' >> ~/.ssh/authorized_keys

Don't copy-paste from a web browser into a terminal — the formatting often breaks.

3. Server's sshd_config is blocking public key auth

Less common but still bites people. The SSH daemon on the server might have PubkeyAuthentication set to no or PasswordAuthentication set to yes when you're expecting key-only login.

Check the server's /etc/ssh/sshd_config for these lines:

PubkeyAuthentication yes
PasswordAuthentication no   # if you want key-only
AuthorizedKeysFile .ssh/authorized_keys

If you changed anything, restart sshd: sudo systemctl restart sshd (or sudo service ssh restart on older systems).

Note: Some cloud images (like Ubuntu on AWS) have PasswordAuthentication no by default but also disable root login with keys. Double-check PermitRootLogin if you're trying to log in as root.

Quick-reference summary table

Cause	Fix	Check command
Bad permissions on ~/.ssh or authorized_keys	chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys	ls -la ~/.ssh
Corrupted or malformed public key in authorized_keys	Re-add key with echo >> authorized_keys	cat -A ~/.ssh/authorized_keys
sshd_config blocks publickey auth	Set PubkeyAuthentication yes, restart sshd	grep Pubkey /etc/ssh/sshd_config

If none of this works, run SSH in debug mode on the client: ssh -vvv user@host. Look for lines starting with debug1: that say things like Permission denied (publickey) or Offering public key. That tells you exactly which key the client is sending and where the server rejects it. Most of the time, the debug output shows the server complaining about bad permissions — that's your clue.