PuTTY "Server Refused Our Key" on EC2: Convert and Fix

If PuTTY says "Server refused our key" or "No supported authentication methods available (server sent: publickey)" when you try to reach an EC2 instance, the cause is almost never a broken key. It is usually one of three things: you typed the wrong username for your AMI, you loaded the raw .pem file into PuTTY instead of a properly converted .ppk, or the key pair you are using was never the one baked into that specific instance in the first place. And that last one hides the counterintuitive part: changing or "rotating" your key pair in the EC2 console does nothing to a running instance's actual access list, because the public key only ever gets written to authorized_keys once, at first boot.

What "Server Refused Our Key" Actually Means

Jake had a laptop on his repair bench that needed a firmware file sitting on a company EC2 box, and a customer standing at the counter waiting for it. He'd connected to that same instance a dozen times before. This time PuTTY threw up a window that just said "Server refused our key" and closed the session before he'd typed a single command.

The phrase sounds like it's describing a bad key — something corrupted, or the wrong file. What it's actually describing is a failed SSH authentication handshake: PuTTY offered the server a public key, and the server checked that key against the ones listed in ~/.ssh/authorized_keys for the username you supplied, and found no match. That's the whole error. It says nothing about why there was no match, and there are several very different reasons that all produce the identical message.

The near-identical message, No supported authentication methods available (server sent: publickey), means the same thing from a slightly different angle: the server has told PuTTY "the only login method I'll accept is a public key," and every key PuTTY tried failed to match one. Same root cause, same fixes, and the two errors are treated as one problem for the rest of this article — which is also how AWS documents them.

Ethan's take on this one is blunt: "People treat 'refused our key' like a diagnosis. It's a symptom. Nine times out of ten it's the username or the conversion, and people spend twenty minutes regenerating keys before they check either one."

Fix 1: Convert Your .pem to a Real .ppk File

AWS hands you a .pem file when you create a key pair. PuTTY doesn't read that format natively — it needs its own .ppk (PuTTY Private Key) format. If you've ever pointed PuTTY straight at a .pem file, it either refused to load it or, worse, loaded something that looks like a key but isn't the one your instance trusts. The conversion tool is called PuTTYgen and it ships in the same installer as PuTTY itself.

The single most common mistake here has nothing to do with the file format and everything to do with one button. PuTTYgen has a Generate button that creates a brand-new key pair from scratch, and a Load button that imports an existing one. People who are in a hurry sometimes click Generate out of habit, produce a perfectly valid key that has never been near their EC2 instance, save it, and then wonder why the server refuses it. It isn't refusing a bad key — it's refusing a key it has genuinely never seen.

1. Open PuTTYgen (Start menu > PuTTY > PuTTYgen).
2. Under "Type of key to generate," leave RSA selected (or "SSH-2 RSA" on older versions) — this must match the type of the key pair AWS created for you.
3. Click Load, not Generate. PuTTYgen only shows .ppk files by default, so switch the file filter to "All Files" to see your .pem.
4. Select your .pem file and open it. PuTTYgen will show a message confirming the import succeeded.
5. Click Save private key. You'll get a warning about saving without a passphrase — choosing Yes is fine for most personal use, though a passphrase adds protection if the file is ever exposed.
6. Give it the same name as your key pair and save. PuTTY adds the .ppk extension automatically.

That's the whole conversion. There's no intermediate step, no re-keying, nothing else to configure. If PuTTYgen's import step itself fails with an error rather than producing "Server refused our key" later, that's a different problem covered in the FAQ below.

Fix 2: Use the Right Username for Your AMI

The username goes in the Host Name field in PuTTY, formatted as username@public-dns-name, not in a separate box most people expect. This is the second-most common cause of this exact error, because the default login user is different for every Linux distribution AWS ships, and it isn't "root" for any of them by default.

If you created a separate login user of your own on the instance instead of using the default, use that username instead — the table above only covers the account that already existed the moment the instance booted. That distinction matters more than it sounds, and it's the subject of one of the edge cases below.

Fix 3: Confirm You're on a Current PuTTY, and Watch the PPK Version

PuTTY's own project page lists 0.85, released August 16, 2026, as the current release. AWS's PuTTY setup guide still lists ".78" as its last-tested version, which is old enough that it can mislead people into thinking any recent PuTTY is untested territory — it isn't; PuTTY has stayed backward compatible with EC2 through all of its releases since then.

