PuTTY Server Refused Our Key: How to Fix It

What you're seeing

PuTTY prints this in the terminal window right after you enter the username:

Using username "deploy".
Server refused our key
[email protected]'s password:

If the server still allows passwords, PuTTY falls back to a password prompt on the next line. If it doesn't, you get a fatal dialog instead: Disconnected: No supported authentication methods available (server sent: publickey). That's the same key problem one step later; this page fixes both, and that error has its own page if you have no key set up at all.

A rarer variant, Server refused public key signature despite accepting key, means the server matched your key but the signature PuTTY produced failed to verify. See the edge case table below.

If you hit the same rejection from the OpenSSH command line, it renders as Permission denied (publickey); see SSH Permission Denied (publickey) for the client-agnostic walkthrough.

What's causing this error

The server compared the key PuTTY offered against every line of the target user's ~/.ssh/authorized_keys and found no acceptable match. The real causes, in rough order of frequency:

1. The public key was pasted in the wrong format. PuTTYgen's "Save public key" button writes a multi-line ---- BEGIN SSH2 PUBLIC KEY ---- block. sshd cannot read that format in authorized_keys. This is by far the most common cause.
2. The key isn't in authorized_keys at all, or it's in the wrong user's home directory.
3. Wrong username in the session. The key is under /home/deploy/.ssh/ but you're logging in as root, so sshd checks /root/.ssh/authorized_keys and finds nothing.
4. Server-side permissions are too loose. sshd silently ignores authorized_keys if ~/.ssh isn't 700, the file isn't 600, they're owned by the wrong user, or the home directory is group- or world-writable.
5. PuTTY or Pageant is offering a different key than the one you installed on the server.
6. The server rejects the key type. Very old servers don't understand ssh-ed25519; hardened servers can restrict types via PubkeyAcceptedAlgorithms.

How to fix it

Step 1: Check the format in authorized_keys

Get onto the server (password fallback, another machine, or your provider's web console) and look at the file:

cat ~/.ssh/authorized_keys

This is wrong and sshd will never match it:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20260822"
AAAAB3NzaC1yc2EAAAADAQABAAABAQC7vbqajDhA...
---- END SSH2 PUBLIC KEY ----

This is right, one unbroken line per key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7vbqajDhA... rsa-key-20260822

The correct text comes from the large box at the top of PuTTYgen labelled "Public key for pasting into OpenSSH authorized_keys file". Load your .ppk into PuTTYgen, copy everything in that box, and replace the bad entry:

nano ~/.ssh/authorized_keys
# paste the one-line key, save, and make sure your editor didn't wrap it

Not sure the line is valid? Paste it into our SSH key validator; it flags format problems, truncation, and inserted line breaks.

Step 2: Confirm PuTTY is offering the right key

The key the server knows about has to be the one PuTTY presents:

• Session key: Connection > SSH > Auth > Credentials (just "Auth" in PuTTY before 0.78) > "Private key file for authentication". Confirm it points at the matching .ppk, then go back to Session and click Save.
• Pageant: right-click the Pageant tray icon > View Keys. PuTTY tries every loaded key in order, so an old key in the list can be offered before the right one. Remove stale keys or add the correct one.

To compare keys, open the .ppk in PuTTYgen and match the fingerprint against ssh-keygen -lf ~/.ssh/authorized_keys on the server. No key pair yet? Generate one in the browser with our PuTTY key generator.

Step 3: Check the username

sshd only reads authorized_keys for the user you're logging in as. Check the username PuTTY sends: the "login as:" prompt, or Connection > Data > "Auto-login username" in the saved session. Cloud images are the classic trap: the key you added at instance creation lands under ubuntu, ec2-user, or opc, not root.

Step 4: Fix server-side permissions

sshd refuses to trust a key file that other users could edit, and it refuses silently. On the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh
chmod g-w,o-w ~        # home dir must not be group/world-writable

Step 5: Read the server's auth log

When the cause still isn't obvious, the server logs the exact reason for every rejected key:

$ sudo journalctl -u ssh -n 50 --no-pager    # Debian/Ubuntu
$ sudo journalctl -u sshd -n 50 --no-pager   # RHEL/CentOS/Fedora
# Or the classic log files:
$ sudo tail -50 /var/log/auth.log            # Debian/Ubuntu
$ sudo tail -50 /var/log/secure              # RHEL/CentOS/Fedora

The two lines worth searching for:

• Authentication refused: bad ownership or modes for directory /home/deploy means step 4 is your problem, and it names the exact path.
• userauth_pubkey: key type ssh-ed25519 not in PubkeyAcceptedAlgorithms means the server rejects the key type; generate an RSA key or widen PubkeyAcceptedAlgorithms in sshd_config.

Common edge cases