Permission Denied (publickey) in SSH: Real Fix for Linux

Quick answer

Run chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys on the server, then on your local machine run ssh-add ~/.ssh/id_ed25519 and connect with ssh -v to see what's happening.

Why this happens

You're not alone—this error trips up everyone eventually. SSH is picky about file permissions because it won't trust keys that are accessible by other users. If your ~/.ssh folder or authorized_keys file has loose permissions, the server silently ignores your key. Another common cause: you're using the wrong key, or the key isn't loaded into your SSH agent.

I hit this last week on a fresh Ubuntu 22.04 server. My key was correct, but I'd copied it with the wrong permissions from a backup, and SSH just said Permission denied (publickey) without any hint.

Fix it in 5 steps

1. check server-side permissions—log in with a password (if you can) or use a console, then run:

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys
   chmod 644 ~/.ssh/id_ed25519.pub

   Yes, the public key is 644, but the private key and authorized_keys are 600. This is non-negotiable.
2. verify the key is actually in authorized_keys—run cat ~/.ssh/authorized_keys and compare it to your local ~/.ssh/id_ed25519.pub. A single extra space or missing newline can break it.
3. check your local private key—on your machine, run ls -la ~/.ssh/id_*. If the private key has permissions other than 600, fix it: chmod 600 ~/.ssh/id_ed25519.
4. load the key into ssh-agent—even if your key is fine, the agent might not have it. Run:

   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_ed25519

   If you get 'Identity added', you're set.
5. connect with verbose output—ssh -v user@host. Look for lines like 'Offering public key' and 'Authentications that can continue'. If you see 'No more authentication methods to try', you've got the fix wrong. Also check for 'Server accepts key'—that means your key worked, so the issue is elsewhere (like account settings).

If it still fails

Try these alternatives.

• check sshd_config on the server—make sure PubkeyAuthentication is set to yes. I've seen hosts disable it accidentally. Restart sshd after changes: sudo systemctl restart sshd.
• check SELinux on RHEL 9—if you're on CentOS or RHEL, SELinux might block access. Restore contexts with restorecon -Rv ~/.ssh. Yes, even with correct permissions, SELinux can reject.
• use a different key type—if you're still on RSA 2048, generate an Ed25519 key: ssh-keygen -t ed25519 and add the new public key to the server. Ed25519 is faster and less likely to be rejected by modern servers.

Prevention tip

Always run ssh-copy-id user@host instead of manually copying keys. That command sets the right permissions automatically. And a habit worth stealing: after you create a new key, immediately add it to your agent. I've got a shell alias for that. If you're managing multiple servers, a tool like ssh-keygen -R hostname to clear old host keys can also prevent weird mismatches.