Beyond compatibility, running a current PuTTY matters for a second reason that has nothing to do with this specific error: two of the security fixes in 0.85 close remotely triggerable memory bugs. There's no cost to upgrading and no downside, so if you're troubleshooting a connection problem anyway, it's worth ruling out as a variable early rather than discovering it three fixes later.

Fix 4: Rule Out the Network Before You Blame the Key

This one trips people up because it seems unrelated — a network rule wouldn't produce an authentication error, would it? Usually not directly, but there's a common variant: if your security group is blocking the connection outright, you'd normally see "Connection timed out" rather than "Server refused our key." If you're seeing a mix of both errors depending on the day, or the connection sometimes hangs and sometimes refuses instantly, it's worth eliminating the network layer as a variable before you spend more time on the key.

1. Open the EC2 console, choose Instances, and select the instance.
2. On the Security tab, under Inbound rules, confirm there's a rule allowing traffic on port 22 from your current IP address.
3. If your IP address changes often (mobile connection, home ISP without a static IP, corporate network), check whether the rule still matches — a rule scoped to a single IP silently stops working the moment that IP changes.

Two things sit just underneath the security group check that are easy to overlook. First, security groups are stateful and permissive-by-addition only — if there's a network ACL on the subnet as well, that's a separate, statement-based layer, and it can block inbound port 22 even when the security group looks correctly configured. Second, if you're going through a bastion or jump host rather than connecting directly, the security group on the target instance needs to allow SSH from the bastion's private IP address, not from yours — your own IP never touches that instance directly, so whitelisting it there does nothing.

Fix 5: When It's a Permissions Problem on the Instance Itself

If you were connecting to this exact instance successfully as recently as last week, and the username and key are both confirmed correct, the cause shifts from "something you're doing wrong locally" to "something changed on the instance." SSH is strict about file permissions on the server side: it will silently refuse to trust an authorized_keys file, or the .ssh directory containing it, if the permissions are too loose or the ownership is wrong. This can happen after a system update, a botched chmod -R, or someone else on the team touching the home directory.

The same underlying issue can also come from the reverse direction, on your own machine: if you're connecting from a Linux subsystem or a non-Windows client instead of PuTTY, and your local .pem file itself is world-readable, OpenSSH will refuse to use it and print a loud warning about an unprotected private key. PuTTY doesn't enforce this the same way OpenSSH does, but it's worth knowing the symptom looks similar if you ever switch tools mid-project.

Edge Cases: Bastions, Private Subnets, and Multi-User Boxes

The five fixes above cover the straightforward case: one person, one key, one instance reachable directly from your desk. Three more common setups produce this same error for reasons that aren't obvious from the message itself.

Bastion or jump host in the middle

If you SSH into a public bastion and then try to SSH again from there into a private instance, the private instance will refuse your key unless it's actually present where you're connecting from — and your key almost certainly isn't sitting on the bastion, nor should it be; leaving a private key on a shared jump box is a real security risk. The fix is agent forwarding: load your .ppk into Pageant (PuTTY's key agent, installed alongside PuTTY), then in PuTTY's session settings go to Connection > SSH > Auth and enable both "Attempt authentication using Pageant" and "Allow agent forwarding." With that in place, the bastion relays authentication requests back to Pageant on your own machine, so the private instance can verify your key without the key ever being copied onto the bastion.

Instances with no public IP address

If the instance lives in a private subnet with no public IPv4 or IPv6 address at all, PuTTY has nothing to connect to directly, bastion or not — this usually shows up as a timeout rather than "Server refused our key," but it's worth naming here because people sometimes misdiagnose it as a key problem after ruling everything else out. AWS's own fix for this exact situation is EC2 Instance Connect Endpoint, which creates a private tunnel into the VPC so you can reach an instance by its private IP address without a bastion host or a public IP on the instance itself. It's a network-layer fix, not a key-layer one, but it's the right next step once you've genuinely exhausted the key and username checks above.

Multiple people, one key pair

