Fix SSH No Supported Authentication Methods: Server Sent Publickey (2026)

The SSH server rejected your connection because it couldn’t find a public key authentication method that it supports and you offered.

This error means your SSH client tried to authenticate using a public key, but the server responded that it doesn’t support the specific public key algorithm you presented. It’s not a failure of your private key itself, but a mismatch in the cryptographic algorithms the client and server agreed to use.

Here are the most common reasons this happens and how to fix them:

1. Outdated SSH Client or Server

The most frequent culprit is that your SSH client or the server is using older cryptographic algorithms that have been deprecated for security reasons. Newer SSH clients and servers might disable these older algorithms by default.

Diagnosis: Check the SSH client version (ssh -V) and the SSH server version (on the server, sshd -V).
Fix (Client-side): If your client is old, upgrade it. If you can’t upgrade the client, you might need to explicitly enable older algorithms (use with caution, as this reduces security). In your ~/.ssh/config file, add:
```
Host your_server_alias
    PubkeyAcceptedAlgorithms +ssh-rsa
```
Replace your_server_alias with the hostname or IP of the server.
Why it works: This tells your client to explicitly offer the ssh-rsa algorithm, which is often the one being rejected if it’s an older server.

2. Server Configuration Restricting Algorithms

The SSH server’s configuration (sshd_config) might be explicitly disallowing certain public key algorithms.

Diagnosis: On the SSH server, examine /etc/ssh/sshd_config. Look for a PubkeyAcceptedAlgorithms or HostKeyAlgorithms directive.
Fix (Server-side): If you have administrative access to the server, edit /etc/ssh/sshd_config. Ensure that the algorithm your client is trying to use (e.g., ssh-rsa, ecdsa-sha2-nistp256, ssh-ed25519) is included in the PubkeyAcceptedAlgorithms or HostKeyAlgorithms directives. For example, to allow RSA and ED25519 keys:
```
PubkeyAcceptedAlgorithms ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
```
After editing, restart the SSH service: sudo systemctl restart sshd (or sudo service ssh restart).
Why it works: This directive explicitly lists the algorithms the server will accept for public key authentication. By adding the missing algorithm, you’re telling the server to consider it.

3. Mismatched Key Types

You might be trying to use a public key type that the server simply doesn’t have configured or enabled. For instance, if your authorized_keys file on the server only contains an RSA public key, but your client is trying to authenticate with an ECDSA key.

Diagnosis: On the server, check the ~/.ssh/authorized_keys file for the user you’re trying to log in as. Identify the type of key (e.g., ssh-rsa, ecdsa-sha2-nistp256, ssh-ed25519). On your client, check which keys are available in ~/.ssh/ (e.g., id_rsa, id_ecdsa, id_ed25519).
Fix: Generate a new key pair on your client using an algorithm supported by the server (e.g., ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519). Then, append the public part of this new key (e.g., ~/.ssh/id_ed25519.pub) to the ~/.ssh/authorized_keys file on the server.
Why it works: This ensures that the server has a public key matching an algorithm that both the client and server support and agree to use.

4. Incorrect Permissions on Server

While less common for this specific error message, incorrect file permissions on the server can prevent sshd from reading the authorized_keys file correctly, leading to unexpected authentication failures.

Diagnosis: On the server, check permissions for ~/.ssh and ~/.ssh/authorized_keys. They should be:
- ~/.ssh: drwx------ (700)
- ~/.ssh/authorized_keys: -rw-r--r-- (644) or -rw------- (600)

Fix: On the server, run:

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

Why it works: SSH is very strict about permissions for security reasons. If the authorized_keys file is world-readable or group-writable, sshd will ignore it to prevent potential compromise.

5. SSH Agent Not Offering the Correct Key

If you’re using an SSH agent (ssh-agent) to manage your keys, it might not be offering the specific key that matches the server’s configuration, or the agent might be misconfigured.

Diagnosis: Run ssh-add -l to list keys currently loaded in your agent. Check if the key type you expect is listed.
Fix: If the correct key isn’t listed, add it using ssh-add ~/.ssh/your_private_key_file. If the agent is presenting the wrong key first, you can sometimes influence the order or explicitly tell SSH which key to use with ssh -i ~/.ssh/your_private_key_file user@host.
Why it works: The SSH agent acts as a proxy for your private keys. If it doesn’t have the right key loaded or is presenting it incorrectly, the client won’t be able to use it for authentication.

6. Client Configuration Overrides

Your local ~/.ssh/config file might have settings that interfere with the authentication process, such as explicitly disabling certain algorithms or forcing a specific key that isn’t accepted.

Diagnosis: Review your ~/.ssh/config file for any PubkeyAcceptedAlgorithms, HostKeyAlgorithms, or IdentityFile directives that might be misconfigured for the target host.
Fix: Comment out or adjust any conflicting settings in ~/.ssh/config. For example, if you have PubkeyAcceptedAlgorithms -ssh-rsa (which disables RSA), remove that line or change it to +ssh-rsa.
Why it works: The SSH client reads configuration from ~/.ssh/config and applies it. Incorrect settings here can override defaults or system-wide configurations, leading to the observed error.

If you’ve addressed these, the next error you might encounter is related to host key verification or a different authentication method failing.