Fix SSH Permission Denied (publickey) on Ubuntu 22.04

When this error shows up

You're trying to SSH into an Ubuntu 22.04 server using a key pair. You've copied the public key to ~/.ssh/authorized_keys on the server. But when you connect, you get:

ssh -i ~/.ssh/id_rsa user@server
Permission denied (publickey).

You try again with -vvv and see something like:

debug1: Authentications that can continue: publickey
debug3: no such identity: /home/you/.ssh/id_rsa: No such file
 ... or similar file-not-found or perm denied on server side

This usually happens after a fresh Ubuntu 22.04 install, or when you migrate keys from an older system. I've seen it drive people nuts for hours.

Root cause (plain English)

The SSH daemon is picky about file permissions. If ~/.ssh or authorized_keys are readable or writable by anyone other than you, SSH refuses to trust them. The logic is: if someone else could have tampered with the keys, they're not safe. Ubuntu 22.04 also ships with AppArmor enabled, which can block key access if you placed keys in non-standard locations.

So the real culprits are almost always:

.ssh directory permissions too loose (should be 700)
authorized_keys permissions too loose (should be 600)
Parent directory (home folder) owned by wrong user or writable by group/others
AppArmor blocking access (rare but happens when keys are in /tmp or custom paths)

The fix (numbered steps)

SSH into the server using console or password auth (if you can't, use the hosting provider's VNC or rescue mode).

Fix home directory permissions. Run:

sudo chown user:user /home/user
sudo chmod 755 /home/user

Fix .ssh directory.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Verify ownership.
```
ls -la ~/.ssh
```
Should show user user for owner/group. If not: sudo chown -R user:user ~/.ssh

Check SSH config. Open /etc/ssh/sshd_config and confirm these lines are set (not commented out):

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no (optional, but good for security)

Restart SSH service.
```
sudo systemctl restart sshd
```
Test with verbose output.
```
ssh -vvv -i ~/.ssh/id_rsa user@server
```
Look for Accepted key or Authentication succeeded. If you see Permission denied (publickey) again, move to the next section.

If it still fails

Here's what to check next—this is where most online guides stop, but I've seen these edge cases:

AppArmor blocking? Check logs: sudo journalctl -u ssh | grep -i denied. If you see AppArmor messages, disable AppArmor for SSH or add a profile. Quick test: sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.sshd. If it works, you'll need to configure a proper profile.
Key format wrong? Ensure your public key is one line in authorized_keys. No extra spaces, no line breaks. If you copy-pasted from a Windows terminal, stray characters can break it. Regenerate keys with ssh-keygen -t rsa -b 4096 and re-copy.
SELinux (on non-Ubuntu)? Ubuntu doesn't use SELinux by default, but if you enabled it, run restorecon -Rv ~/.ssh.
Multiple keys on client? SSH might try other keys first. Force your specific key: ssh -o IdentitiesOnly=yes -i ~/.ssh/mykey user@server.
FIPS mode on some hardened servers? Check /etc/ssh/sshd_config for FIPSMode or HostKeyAlgorithms. You might need to use stronger keys.

I once spent two hours on this only to find that the user's home directory was on an NFS mount with noexec—SSH won't read authorized_keys from noexec mounts. Check mount options with mount | grep home.

If none of that works, post your ssh -vvv output (sanitized) and I'll help debug. This error is almost always fixable in under 10 minutes once you know where to look.