SSH public-key auth fails because client and server cannot agree on a signature algorithm, usually after OpenSSH 8.8+ disabled the SHA-1-based ssh-rsa algorithm for RSA keys.
When you authenticate using public key cryptography, the SSH client and server must agree on which signature algorithm to use for proving ownership of the key. OpenSSH 8.8 and newer deprecated the "ssh-rsa" signature algorithm (which relies on the weak SHA-1 hash) for security reasons. This error appears when: the client offers only ssh-rsa (deprecated), the server accepts only ssh-rsa but the client has disabled it, or neither party advertises a common algorithm for the offered key. The two sides cannot find mutual ground, so the key is rejected during signature negotiation. Note this is specifically a signature-algorithm mismatch for an RSA key — it is not a host-key or key-exchange negotiation failure, which produce different messages.
The most future-proof solution is to use an Ed25519 key, which is modern, secure, and widely supported on current systems:
ssh-keygen -t ed25519 -C "[email protected]"When prompted for the file location, press Enter to use the default (~/.ssh/id_ed25519).
When prompted for a passphrase, either press Enter for none or set one (recommended).
Then add your public key to the remote server:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-hostTest the connection:
ssh -i ~/.ssh/id_ed25519 user@remote-hostEd25519 keys sidestep the RSA signature-algorithm negotiation entirely, since they use their own dedicated ssh-ed25519 algorithm.
First, understand what key type you're offering:
ssh-keygen -l -f ~/.ssh/id_rsaExample output:
2048 SHA256:abc123... user@host (RSA)If it says (RSA), you're using the key type affected by this error. If it says (ED25519) or (ECDSA), you have a modern key and the problem likely lies in the server or client algorithm configuration rather than the key itself.
Also check what keys you have:
ls -la ~/.ssh/If you see id_rsa or id_dsa, consider migrating to Ed25519.
If you cannot immediately upgrade keys or the server, you can re-enable the legacy ssh-rsa signature algorithm for a specific host. This is a stopgap: ssh-rsa relies on SHA-1, so scope it narrowly and remove it once the server is fixed.
Edit or create ~/.ssh/config:
nano ~/.ssh/configAdd a block for the specific host only:
Host legacy-server
HostName 192.168.1.100
User ubuntu
IdentityFile ~/.ssh/id_rsa
PubkeyAcceptedAlgorithms +ssh-rsa
HostKeyAlgorithms +ssh-rsaThen connect using the alias:
ssh legacy-serverOr enable it for a single command:
ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa user@hostThe leading + *adds* ssh-rsa to the existing list rather than replacing it, so your other algorithms stay enabled. Prefer fixing the server (next step) over leaving this in place.
If you control the remote server, the best fix is to enable the SHA-2 RSA signature algorithms (rsa-sha2-256 / rsa-sha2-512) rather than falling back to weak ssh-rsa. Your existing RSA keys keep working — only the signature hash changes.
SSH into the server (using password auth if needed) and edit the daemon config:
sudo nano /etc/ssh/sshd_configEnsure modern algorithms are accepted (leave ssh-rsa out unless a legacy client truly requires it):
PubkeyAcceptedAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp256
HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp256Save and exit (Ctrl+X, then Y, then Enter in nano).
Validate the config before applying it so a typo doesn't lock you out:
sudo sshd -tIf it reports no errors, restart the daemon:
sudo systemctl restart sshdOr on older systems:
sudo service sshd restartKeep your existing session open and test a new connection in a separate terminal before closing it.
If your SSH client is too old to support the SHA-2 RSA algorithms, upgrade it.
Check your version:
ssh -Vrsa-sha2 support landed in OpenSSH 7.2; anything older should be upgraded. Instructions vary by OS:
macOS (Homebrew):
brew install opensshUbuntu/Debian:
sudo apt update && sudo apt upgrade openssh-clientCentOS/RHEL:
sudo yum update opensshWindows: Use the bundled OpenSSH (Settings > Optional Features), Windows Subsystem for Linux (WSL), or install from https://github.com/PowerShell/Win32-OpenSSH
On a very old server that lacks Ed25519 support but still rejects ssh-rsa, an ECDSA key is a reasonable middle ground — more compatible than Ed25519 on legacy systems and not subject to the ssh-rsa SHA-1 deprecation:
ssh-keygen -t ecdsa -b 521 -C "[email protected]"The -b 521 selects the NIST P-521 curve. Copy the public key to the server:
ssh-copy-id -i ~/.ssh/id_ecdsa.pub user@remote-hostUse this only when Ed25519 isn't an option; Ed25519 remains the preferred choice on modern systems.
Why was ssh-rsa disabled? OpenSSH 8.8 (August 2021) disabled the ssh-rsa signature algorithm by default because it uses SHA-1, which is cryptographically broken. Practical SHA-1 collision attacks make such signatures untrustworthy, so modern OpenSSH chooses security over legacy compatibility.
ssh-rsa vs rsa-sha2: The confusing part is that "ssh-rsa" names a *signature algorithm*, not the key. The same RSA key can be used with the stronger rsa-sha2-256 and rsa-sha2-512 signature algorithms. That is why simply allowing rsa-sha2 on the server fixes the problem without regenerating keys — you keep the existing RSA key but sign with a safe hash.
Verify negotiation with -vvv: Run ssh -vvv user@host and look for lines such as "send_pubkey_test" and the offered/accepted signature algorithms. This confirms whether the failure is a signature-algorithm mismatch (this error) rather than a host-key or key-exchange mismatch, which produce different messages like "no matching host key type found" or "no matching key exchange method".
Key rotation: When migrating, keep the old key in authorized_keys temporarily until every system accepts the new key, then remove it.
Containers and CI/CD: In Docker, Kubernetes, Ansible, or Terraform, this usually stems from a base image with an old or hardened OpenSSH. Update the base image or install a newer openssh package, and prefer Ed25519 keys for CI identities.
Security timeline: If you re-enable ssh-rsa as a stopgap, scope it per-host and set a firm deadline (e.g. 30 days) to migrate to Ed25519/ECDSA or enable rsa-sha2 on the server, then remove the ssh-rsa override so you don't silently depend on weak cryptography.
sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation
How to fix "sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation" in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
No more authentication methods to try.
How to fix "No more authentication methods to try." in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
bind: Address already in use
How to fix "bind: Address already in use" in SSH