Permission denied (publickey)

Fix 'Permission denied' (SSH public key) in Linux

EP
Erropedia Team
📅 May 27, 2026 📅 Updated Jul 31, 2026 👁 15 views Linux & Unix Intermediate
SSH rejects your key because of wrong file permissions, wrong key format, or SSH config issues. We'll fix it in 3 stages from quick to deep.

The 30-second fix: Check file permissions

SSH is paranoid about permissions. If your ~/.ssh folder or authorized_keys file is readable by anyone else, SSH straight up ignores your key. No error beyond that cryptic message. Here's what to do right now:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~ (your home directory must not be group-writable or world-writable)

Then try connecting again. If that did it, you're done. 80% of the time this is the culprit.

Why this matters

SSH runs a strict permissions check before it even considers using your key. If .ssh is 755 or authorized_keys is 644, SSH says nope. The reason is security: if another user on the box can write to your key file, they can inject their own public key and own your account. So SSH refuses to play.

The 5-minute fix: Key format and ssh-copy-id

If permissions are correct and it's still failing, the issue is usually that you manually pasted your public key into authorized_keys but screwed up the format. The key must be one single line starting with ssh-rsa, ssh-ed25519, or similar. No line breaks, no extra spaces at the end, no trailing newline that breaks parsing.

Don't manually edit that file unless you know what you're doing. Use ssh-copy-id instead:

ssh-copy-id user@server

This command reads your public key from ~/.ssh/id_rsa.pub (or whatever default key you have), appends it to the remote ~/.ssh/authorized_keys, and sets the right permissions automatically. It's one command, it works.

If you still get the error, check if the remote server has PermitRootLogin prohibit-password in /etc/ssh/sshd_config. If you're logging in as root, that setting blocks key-only auth unless you have PermitRootLogin yes or without-password. Edit the file, change it, then systemctl restart sshd.

A common gotcha: key type mismatch

If you generated an Ed25519 key but the remote server runs an old SSH version that doesn't support it, the key gets silently ignored. Check your client's key type with ssh-keygen -l -f ~/.ssh/id_ed25519.pub and make sure the server's SSH version supports it. If unsure, generate an RSA key: ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa.

The 15+ minute fix: Debug mode and deeper issues

When nothing above works, go to war with verbose mode. SSH has a debug flag that tells you exactly where it's failing:

ssh -vvv user@server

Look for lines like:

  • debug1: Authentications that can continue: publickey — good, it's trying keys.
  • debug1: Offering public key: /home/you/.ssh/id_rsa — it's offering your key.
  • debug1: Authentication refused: bad permissions — permission problem we already fixed? Maybe not on the server's end.
  • debug1: Trying private key: /home/you/.ssh/id_rsa but then debug1: Authentication refused: bad ownership or modes — the remote authorized_keys has wrong perms. Re-run the chmod commands on the server.

If you see debug1: Authentications that can continue: publickey,password and never a key offer, SSH isn't finding your key. Either you didn't specify the key (ssh -i /path/to/key user@server) or the key's private part has wrong permissions. Fix: chmod 600 ~/.ssh/id_rsa.

SELinux — the hidden blocker

If you're on RHEL, CentOS 7+, or Fedora, SELinux might be blocking SSH from reading authorized_keys even if file perms are correct. Check with:

ls -Z ~/.ssh/authorized_keys
system_u:object_r:ssh_home_t:s0

If the context shows admin_home_t instead of ssh_home_t, restore it:

restorecon -R -v ~/.ssh

Don't disable SELinux. That's lazy. Just fix the context.

Home directory on NFS? That's your problem

If the remote server mounts home directories via NFS, SSH by default won't trust authorized_keys because NFS doesn't enforce Unix permissions the way a local filesystem does. You'll see this in debug output as a refused key with no obvious permission issue. Fix: set StrictModes no in /etc/ssh/sshd_config. Only use this as a last resort — it loosens security. Better to move key authentication to a local path using AuthorizedKeysFile in sshd_config.

Still stuck? Check the SSH daemon config

Sometimes the server's sshd_config has PubkeyAuthentication no or AuthorizedKeysFile /dev/null. Check it:

grep -E '^(PubkeyAuthentication|AuthorizedKeysFile)' /etc/ssh/sshd_config

If PubkeyAuthentication is set to no, change it to yes. If AuthorizedKeysFile points somewhere weird, change it to .ssh/authorized_keys. Restart sshd after changes.

Summary checklist

  1. Fix perms: chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys
  2. Use ssh-copy-id instead of manual key pasting
  3. Run ssh -vvv to see where it's dying
  4. Check SELinux context on the remote
  5. Verify sshd_config isn't blocking key auth

That covers 99% of cases. If you're still locked out, your key might have been revoked or the server's firewall is blocking port 22 entirely — but that's a different error message. For this one, the fix is almost always permissions or format.

Related Errors in Linux & Unix
Fix wrong login screen resolution on Ubuntu 22.04/24.04 EXT4-fs error (device sda1): ext4_find_entry: bad entry Fixing a corrupt EXT4 superblock on Linux Permission denied Linux 'Permission Denied' Error: 3 Quick Fixes Permission Denied Flatpak 'Permission Denied' Install Fix on Linux
SSH permission denied publickey error fix Linux SSH troubleshooting chmod 600 .ssh/authorized_keys SSH key permissions sshd_config settings authorized_keys file permissions home directory permissions .ssh directory permissions SELinux SSH context SSH debug mode key format error ssh-copy-id not working Linux remote access fix SSH authentication failure

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.