SSH: No Supported Authentication Methods Available (Server Sent Publickey)

Q: How do I fix it with the OpenSSH command line?

Point ssh at the right key: `ssh -i ~/.ssh/id_ed25519 user@host`. If that works, add an `IdentityFile` entry in `~/.ssh/config`. Also ensure the private key is `chmod 600` - SSH silently ignores a key with loose permissions, which produces this same error.

Q: Why does the server only accept publickey?

Because it has `PasswordAuthentication no` set in sshd_config, disabling password login on purpose. Key-only authentication is stronger and resists brute-force attacks, so it is standard hardening on internet-facing servers. The fix is to get your key working, not to re-enable password login.

Q: The key is loaded but it still fails - why?

The matching public key is probably not in the server's `~/.ssh/authorized_keys`, or the file permissions are wrong. Add the public key (for example with `ssh-copy-id`), and ensure `~/.ssh` is `chmod 700` and `authorized_keys` is `chmod 600`, owned by the login user. Wrong permissions cause a silent rejection.

No supported authentication methods available (server sent: publickey) is the server and your client failing to agree on how to log in. The parenthetical is the whole message: the server will only accept a public key, and your client did not present one it liked. It is not a network problem and not a wrong password - password login is switched off server-side, so a password will never work no matter how many times you retype it. The fix is to give the client the right key: load your private key into PuTTY (or Pageant), or point OpenSSH at it with -i - and make sure the matching public key is in the server’s authorized_keys.

This error is most famous in PuTTY, and it almost always means one thing: the server wants a key, you have not handed it one, and no amount of password-typing will change that.

What the error is really saying
The PuTTY case: load your key
The OpenSSH case: point it at the key
Confirm the public key is on the server
When password auth is off on purpose
How this fits the rest of the stack
FAQ

What the error is really saying

SSH authentication is a negotiation. The server advertises which methods it will accept; the client tries the ones it can satisfy. This error means that list did not overlap:

The server said it accepts publickey (and, the message implies, not password).
Your client had no acceptable key to offer.

The (server sent: publickey) part is the server telling you exactly what it wants. So the problem is never “wrong password” - the server is not offering password login at all. It is one of: your key is not loaded in the client, the client is offering the wrong key, or the matching public key is not on the server. Everything below is about closing that gap.

The PuTTY case: load your key

In PuTTY this error usually means you have not told PuTTY which private key to use, or the key is in the wrong format.

The checklist:

Point PuTTY at your key. In the session config, go to Connection > SSH > Auth > Credentials and set the private key file to your .ppk.
Use PuTTY’s format. PuTTY needs a .ppk file. If you have an OpenSSH-format key, convert it with PuTTYgen (Load the key, then Save private key as .ppk).
Or run Pageant. PuTTY’s agent, Pageant, holds your loaded keys so every session can use them. Add the key to Pageant and PuTTY will offer it automatically.

Most of the time it is step 1 - the key was never selected, so PuTTY connected with nothing to authenticate and the server rejected it.

The OpenSSH case: point it at the key

From a command-line OpenSSH client (Linux, macOS, modern Windows), the same problem shows up when the client is not offering the key the server expects.

Name the key explicitly:

ssh -i ~/.ssh/id_ed25519 user@host

If that works, make it permanent in ~/.ssh/config:

Host myserver
    HostName host
    User user
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

IdentitiesOnly yes stops the client from throwing other keys at the server first. Also confirm the key permissions are tight - SSH ignores a private key that is world-readable: chmod 600 ~/.ssh/id_ed25519. A key with loose permissions is silently skipped, which reproduces this exact error.

Confirm the public key is on the server

Even with the client offering the right key, the login fails if the matching public key is not in the server’s authorized list. The server checks the incoming key against ~/.ssh/authorized_keys for the user you are logging in as.

If you have another way in (a console, a different working key), verify it is there:

cat ~/.ssh/authorized_keys

The public half of your key pair should be one of the lines. If it is missing, add it - the ssh-copy-id user@host command does this cleanly when password login is still available. Watch the details that silently break it: the file must be chmod 600, the .ssh directory chmod 700, and owned by the right user. A correctly-added key in a directory with wrong permissions is rejected without a helpful message.

When password auth is off on purpose

Often this error is the system working exactly as intended. A hardened server sets PasswordAuthentication no in /etc/ssh/sshd_config precisely so that only key-based login is allowed - passwords are a weaker, brute-forceable method, and turning them off is good practice on any internet-facing box.

So the right response is usually not to re-enable passwords; it is to get your key working. Only if you are locked out entirely, with no console and no working key, would you (via a provider console) temporarily set PasswordAuthentication yes, restart sshd, add your key, and turn it back off. For everyday use, treat server sent: publickey as a reminder that this box does keys only - load the right key and connect. Do not fix a security feature by disabling it.

How this fits the rest of the stack

Whatever you decide here, the cost of it eventually shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.

Useful related references:

FAQ

What does no supported authentication methods available mean?

It means the server and your SSH client could not agree on a login method. The (server sent: publickey) note means the server only accepts key-based login and your client did not present an acceptable key. It is not a wrong-password problem - password login is disabled server-side, so a password cannot work.

How do I fix this error in PuTTY?

Point PuTTY at your private key under Connection > SSH > Auth > Credentials, using a .ppk file (convert an OpenSSH key with PuTTYgen if needed). Alternatively, load the key into Pageant, PuTTY’s key agent, so every session offers it automatically. Usually the key was simply never selected.

How do I fix it with the OpenSSH command line?

Point ssh at the right key: ssh -i ~/.ssh/id_ed25519 user@host. If that works, add an IdentityFile entry in ~/.ssh/config. Also ensure the private key is chmod 600 - SSH silently ignores a key with loose permissions, which produces this same error.

Why does the server only accept publickey?

Because it has PasswordAuthentication no set in sshd_config, disabling password login on purpose. Key-only authentication is stronger and resists brute-force attacks, so it is standard hardening on internet-facing servers. The fix is to get your key working, not to re-enable password login.

The key is loaded but it still fails - why?

The matching public key is probably not in the server’s ~/.ssh/authorized_keys, or the file permissions are wrong. Add the public key (for example with ssh-copy-id), and ensure ~/.ssh is chmod 700 and authorized_keys is chmod 600, owned by the login user. Wrong permissions cause a silent rejection.