Fix SSH "Permission denied (publickey)"

The "Permission denied (publickey)" error means the SSH server would not accept your key, or you offered the wrong one. It is almost always one of a handful of causes — here is how to find which, and fix it.

Cause 1: wrong username

A key installed for one user will not work for another. Cloud images often use a specific default user — for example root, ubuntu, debian or almalinux — not your own name. Try the correct user for your distro.

Cause 2: the key is not on the server (or is the wrong one)

Your public key must be in ~/.ssh/authorized_keys on the server, for the user you log in as. If it is missing, add it (via console access or your host's panel). Make sure your client offers the matching private key:

ssh -i ~/.ssh/id_ed25519 user@your-server-ip

Cause 3: wrong file permissions (very common)

SSH refuses keys if the permissions are too open — this is a security feature. On the server, the .ssh folder and authorized_keys file must be locked down:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

On your local machine, your private key should be chmod 600 too.

Cause 4: keys only, and yours is not working

If password login is disabled (good hardening) and your key fails, you cannot fall back to a password — you must fix the key or use your host's console/recovery to add a working one. This is why you should always test a new key before disabling passwords.

The quick checklist

1. Run ssh -v and read which key is rejected and why.
2. Confirm you are using the correct username for your image.
3. Make sure your public key is in the server's ~/.ssh/authorized_keys.
4. Fix permissions: 700 on .ssh, 600 on authorized_keys.
5. Point to the right private key with -i.

Nine times out of ten this is either the wrong username or too-open permissions on ~/.ssh. Check those two first.

Cause 5: the SSH agent is offering the wrong key (or too many)

If your agent holds several keys, SSH may offer the wrong ones first and get rejected before reaching the right one — which can even trip a "too many authentication failures" cutoff. Force the correct key with -i and IdentitiesOnly=yes, or clean up your agent. See too many authentication failures.

Cause 6: the server rejects your key type or a home-directory permission

Newer OpenSSH releases refuse old key algorithms (like legacy RSA-SHA1) by default, so an older key can be silently declined. A world-writable home directory also makes SSH ignore authorized_keys. Generate a modern ed25519 key, and make sure your home directory isn't group/other writable.

How to prevent SSH key lockouts

• Always keep a working session open when changing SSH or permissions, and test the new key in a second terminal.
• Never disable password login until key login is confirmed working.
• Use a modern ed25519 key and keep private keys at chmod 600.
• Know where your host's VNC/console recovery is before you need it.

Related errors

If SSH refuses the connection entirely rather than rejecting your key, see SSH connection refused. New to SSH? Start with connecting to your server with SSH. For the full lockdown approach, see how to secure a Linux VPS.