Introduction

This SSH error means the server is willing to authenticate you with a public key, but your client did not offer an acceptable key or could not use one correctly. In other words, the server said "publickey only," and the client had nothing valid to complete that method.

What the Error Really Says

A message like:

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

usually indicates:

• password login is disabled on the server
• the server expects key-based authentication
• the client did not present a matching private key

The problem is rarely "SSH is broken." It is almost always a mismatch between the key the server expects and the key the client actually offers.

Start With Verbose Client Output

The fastest way to narrow the issue is:

ssh -vvv [email protected]

The verbose log shows:

• which private keys the client tried
• whether the SSH agent offered anything
• whether the server rejected a key

That output is much more useful than guessing.

Make Sure You Actually Have the Right Private Key

If the server has your public key in ~/.ssh/authorized_keys, your client needs the matching private key locally.

Typical files:

ls -la ~/.ssh

You may see keys such as:

• 'id_ed25519'
• 'id_rsa'
• custom-named private keys

If the key is not one of the default names, specify it explicitly:

ssh -i ~/.ssh/my_deploy_key [email protected]

If this works while the normal command fails, the key was present but not being selected automatically.

Confirm the Public Key Is Installed on the Server

On the server, the matching public key must exist in the target user's authorized_keys file:

cat ~/.ssh/authorized_keys

The entry should match the public half of the private key you are using locally:

cat ~/.ssh/my_deploy_key.pub

If the public key is missing or copied incorrectly, the server will reject the login even though it is configured for public-key authentication.

Permissions Matter

SSH is strict about file permissions on the server side. Typical safe permissions are:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~

If the home directory or .ssh files are too open, sshd may ignore the keys entirely. This is one of the most common reasons a correctly copied key still fails.

Check the Server Configuration

On the server, confirm that public-key authentication is enabled:

grep -E 'PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication' /etc/ssh/sshd_config

Relevant settings often look like:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

After changes, restart or reload the SSH service according to the host operating system.

SSH Agent and Key Format Issues

Sometimes the key is correct, but the client is not offering it through the agent. You can inspect loaded keys with:

ssh-add -l

If the needed key is missing, add it:

ssh-add ~/.ssh/my_deploy_key

Another issue is old tooling and unsupported key formats or algorithms. If the client and server are far apart in age, the verbose SSH output usually reveals that mismatch more clearly than the short disconnect message does.

Use the Correct Username

A surprisingly common failure is authenticating with the wrong account. The public key may be installed for deploy, but the client connects as ubuntu or ec2-user.

Always verify the username:

ssh -i ~/.ssh/my_deploy_key [email protected]

Public keys are checked against the target user's home directory and authorized_keys, so the correct key with the wrong username still fails.

Common Pitfalls

The most common mistake is assuming the presence of a .pub file locally means the client can authenticate. SSH needs the private key, not just the public key.

Another issue is copying the public key correctly but leaving server-side permissions too loose. In that case the server may silently ignore authorized_keys.

People also skip ssh -vvv and start changing unrelated settings. The verbose log usually shows whether the problem is key selection, key rejection, or username mismatch.

Summary

• The server is asking for public-key authentication, and the client is not completing it successfully.
• Start with ssh -vvv to see which keys are being offered and rejected.
• Make sure the local private key matches the public key installed in authorized_keys.
• Fix server-side permissions on the home directory, .ssh, and authorized_keys.
• Check the username, SSH agent state, and sshd_config before changing anything else.