PuTTY No Supported Authentication Methods Available: How to Fix It

What you're seeing

A "PuTTY Fatal Error" dialog before any password prompt:

Disconnected: No supported authentication methods available
(server sent: publickey)

The list in parentheses is what the server is willing to accept. Common variants:

• (server sent: publickey) means the server is key-only. Password auth is disabled, and PuTTY has no key to offer.
• (server sent: publickey,gssapi-keyex,gssapi-with-mic) is the same situation on RHEL-family servers. The gssapi entries are Kerberos single sign-on and only apply inside a domain; for everyone else this still means "key required".
• (server sent: keyboard-interactive) means the server wants keyboard-interactive (how most Linux servers actually do password prompts) but it's disabled in your PuTTY settings.

This error means PuTTY never got to try a key. If PuTTY offers a key and the server rejects it, you get a different message; see PuTTY Server Refused Our Key.

What's causing this error

During SSH auth negotiation the server advertises the methods it accepts. PuTTY compares that list against what it has (a key file, Pageant, password, keyboard-interactive) and finds zero overlap, so it gives up before trying anything. The real causes, in rough order of frequency:

1. The server is key-only and PuTTY has no key configured. PasswordAuthentication no in sshd_config is the default on AWS EC2, Oracle Cloud, and most hardened servers.
2. The key exists but isn't loaded: the saved session doesn't point at the .ppk, and Pageant isn't running or has no keys.
3. "Attempt keyboard-interactive auth" is unchecked in Connection > SSH > Auth, on a server that only offers keyboard-interactive.
4. Wrong username. Match User blocks or PermitRootLogin prohibit-password can make the server offer fewer methods for that specific user. Logging in as root on a cloud image commonly produces exactly this.
5. The key is in the wrong format. PuTTY silently can't use a .pem or OpenSSH private key; only .ppk counts.

How to fix it

Step 1: Load your private key in PuTTY

• Open the saved session in PuTTY.
• Go to Connection > SSH > Auth > Credentials (just "Auth" in PuTTY before 0.78).
• Under "Private key file for authentication", browse to your .ppk file.
• Go back to Session, click Save, then Open.

If you skip Save, the key setting is gone next time and the error comes back.

PuTTY only reads .ppk files. If what you have is a .pem from AWS or an OpenSSH key (id_ed25519, id_rsa), convert it first with PuTTYgen or our PEM to PPK converter. No key at all yet? Create a pair in the browser with the PuTTY key generator.

Step 2: Or load the key into Pageant

Pageant (installed alongside PuTTY) holds keys in memory and every PuTTY session tries them automatically:

• Start Pageant, right-click its tray icon, choose Add Key, pick the .ppk.
• In the session, confirm Connection > SSH > Auth > "Attempt authentication using Pageant" is checked (it is by default).

Step 3: If your key isn't on the server yet

Loading a key only helps if its public half is in the server's ~/.ssh/authorized_keys. If it isn't, you need another way in:

• Another machine that can already connect. Add your new public key to authorized_keys from there.
• Your provider's web console. AWS EC2 Instance Connect or Serial Console, DigitalOcean Recovery Console, Hetzner Rescue, or the VNC console on most VPS panels. These bypass SSH entirely.
• Temporarily enable password auth. From the console:

sudo nano /etc/ssh/sshd_config
# Set: PasswordAuthentication yes
sudo systemctl restart ssh     # Debian/Ubuntu
sudo systemctl restart sshd    # RHEL/CentOS/Fedora

Connect with your password, install the key properly, then set PasswordAuthentication no again. If the key then gets rejected instead of accepted, that's the Server Refused Our Key page.

Step 4: Re-enable keyboard-interactive auth

If the dialog says (server sent: keyboard-interactive) or the server uses password prompts through PAM:

• Go to Connection > SSH > Auth.
• Check "Attempt keyboard-interactive auth (SSH-2)".
• Save the session and reconnect.

This box gets unchecked by people trying to silence login prompts, and the setting rides along in exported/shared sessions.

Step 5: Check the username

Confirm the "login as" name or Connection > Data > "Auto-login username" is the account that actually has access. On cloud images, root is often restricted to keys or blocked outright while the image's default user (ubuntu, ec2-user, opc) works fine.

Common edge cases