A key pair created for one user doesn't automatically extend to accounts created later on the same instance. If a teammate creates themselves a new Linux user account on the box, that new account gets its own empty ~/.ssh/authorized_keys — nobody's public key is in it until someone puts it there by hand. If that teammate then tries to connect with the original team key pair under their own new username, they'll get "Server refused our key" even though the exact same key works perfectly for the original ec2-user or ubuntu account. The fix is to append the public key (the .pub half, not the private one) to that specific user's authorized_keys file, from an account that already has access.

Not the Same Error: "Couldn't Agree a Key Exchange Algorithm"

It's worth naming this one explicitly because people searching "PuTTY couldn't agree a key" often land here expecting the same fix, and it isn't. "Server refused our key" is an authentication failure — PuTTY and the server agreed on how to talk, but your credentials didn't check out. "Couldn't agree a key exchange algorithm" happens earlier and is a compatibility failure: PuTTY and the server can't even agree on the cryptographic method to set up the encrypted channel in the first place, before authentication is ever attempted.

That error is caused almost entirely by an outdated PuTTY talking to a server that has dropped support for older, weaker key exchange methods for security reasons. The fix is the PuTTY upgrade covered above — it has nothing to do with your key file, your username, or your security group.

When the Key Pair Itself Is the Wrong One

Here's the part almost nobody checks first, because it feels like it shouldn't need checking: the EC2 console lets you rename, replace, or delete key pairs at the account level, and none of that touches a running instance. A key pair only ever gets written into an instance's authorized_keys once, during the first boot, through the instance's user data. If you deleted the original key pair after launch and created a new one with the same name, or you're simply using the wrong .ppk file for this particular instance, the server will refuse it forever — correctly, because it genuinely never had that key.

To confirm which key pair an instance actually expects, open the EC2 console, select the instance, and check the Key pair name field on the Details tab. If that name doesn't match the .ppk file you're loading in PuTTY, you've found the problem, and no amount of reconverting or re-typing usernames will fix it.

This procedure only applies to EBS-backed root volumes. Instance-store-backed instances have no equivalent recovery path; if the key is gone, so is your ability to log in, and the volume's contents go with it if the instance ever stops.

1. Create a new key pair (EC2 console or a third-party tool), and note its .pub public key contents.
2. Stop the original instance, and from its Storage tab note the root volume's ID and device name (for example /dev/xvda).
3. Launch a temporary instance in the same Availability Zone, using the same or a similar AMI.
4. Detach the original instance's root volume, then attach it to the temporary instance as a secondary volume (this gives it a different device name, such as /dev/sdf).
5. Connect to the temporary instance, mount the attached volume to a temporary mount point, and copy your new public key into the mounted volume's authorized_keys file for the correct username, fixing ownership and permissions to match the original account.
6. Unmount, detach the volume from the temporary instance, and reattach it to the original instance at its original device name.
7. Start the original instance and connect using the new key pair's private key.

Every step above is standard console work — nothing here requires the private key you lost, which is the entire point of the procedure. Terminate the temporary instance once you're back in if you have no further use for it.

A Faster Fallback While You Sort the Key Out

Ethan's advice for anyone mid-crisis: "Don't burn an hour rebuilding a PPK file while a customer's waiting. Get into the box a different way first, fix the real problem calmly from inside, then come back and sort out PuTTY." If the instance has a public IP and its security group allows it, EC2 Instance Connect gives you a browser-based terminal straight from the EC2 console — it pushes a short-lived key to the instance metadata for that one session, sidestepping the PuTTY conversion question entirely. If the instance sits in a private subnet, EC2 Instance Connect Endpoint extends that same convenience without needing a public IP at all. And if the AWS Systems Manager SSM Agent is installed and the instance has the right IAM role, Session Manager goes further still: no open port 22, no key file at all, and a fully IAM-authenticated shell.

Neither of these is a permanent replacement for PuTTY if that's your normal workflow, but both are faster ways to confirm whether the problem really is the key, or something else entirely, without repeatedly guessing through PuTTY's dialog boxes.

Frequently Asked Questions

What does "Server refused our key" actually mean?

It means the SSH server checked your public key against the ones listed for the username you supplied, in ~/.ssh/authorized_keys, and found no match. It says nothing about why — the wrong username, an unconverted key file, or the wrong key pair entirely all produce this identical message.

Why does PuTTY say "No supported authentication methods available (server sent: publickey)"?

This is the same underlying failure from a slightly different angle: the server only accepts public-key authentication for this instance, and every key PuTTY offered failed to match. Treat it identically to "Server refused our key."

