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

"Permission denied (publickey)" means the server refused every key your client offered. The key is almost never "broken" — it's usually a wrong user, a wrong key, or wrong file permissions. Work through this list top to bottom.

1. Get the real reason first

Run the client in verbose mode and read what it tries:

ssh -vvv [email protected]

Look for lines like Offering public key: ... and Authentications that can continue: publickey. If you see no Offering public key line, your client isn't offering any key at all (see step 3).

If you have access to the server (console, another admin session), watch the log while you connect:

sudo journalctl -u ssh -f          # Ubuntu / Debian
sudo tail -f /var/log/secure       # RHEL / Rocky / Alma

The server log usually says exactly why: Authentication refused: bad ownership or modes for directory /home/user, User not allowed, no matching host key type, and so on.

2. Are you using the right user name?

Cloud images use different default users: ubuntu, admin, ec2-user, debian, root. Connecting as the wrong user gives the same error as a wrong key.

ssh -i ~/.ssh/id_ed25519 [email protected]

3. Is the right key being offered?

ssh-add -l                  # keys loaded in your agent
ls -l ~/.ssh/               # keys on disk

Point to the key explicitly, and stop the client from trying every key it knows (this also fixes "Too many authentication failures"):

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

Make it permanent in ~/.ssh/config:

Host myserver
    HostName server.example.com
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

4. Is your public key on the server?

The public key must be a line in ~/.ssh/authorized_keys of the target user. The easiest way to add it:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

No key yet? Create a modern one:

ssh-keygen -t ed25519 -C "my-laptop"

If password login is disabled and you're locked out, use the provider's web console to paste the key into authorized_keys by hand. It must be one single line.

5. Fix permissions (very common)

OpenSSH silently ignores keys if the files are too open. On the server, as the target user:

chmod 755 ~                   # home must NOT be group/world-writable
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER": ~/.ssh

On your client, the private key must be private:

chmod 600 ~/.ssh/id_ed25519

On SELinux systems (RHEL family) also run restorecon -Rv ~/.ssh.

6. Check what the server actually allows

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

• pubkeyauthentication yes must be set.
• permitrootlogin no means root@ will always fail, use a normal user plus sudo.
• If allowusers / allowgroups is set, your user must be listed.

After editing the config, test and reload (keep your current session open!):

sudo sshd -t && sudo systemctl reload ssh

7. Old RSA keys on new servers

OpenSSH 8.8+ disabled the legacy ssh-rsa (SHA-1) signature. RSA keys still work through rsa-sha2-256/512, but very old clients or servers may not negotiate it. The clean fix is to switch to an ed25519 key. Only as a temporary workaround:

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa user@oldserver

Quick checklist