SSH "Permission denied (publickey)": How to Fix It

Permission denied (publickey) means the SSH server was reached and talked to you, but none of the keys your client offered were accepted, and the server allows no other login method. The connection itself is fine. This separates it from a timeout or a refused connection.

You may see the longer form Permission denied (publickey,gssapi-keyex,gssapi-with-mic) or, on Git hosts, git@github.com: Permission denied (publickey). The list in brackets is simply the methods the server would accept.

Step 1: read the verbose output

Run the client in verbose mode. It tells you exactly which keys were tried.

ssh -vvv deploy@203.0.113.10

Look for lines like these:

debug1: Offering public key: /home/me/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

If the output never says "Offering public key", the client found no usable key. If it offers a key and the server rejects it, the server side is the issue. Both paths are below.

Step 2: check you are offering the right key

• List agent keys with ssh-add -l. If it says "The agent has no identities", load one with ssh-add ~/.ssh/id_ed25519.
• Name the key explicitly: ssh -i ~/.ssh/mykey -o IdentitiesOnly=yes deploy@host. IdentitiesOnly=yes stops the client trying many agent keys first, which can hit the server's attempt limit (MaxAuthTries, default 6) before your real key is tried.
• Set a per-host entry in ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

• Confirm the public key you installed matches the private key: ssh-keygen -y -f ~/.ssh/id_ed25519 prints the public key derived from the private one.

Step 3: check the username

The most common silent mistake. Cloud images use different default users (for example ubuntu, ec2-user, admin, debian, root). Use the account named in your provider's documentation or console. Git hosts expect git, not your own username.

Step 4: fix authorized_keys and permissions on the server

If you can still log in another way (console, another user), check the target account:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER":"$USER" ~/.ssh

With the default StrictModes yes, sshd refuses keys if the home directory, .ssh, or authorized_keys are writable by other users or owned by the wrong account. The server's log says so plainly:

sudo journalctl -u ssh -n 50          # Debian/Ubuntu; use -u sshd on RHEL-family
sudo tail -n 50 /var/log/auth.log     # or /var/log/secure

Typical entries are Authentication refused: bad ownership or modes for directory /home/deploy and User deploy not allowed because not listed in AllowUsers.

Also make sure the key was pasted as a single line with no stray line breaks. On systems using SELinux, restore contexts with restorecon -R -v ~/.ssh.

Step 5: check sshd_config

sudo sshd -T | grep -Ei "pubkeyauthentication|passwordauthentication|permitrootlogin|allowusers|allowgroups|authorizedkeysfile"

Confirm pubkeyauthentication yes, that your user is not excluded by AllowUsers or AllowGroups, and that AuthorizedKeysFile points where you put the key. Remote root login is commonly set to prohibit-password, meaning keys only. After edits, validate with sudo sshd -t and reload the service.

Step 6: old key types and algorithms

Recent OpenSSH releases disabled the ssh-rsa signature algorithm using SHA-1 by default, beginning with OpenSSH 8.8. An RSA key itself still works with stronger signatures, but very old clients or servers may fail to negotiate. Prefer ed25519 keys (ssh-keygen -t ed25519 -C "you@example.com"), or update the old software. Check the release notes for your version before re-enabling a legacy algorithm.

Cloud and Git specifics

• Cloud instances: a key pair chosen at launch is the only one installed. Losing it usually means using a provider recovery method or attaching the disk to another instance. Check the provider's current docs.
• GitHub, GitLab and similar: add your public key in the account settings, and test with ssh -T git@github.com. If you use a deploy key, it is tied to one repository.
• CI runners: make sure the private key is stored as a secret with real line breaks and a trailing newline.

Next steps

• Handle host key verification failed when reconnecting to a rebuilt host.
• Diagnose SSH connection timed out.
• Test reachability with the Port Checker.
• Read why is my website down for wider troubleshooting.

FAQ

Is Permission denied (publickey) a firewall problem?

No. The server answered, so the network path works. The failure is about authentication: the wrong key, wrong user or wrong permissions.

Why does it work for root but not my user?

Your user's ~/.ssh/authorized_keys may be missing, have wrong ownership or modes, or the user may be blocked by AllowUsers. Compare the two accounts' files and the auth log.

Do I need to restart sshd after adding a key?

No. authorized_keys is read at each login. You only reload sshd after changing sshd_config.

Should I enable password login to get in?

Only briefly and with care. A temporary password login can help recovery, but turn it off again afterward.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.