Fixing the SSH 'no matching host key type found' Error

The ProblemYou’re trying to manage an old Cisco Catalyst switch or a legacy CentOS 6 server, but your brand-new Ubuntu 24.04 laptop refuses to connect. The connection drops instantly. Instead of a password prompt, you see this error:

$ ssh root@192.168.1.10
Unable to negotiate with 192.168.1.10 port 22: no matching host key type found. Their offer: ssh-rsa

Why This HappensThis isn't a bug. It is a deliberate security move. Since the release of OpenSSH 8.8 in September 2021, the ssh-rsa signature algorithm has been disabled by default.

The issue lies with the SHA-1 hash function. Security researchers have proven that SHA-1 is vulnerable to chosen-prefix attacks. In 2020, the cost of performing such an attack was estimated at around $50,000 USD—well within the reach of many bad actors. Because your modern SSH client considers SHA-1 broken, it rejects the server’s offer to use it. You are essentially stuck between modern security standards and aging infrastructure.

Solution 1: The Quick Fix (Command Line)If you just need to get into the server once to update a config file, don't change your global settings. You can tell SSH to allow the older algorithm for just this one session using the -o flag.

ssh -o HostKeyAlgorithms=+ssh-rsa root@192.168.1.10

If you use an SSH key to log in and that also fails, you likely need to re-enable RSA for public keys as well:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa root@192.168.1.10

Solution 2: The "Set and Forget" Fix (Recommended)Typing long flags every time is annoying. A better approach is to create an exception for that specific server in your local configuration. This keeps your system secure for everything else while letting you access legacy gear seamlessly.

• Open your user-level SSH config file:nano ~/.ssh/config- Add these lines for your specific device IP or hostname:Host 192.168.1.10 HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa- Save and exit. Ensure the file has the correct permissions so SSH doesn't ignore it:``` chmod 600 ~/.ssh/config

Now, a simple `ssh root@192.168.1.10` will work without any extra flags.
## Solution 3: The Nuclear Option (Global Fix)If you are working in a lab with hundreds of legacy machines, you might be tempted to enable this globally. **Be careful: this makes every SSH connection you initiate slightly less secure.**
Edit `/etc/ssh/ssh_config` with sudo and add these lines to the bottom of the file:

HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa

## Verifying the ConnectionTo confirm the fix is working as intended, run SSH in verbose mode. You can filter the output to see exactly which algorithm was negotiated.

ssh -v root@192.168.1.10 2>&1 | grep -i "host key"

Look for a line like this to confirm success:

debug1: kex: host key algorithm: ssh-rsa

## The Long-Term FixBypassing security checks is a temporary bandage. If you have administrative access to the remote server, you should upgrade its keys to something modern like **Ed25519**. It is faster and significantly more secure than RSA.
Run this on the remote server to generate a new host key:

ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key < /dev/null

After that, add `HostKey /etc/ssh/ssh_host_ed25519_key` to the server's `/etc/ssh/sshd_config` and restart the SSH service. Your modern client will now connect without any workarounds.