Fix SSH Permission Denied (publickey) on Linux

Quick answer

Run

chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_rsa ~/.ssh/id_ed25519 ~/.ssh/authorized_keys 2>/dev/null

then reconnect. If it still fails, check that ~/.ssh/config points to the right key file.

Why this happens

OpenSSH is paranoid about file permissions on purpose. If your private key is readable by anyone else (group or other), or if the .ssh directory itself is writable by group/other, the SSH client refuses to use that key. The server side also checks that ~/.ssh and ~/.ssh/authorized_keys aren't too open. This catches you most often after you copy keys manually with cp or mv from a backup — those commands don't preserve safe permissions. I've seen it happen right after a fresh Ubuntu install if you created the key as root and moved it to your user folder.

Step-by-step fix

Fix local key permissions
Run these commands on the client machine (the one you're SSHing from):
```
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa ~/.ssh/id_ed25519 ~/.ssh/authorized_keys 2>/dev/null
```
The 2>/dev/null swallows errors for files that don't exist — not all users have every key type. The 700 on the directory prevents anyone else from listing or writing to it; the 600 on key files makes them owner-read/write only.
Check the key identity
Run
```
ssh -v user@host 2>&1 | grep -i "Offering|identity"
```
This shows exactly which key file SSH is trying. If it's the wrong one, you'll see something like Offering public key: /home/you/.ssh/some_other_key. Fix by specifying the correct key with -i /path/to/correct_key or edit ~/.ssh/config (see below).
Fix server-side permissions (if you can still log in via other method)
If you have password or console access to the server, fix the remote ~/.ssh:
```
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys ~/.ssh/id_rsa.pub
```
Then double-check that the public key in authorized_keys matches your private key. Run ssh-keygen -lf ~/.ssh/id_rsa.pub on client and ssh-keygen -lf ~/.ssh/authorized_keys on server — the fingerprints must match.
Test connection
```
ssh -v user@host 2>&1 | tail -20
```
Look for Authentication succeeded. If you still see Permission denied (publickey), go to alternative fixes below.

Alternative fixes

Wrong key file being offered

Sometimes SSH tries the default key (id_rsa) but you need a different one. Create or edit ~/.ssh/config with this block:

Host myserver
    HostName 192.168.1.100
    User myuser
    IdentityFile ~/.ssh/my_custom_key

Then just run ssh myserver. The IdentityFile directive forces SSH to use that key. This is cleaner than remembering -i flags.

Server's known_hosts mismatch

If you rebuilt a server and its host key changed, SSH will silently fail with Permission denied instead of the usual warning. Fix by removing the old host key:

ssh-keygen -R hostname_or_ip

Then reconnect.

Agent forwarding issues

If you're hopping through a bastion host and the agent isn't forwarded, your keys won't be available. On the bastion, verify with ssh-add -l. If it shows The agent has no identities, you need to either forward the agent (ssh -A) or copy your key to the bastion temporarily (bad practice — don't do it).

Prevention tip

Never copy SSH keys with cp or scp and assume permissions are correct. Always run chmod 600 ~/.ssh/id_* && chmod 700 ~/.ssh after any key transfer. A one-liner you can alias: alias sshfix='chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_* ~/.ssh/authorized_keys 2>/dev/null'. Run it before every SSH session for the next week — you'll build the muscle memory.