SSH "Permission denied (publickey)": how to find the real cause

You try to log in with your SSH key and get the shortest error message in Linux:

guest@203.0.113.10: Permission denied (publickey).

(publickey) means the server only accepts key authentication — and none of the keys your client offered was accepted. The message doesn’t say why, on purpose: telling a stranger the reason would help attackers. The reason is written on the server, in the SSH daemon’s log. Start there whenever you can; guessing wastes a lot more time.

TL;DR

ssh -v user@server                                      # client: which keys are offered?
sudo journalctl -u ssh -n 20                            # server log (Ubuntu/Debian)
sudo journalctl -u sshd -n 20                           # server log (RHEL/Rocky/Alma)
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys    # server: the usual permission fix
chmod go-w ~                                            # server: home not writable by others

1. Read what the server says

You need another way into the server — a console from your cloud provider, another user with access, or a session that’s still open. Then read the SSH log:

# Ubuntu / Debian
sudo journalctl -u ssh -n 30
sudo grep sshd /var/log/auth.log | tail -n 20

# RHEL / Rocky / AlmaLinux
sudo journalctl -u sshd -n 30
sudo grep sshd /var/log/secure | tail -n 20

Each section below starts with the log line that points to it.

From the client side, ssh -v (or -vvv for more) shows which keys it tries and how the server answers. Look for Offering public key: … followed by Authentications that can continue: publickey — the server saw the key and refused it.

2. Bad permissions on ~/.ssh

Authentication refused: bad ownership or modes for directory /home/guest/.ssh
Authentication refused: bad ownership or modes for file /home/guest/.ssh/authorized_keys

The most common cause on servers. With the default StrictModes yes, sshd ignores your keys if other users could modify them — a group- or world-writable ~/.ssh, authorized_keys, or even the home directory itself. Check:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

drwxr-x---  6 guest guest 4096 Nov  1 10:00 /home/guest
drwxrwxr-x  2 guest guest 4096 Nov  1 10:00 /home/guest/.ssh
-rw-rw-r--  1 guest guest  102 Nov  1 10:00 /home/guest/.ssh/authorized_keys

Fix it — on the server, as the user who logs in:

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If the files were created by root (for example with sudo), fix the owner too: sudo chown -R guest:guest /home/guest/.ssh. No restart is needed — try logging in again.

3. The server doesn’t have your key

If the log shows nothing about modes, the key the client offers is probably not in authorized_keys. Compare fingerprints:

# on your computer
ssh-keygen -lf ~/.ssh/id_ed25519.pub

# on the server
ssh-keygen -lf ~/.ssh/authorized_keys

If your fingerprint isn’t in the server’s list, add the public key. From your computer, while you still have another way to log in:

ssh-copy-id -i ~/.ssh/id_ed25519.pub guest@203.0.113.10

Or paste the content of id_ed25519.pub as one line at the end of ~/.ssh/authorized_keys on the server — a key broken over several lines doesn’t work.

If you have several keys, tell SSH which one to use, so it doesn’t offer the wrong ones first:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes guest@203.0.113.10

To make it permanent, put IdentityFile and IdentitiesOnly yes in a Host block of your ~/.ssh/config.

4. Your private key is too open (client side)

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/guest/.ssh/id_ed25519' are too open.

This time the client refuses to use your key, so it never reaches the server and you end up with “Permission denied (publickey)”. Private keys must be readable only by you:

chmod 600 ~/.ssh/id_ed25519

5. sshd is configured to refuse it

Check the settings the server is actually using (this includes files in /etc/ssh/sshd_config.d/):

sudo sshd -T | grep -Ei 'pubkeyauthentication|authorizedkeysfile|allowusers|denyusers|permitrootlogin'

Things to look for:

• pubkeyauthentication no — key logins are disabled.
• authorizedkeysfile pointing somewhere unexpected.
• allowusers / denyusers that don’t include your user.
• Logging in as root with permitrootlogin no.

After changing /etc/ssh/sshd_config, check the syntax and reload — keep your current session open until you’ve tested a new login:

sudo sshd -t && sudo systemctl reload ssh     # Ubuntu / Debian
sudo sshd -t && sudo systemctl reload sshd    # RHEL / Rocky / AlmaLinux

6. Simply the wrong user

Cloud images log you in with a default user that’s not root — ubuntu on Ubuntu images, ec2-user on Amazon Linux, others on other distributions. The key is installed for that user only. Check your provider’s documentation for the image, and use ssh ubuntu@server instead of ssh root@server.