{ "slug": "how-to-fix-permission-denied-ssh-key", "title": "How to Fix SSH 'Permission denied (publickey)' Error", "description": "Step-by-step guide to diagnose and fix SSH 'Permission denied (publickey)' errors on Linux, macOS, and Windows using ssh-add, ssh -vvv, and permissions.", "type": "how-to", "toolSlugs": ["ssh", "ssh-agent", "ssh-keygen", "chmod"], "keywords": ["ssh permission denied publickey", "ssh-add", "authorized_keys permissions", "ssh -vvv debug", "ssh key not working", "openssh windows", "ssh agent", "restorecon ssh"], "steps": [ {"name": "Confirm the key is loaded in ssh-agent", "text": "Run ssh-add -l to see loaded identities. If it returns 'The agent has no identities', load your key with ssh-add ~/.ssh/id_ed25519."}, {"name": "Verify the public key is in authorized_keys on the server", "text": "SSH in another way (password, console) and grep your key fingerprint against ~/.ssh/authorized_keys."}, {"name": "Fix file and directory permissions", "text": "Set ~/.ssh to 700, authorized_keys to 600, and private keys to 600. sshd refuses keys stored under world-readable paths."}, {"name": "Check which key is actually being offered", "text": "Run ssh -vvv user@host and look at 'Offering public key' and 'Authentications that can continue' lines to see if the correct key is tried."}, {"name": "Rule out SELinux or AppArmor blocks", "text": "On RHEL/Fedora/CentOS run restorecon -R -v ~/.ssh. Check /var/log/audit/audit.log for AVC denials."}, {"name": "Handle Windows OpenSSH quirks", "text": "On Windows use icacls to lock down the key file, and confirm ssh-agent service is running with Get-Service ssh-agent."} ], "content": "

How to Fix SSH "Permission denied (publickey)" Error

\n

The dreaded Permission denied (publickey) message means the SSH server rejected every authentication method your client offered. It is almost never a network or password problem — the server saw your connection, refused the key, and closed the door. This guide walks through the five checks that resolve virtually every case, with real command output so you know what "good" looks like.

\n\n

1. Is your key loaded in ssh-agent?

\n

Start by asking the agent what it holds:

\n

$ ssh-add -l\nThe agent has no identities.

\n

That empty state is a common cause. Load your private key:

\n

$ ssh-add ~/.ssh/id_ed25519\nEnter passphrase for /home/badshah/.ssh/id_ed25519:\nIdentity added: /home/badshah/.ssh/id_ed25519 (badshah@laptop)

\n

If ssh-add itself fails with Could not open a connection to your authentication agent, start the agent first: eval "$(ssh-agent -s)".

\n\n

2. Does the server actually have your public key?

\n

Get into the server another way (password login, cloud console, or recovery shell) and check:

\n

$ cat ~/.ssh/authorized_keys\nssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... badshah@laptop

\n

Compare the fingerprint of what is on the server with what your client is sending:

\n

$ ssh-keygen -lf ~/.ssh/id_ed25519.pub\n256 SHA256:Xk3q9... badshah@laptop (ED25519)

\n

They must match byte-for-byte. A stray line break in authorized_keys silently invalidates the entry.

\n\n

3. Are the permissions correct?

\n

OpenSSH refuses to use keys that other users can read. On the server:

\n

chmod 700 ~/.ssh\nchmod 600 ~/.ssh/authorized_keys\nchown -R $USER:$USER ~/.ssh

\n

On the client:

\n

chmod 700 ~/.ssh\nchmod 600 ~/.ssh/id_ed25519\nchmod 644 ~/.ssh/id_ed25519.pub

\n

If permissions were wrong, ssh -vvv will have shown lines like Permissions 0644 for '/home/badshah/.ssh/id_ed25519' are too open and this private key will be ignored.

\n\n

4. Is the right key being offered?

\n

Run verbose SSH to watch the negotiation:

\n

$ ssh -vvv [email protected]\ndebug1: Offering public key: /home/badshah/.ssh/id_rsa RSA SHA256:abcd...\ndebug1: Authentications that can continue: publickey\ndebug1: Offering public key: /home/badshah/.ssh/id_ed25519 ED25519 SHA256:Xk3q9...\ndebug1: Server accepts key: /home/badshah/.ssh/id_ed25519 ED25519 SHA256:Xk3q9...

\n

If the client stops after a few keys with Too many authentication failures, pin the exact key and disable identity guessing:

\n

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes [email protected]

\n

Then make it permanent in ~/.ssh/config:

\n

Host example.com\n  IdentityFile ~/.ssh/id_ed25519\n  IdentitiesOnly yes\n  User badshah

\n\n

5. Is SELinux or AppArmor blocking access?

\n

On RHEL, Fedora, Rocky, or AlmaLinux, authorized_keys can have correct Unix permissions but the wrong SELinux label — especially if you copied it in from another location. Fix the labels:

\n

$ restorecon -R -v /home/badshah/.ssh\nRelabeled /home/badshah/.ssh from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:ssh_home_t:s0\nRelabeled /home/badshah/.ssh/authorized_keys from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:ssh_home_t:s0

\n

Check for denials:

\n

ausearch -m AVC -ts recent | grep ssh

\n

On Ubuntu with AppArmor, review /var/log/syslog for apparmor="DENIED" lines mentioning sshd.

\n\n

Windows OpenSSH gotchas

\n

The built-in OpenSSH on Windows 10/11 is strict about ACLs and unforgiving of PowerShell profile clutter. Common fixes:

\n

\n
• Agent not running. Get-Service ssh-agent should show Running. Enable it once: Set-Service ssh-agent -StartupType Automatic; Start-Service ssh-agent.
\n
• Key permissions rejected. Windows uses ACLs, not chmod. Lock the key to your user only:\n

  icacls C:\\Users\\Badshah\\.ssh\\id_ed25519 /inheritance:r\nicacls C:\\Users\\Badshah\\.ssh\\id_ed25519 /grant:r "$($env:USERNAME):(R)"

  \n
\n
• Wrong OpenSSH on PATH. If Git for Windows ships its own ssh.exe ahead of the Windows one, they use different agents and different key stores. Run (Get-Command ssh).Source to confirm which one you are using.
\n
• CRLF in authorized_keys. If you edited the file in Notepad, the line endings may be CRLF and sshd will not match the key. Re-save as LF-only using VS Code or dos2unix.
\n

\n\n

When nothing else works

\n

Ask the server to log the reason. As root on the server:

\n

tail -f /var/log/auth.log     # Debian/Ubuntu\njournalctl -u sshd -f          # systemd distros

\n

You will see messages like Authentication refused: bad ownership or modes for directory /home/badshah or User badshah from 1.2.3.4 not allowed because listed in DenyUsers. Those log lines identify the exact rejection cause and take you straight to the fix.

" }