How do I convert a .pem file to .ppk?

Open PuTTYgen, click Load (switch the file filter to All Files to see the .pem), select your .pem file, then click Save private key. Never click Generate for this — that creates an unrelated new key.

Why did PuTTYgen create a completely different key than my .pem?

Because Generate was clicked instead of Load. Generate always produces a fresh, unrelated key pair regardless of any file you had open. Start over using Load.

What username do I use to connect to my EC2 instance?

It depends on the AMI: ec2-user for Amazon Linux, ubuntu for Ubuntu, admin for Debian, and so on — see the full table above. Enter it as username@public-dns-name in PuTTY's Host Name field.

My key worked before — why does it not work now?

Check instance-side permissions on ~/.ssh/authorized_keys and its parent directories first, since those can change after an update or a careless chmod. If you can rule that out, confirm the key pair name shown on the instance's Details tab still matches the .ppk you're loading.

Can I use the same .pem file directly in PuTTY without converting it?

No. PuTTY doesn't read the PEM format natively. You must convert it to .ppk with PuTTYgen first, using Load then Save private key.

What's the difference between "Server refused our key" and "Couldn't agree a key exchange algorithm"?

They happen at different stages. "Couldn't agree a key exchange algorithm" fails before authentication even starts, because PuTTY and the server can't agree on an encryption method — almost always fixed by upgrading PuTTY. "Server refused our key" happens after that stage succeeds, when your specific credentials don't check out.

Should I generate a new key pair in PuTTYgen instead of loading mine?

No, not as a first move. A newly generated key has never been placed on your instance, so it will always be refused. Generating a new key pair is only useful if you're deliberately setting up new access from inside the instance, using another connection method first.

What if I don't know which AMI my instance uses?

Check the instance's Details tab in the EC2 console for the AMI name or ID, or check the AMI listing itself if it's a third-party or Marketplace image — the provider's page will usually state the default login user.

Why does PuTTY say "Couldn't load private key" or "unable to use key file"?

This is a different error from "Server refused our key" and happens before you even try to connect — it means PuTTY can't parse the key file at all, often because it's an OpenSSH-format key that was never converted, or because it's a newer PPK v3 file being opened by a very old PuTTY build. Reconvert with a current PuTTYgen, or upgrade PuTTY.

Can I connect without a private key at all?

Yes, if the SSM Agent is installed on the instance and it has the right IAM role, AWS Systems Manager Session Manager gives you a fully authenticated shell with no key file and no open port 22. EC2 Instance Connect, and EC2 Instance Connect Endpoint for private subnets, offer similar keyless options.

What if I've completely lost my private key?

For an EBS-backed instance, you can regain access by stopping it, detaching the root volume to a temporary instance, adding a new public key to the mounted volume's authorized_keys file, then reattaching and restarting the original instance — see the full numbered procedure above. Instance-store-backed instances have no equivalent recovery path.

Does a passphrase on my key cause "Server refused our key"?

No. A passphrase protects the private key file locally and is checked by PuTTY before it even attempts the connection; it plays no part in whether the server accepts the public key. Entering the wrong passphrase just fails to unlock the key file, which looks and feels different from a refusal at connect time.

My security group allows SSH — could that still be the problem?

If the rule is scoped to a specific IP address and your IP has changed since you last connected, the rule silently stops matching. If you're going through a bastion, the target instance's security group must allow SSH from the bastion's private IP, not yours. This usually produces a timeout rather than "Server refused our key," but it's worth ruling out if your symptoms are inconsistent.

How do I fix permissions on ~/.ssh/authorized_keys if I already have access another way?

Once connected via Session Manager, the serial console, or a temporary instance with the volume attached, set the home directory and .ssh directory to permission 700 and authorized_keys to 600, and make sure the login user — not root — owns all three.

Revision note. Written August 2026, covering current PuTTY (0.85) and PuTTYgen on Windows connecting to Amazon Linux, Ubuntu, Debian, and other common EC2 AMIs, including bastion, private-subnet, and multi-user setups. This will need a fresh look whenever PuTTY changes its PPK format again or AWS updates its default usernames for a new AMI family. If you're staring at this error with a customer waiting or a deadline closing in, the fix is almost always smaller than it feels right now — work through it in order and you'll likely be back in within a few minutes.