[email protected]: Permission denied (publickey).

This message means the server only accepts key-based logins and none of the keys your client offered were accepted. The cause is almost always one of a short list. Work through them in order.

Step 1: see what SSH is doing

Run the client in verbose mode:

ssh -v [email protected]

Look for these lines:

debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:abc…
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
  • No “Offering public key” line → your client isn’t using the key you think. Go to step 2.
  • The key is offered but rejected → the server doesn’t accept it. Go to step 3.

If you can reach the server another way (the provider’s VNC console, or another user), the server log is even more useful:

sudo journalctl -u ssh -n 30      # "sshd" on RHEL-family systems
sudo tail -n 30 /var/log/auth.log # Debian/Ubuntu with rsyslog

It often says exactly what’s wrong, e.g. Authentication refused: bad ownership or modes for directory /home/user/.ssh.

Step 2: client-side problems

Wrong key or no key. Specify it explicitly:

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

If that works, add it to ~/.ssh/config:

Host myvps
    HostName 203.0.113.10
    User user
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Wrong username. Cloud images often use a default user (ubuntu, debian, almalinux) rather than root. The key is installed for that user only.

Private key permissions. OpenSSH ignores keys that others can read:

chmod 600 ~/.ssh/id_ed25519

On Windows, remove other users’ access in the file’s Properties → Security tab.

Too many keys in the agent. If you have many keys loaded, the server may disconnect after five failed attempts (Too many authentication failures) before the right key is tried. Use IdentitiesOnly yes as above.

Key format. Keys from PuTTYgen (.ppk) must be exported to OpenSSH format (PuTTYgen → Conversions → Export OpenSSH key) for the ssh command.

Step 3: server-side problems

Is the public key really in authorized_keys?

cat ~/.ssh/authorized_keys

Compare it with your local ~/.ssh/id_ed25519.pub. Each key must be on one line; copy-pasting from some terminals or web consoles inserts line breaks, which break the key. Compare fingerprints:

ssh-keygen -lf ~/.ssh/id_ed25519.pub          # local
ssh-keygen -lf ~/.ssh/authorized_keys          # server: lists all keys

Permissions and ownership — the most common cause

sshd’s StrictModes refuses keys if the files could be modified by other users:

chmod 755 ~             # home must not be group/world-writable (750 or 700 also fine)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

If you created the files as root for another user, they’re owned by root — the chown fixes that.

sshd configuration

sudo sshd -T | grep -Ei 'pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups|denyusers'
  • pubkeyauthentication yes must be set.
  • authorizedkeysfile should include .ssh/authorized_keys.
  • If AllowUsers or AllowGroups exists, your user must be listed.

Root login

If logging in as root fails while other users work, check PermitRootLogin. no blocks root entirely; prohibit-password allows root with keys. See disabling root SSH login.

SELinux (AlmaLinux, Rocky, Fedora)

If you created ~/.ssh by hand or restored it from a backup, its SELinux labels may be wrong, and sshd can’t read the file even with perfect permissions:

restorecon -Rv ~/.ssh

Key algorithm not accepted

Very old RSA keys signed with SHA-1 (ssh-rsa) are disabled by default since OpenSSH 8.8. If the server log shows userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms, generate a modern key: ssh-keygen -t ed25519. Conversely, a very old server may not understand Ed25519 — then use -t rsa -b 4096.

Step 4: get back in to fix it

If no key works and password login is disabled, you need another way in:

  • Your provider’s VNC console — logs in locally, independent of SSH settings.
  • Another user with working access and sudo.

Once in, add your key correctly:

mkdir -p /home/user/.ssh
echo "ssh-ed25519 AAAA…your key… you@laptop" >> /home/user/.ssh/authorized_keys
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh && chmod 600 /home/user/.ssh/authorized_keys

Quick checklist

  1. ssh -v — is the right key offered?
  2. Correct username?
  3. Local private key chmod 600?
  4. Public key present, on one line, in the right user’s authorized_keys?
  5. ~/.ssh 700, authorized_keys 600, home not group-writable, owned by the user?
  6. sshd -T — pubkey auth on, user allowed, root policy?
  7. SELinux labels (restorecon)?
  8. Key type supported by both ends?

Related: creating SSH keys, SSH connection refused (a different problem — the server isn’t reachable at all), and connecting to your VPS over SSH.

  • SSH
  • Troubleshooting
  • Linux