This error occurs when an SSH client and server cannot agree on a mutually supported signature algorithm for public key authentication. It typically happens when using deprecated RSA keys with newer OpenSSH versions (8.8+) that disabled SHA-1 signatures, or when connecting to legacy servers that don't support modern signature algorithms.
When you attempt to authenticate using public key cryptography, the SSH client and server must agree on which signature algorithm to use. 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 supports only ssh-rsa (deprecated), the server supports only ssh-rsa but has disabled it, or neither party supports a common algorithm. The systems cannot find mutual ground, so authentication fails before you're even prompted for a password.
The most future-proof solution is to use Ed25519 keys, which are modern, secure, and widely supported:
ssh-keygen -t ed25519 -C "[email protected]"When prompted for file location, press Enter to use the default (~/.ssh/id_ed25519).
When prompted for passphrase, either press Enter for no passphrase or create one.
Then add your public key to the remote server:
ssh-copy-id -i ~/.ssh/id_ed25519 user@remote-hostTest the connection:
ssh -i ~/.ssh/id_ed25519 user@remote-hostEd25519 keys eliminate signature algorithm negotiation issues because OpenSSH treats them differently than RSA.
First, understand what key type you're using:
ssh-keygen -l -f ~/.ssh/id_rsaOutput example:
2048 SHA256:abc123... user@host (RSA)If it says "RSA", you're using the problematic algorithm. If it says "ED25519" or "ECDSA", you have a modern key.
Also check if you have multiple keys:
ls -la ~/.ssh/If you see id_rsa, id_dsa, or other old algorithms, consider replacing them.
If you cannot immediately upgrade keys or servers, you can tell your SSH client to accept ssh-rsa signatures temporarily.
Edit or create ~/.ssh/config:
nano ~/.ssh/configAdd this block for the specific host:
Host legacy-server
HostName 192.168.1.100
User ubuntu
IdentityFile ~/.ssh/id_rsa
PubkeyAcceptedAlgorithms +ssh-rsa
HostKeyAlgorithms +ssh-rsaThen connect using the host alias:
ssh legacy-serverAlternatively, enable it on a per-command basis:
ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa user@hostImportant: The "+" means "add to the list of allowed algorithms" rather than replace the entire list.
If you have access and control over the remote server, you can enable support for rsa-sha2 signatures instead of just ssh-rsa.
SSH into the server (using password auth if needed) and edit /etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_configAdd or modify these lines to enable RSA with SHA-2 signatures:
HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
PubkeyAcceptedAlgorithms rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519Save and exit (Ctrl+X, then Y, then Enter in nano).
Restart the SSH daemon:
sudo systemctl restart sshdOr on older systems:
sudo service sshd restartNow clients with RSA keys using SHA-2 signatures will work.
If you're running a very old SSH client that doesn't support modern algorithms, upgrade it.
Check your SSH version:
ssh -VIf you see version below 7.2, consider upgrading. Instructions vary by OS:
macOS (Homebrew):
brew install opensshUbuntu/Debian:
sudo apt update && sudo apt upgrade openssh-clientCentOS/RHEL:
sudo yum update opensshWindows: Use Windows Subsystem for Linux (WSL) or install OpenSSH from https://github.com/PowerShell/Win32-OpenSSH
If the remote server is too old to support Ed25519, generate an ECDSA key instead (more compatible than Ed25519 but more secure than RSA):
ssh-keygen -t ecdsa -b 521 -C "[email protected]"This creates a 521-bit ECDSA key (the "-521" specifies the curve size). Copy it to the server:
ssh-copy-id -i ~/.ssh/id_ecdsa user@remote-hostECDSA is more broadly supported than Ed25519 on legacy systems, but less favored than Ed25519 on modern systems.
Advanced troubleshooting and context:
Why was ssh-rsa disabled? OpenSSH 8.8 (August 2021) deprecated ssh-rsa because it relies on SHA-1, which is cryptographically broken. Collision attacks against SHA-1 are feasible, making RSA signatures potentially forgeable. Modern systems choose security over legacy compatibility.
RSA SHA-2 vs ssh-rsa: Modern OpenSSH supports rsa-sha2-256 and rsa-sha2-512 for RSA keys. These use the same RSA key but with stronger hash algorithms. This is why updating sshd_config to allow these works: you keep existing RSA keys but use safer signatures.
Key rotation best practices: When generating new keys, keep old ones temporarily in case you need to access systems from multiple locations. Once all systems support your new key type, you can remove old keys.
Container and CI/CD: If you're seeing this in Docker, Kubernetes, Ansible, or Terraform environments, the issue is usually the base image using an old OpenSSH version. Update the base image or install newer openssh packages in your Dockerfile.
Security considerations: Do not leave ssh-rsa permanently enabled unless absolutely necessary. Set a timeline (e.g., 30 days) to migrate all systems to Ed25519 or ECDSA, then disable ssh-rsa entirely. This prevents accidental reliance on weak cryptography.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH
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