How to fix Unable to negotiate with host port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss in SSH

SSHINTERMEDIATEMEDIUMUpdated May 28, 2026· 308 views

Your OpenSSH dropped legacy ssh-rsa/ssh-dss. Re-enable with -o HostKeyAlgorithms=+ssh-rsa or in ~/.ssh/config.

Quick fix

Fixes Unable to negotiate with host port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

ssh -v user@hostname
  1. Verify the offered host key types from the server
  2. Temporarily allow the legacy algorithm for a single connection
  3. Permanently allow the algorithm via SSH config
  4. Remove the cached host key and reconnect
ssh — error
ssh -v user@hostname
Unable to negotiate with host port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

What this error means

SSH uses host key algorithms to verify the identity of the server you're connecting to. During the initial handshake, your SSH client and the remote server negotiate which algorithm to use. This error means the server only offers host key types (like ssh-rsa or ssh-dss) that your SSH client no longer accepts by default. This is typically a security precaution—OpenSSH 8.8 and later disabled ssh-rsa signatures that rely on the SHA-1 hash algorithm due to known cryptographic vulnerabilities. The connection fails because neither side will compromise on an unsafe algorithm.

Typical symptoms

  • SSH connection fails immediately with 'no matching host key type found' error
  • Error message shows the server's offered algorithms, such as 'Their offer: ssh-rsa,ssh-dss'
  • Manual SSH commands fail, but may have worked on older OpenSSH versions
  • Connecting via GUI tools (PuTTY, Termius, VS Code Remote) also fails with the same error
  • The connection works from other machines or older SSH clients

Common causes

  1. Server is running an older SSH daemon that only supports legacy host key algorithms (ssh-rsa, ssh-dss)
  2. OpenSSH client version is 8.8 or newer, which disabled ssh-rsa signatures by default
  3. Server hasn't been updated to support modern algorithms like rsa-sha2-256, rsa-sha2-512, or ed25519
  4. Connecting to legacy network equipment, appliances, or embedded systems with outdated SSH implementations
  5. Client and server were configured to only accept specific algorithms that don't overlap

How to fix "Unable to negotiate with host port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss"

1Verify the offered host key types from the server

First, identify exactly which algorithms the server supports. Run:

bash
ssh -v user@hostname

Look for the line that shows "Their offer:" with a comma-separated list of algorithms. This tells you what the server actually supports. Example output:

bash
Unable to negotiate with 192.168.1.100 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

This shows the server only offers ssh-rsa and ssh-dss, both deprecated algorithms.

2Temporarily allow the legacy algorithm for a single connection

If you need to connect immediately, append the -oHostKeyAlgorithms option to your SSH command:

bash
ssh -o HostKeyAlgorithms=+ssh-rsa user@hostname

Or if that doesn't work, try:

bash
ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@hostname

The + prefix means "add this to the default accepted list" rather than replacing it entirely. This is a quick workaround but should only be used temporarily—see the advanced notes for why.

3Permanently allow the algorithm via SSH config

For a more permanent solution without modifying every SSH command, update your SSH client configuration. Edit ~/.ssh/config (create it if it doesn't exist):

bash
Host myserver
    HostName hostname.example.com
    User myusername
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Replace myserver with an alias, hostname.example.com with the actual server address, and myusername with your username. Then connect using:

bash
ssh myserver

To allow this algorithm for all hosts (less secure, not recommended):

bash
Host *
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Ensure the SSH config file has restricted permissions:

bash
chmod 600 ~/.ssh/config
4Remove the cached host key and reconnect

Sometimes SSH caches old host key information. Clear the cached entry:

bash
ssh-keygen -R hostname.example.com

Or for an IP address:

bash
ssh-keygen -R 192.168.1.100

This removes the host key from ~/.ssh/known_hosts. On your next connection attempt, you'll be prompted to accept the server's key again. After accepting, retry the connection.

5Check your OpenSSH version

Verify which OpenSSH version is running on your client:

bash
ssh -V

Example output:

bash
OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Feb 2022

If you're on OpenSSH 8.8 or newer and connecting to older servers, this is expected behavior. The long-term solution is to upgrade the server. For a detailed changelog of what changed, see the official OpenSSH release notes.

6Best solution: Upgrade the server's SSH daemon

The most secure and permanent fix is to update the SSH server to a modern version that supports secure algorithms. The process depends on the server OS:

Ubuntu/Debian:

bash
sudo apt update
sudo apt install -y openssh-server
sudo systemctl restart ssh

CentOS/RHEL:

bash
sudo yum update -y openssh-server openssh-clients
sudo systemctl restart sshd

macOS:

bash
brew install openssh
# Then update your shell's SSH settings

After upgrading, the server will support modern algorithms (rsa-sha2-256, rsa-sha2-512, ecdsa-sha2-nistp256, ed25519) and your client will connect without needing workarounds.

Advanced notes

Why OpenSSH Disabled ssh-rsa: OpenSSH 8.8 (released September 2021) disabled ssh-rsa signatures because they use the SHA-1 hash algorithm, which has known cryptographic weaknesses. Chosen-prefix collision attacks against SHA-1 are now feasible for under $50K. Using ssh-rsa as a workaround temporarily compromises your security posture.

Modern Alternatives: Most modern servers now support:
- rsa-sha2-256 and rsa-sha2-512 (RSA with SHA-256/SHA-512, secure)
- ecdsa-sha2-nistp256 (Elliptic Curve, good performance/security trade-off)
- ed25519 (Modern, recommended, best security and performance)

These algorithms are backwards compatible with OpenSSH 6.5+ and should be your target for any server upgrade.

For Embedded/Legacy Devices: If upgrading the server isn't possible (e.g., network appliances, embedded systems with custom SSH), using HostKeyAlgorithms=+ssh-rsa is acceptable as a long-term solution, but document it clearly in your SSH config and consider implementing network-level security controls (VPN, jump hosts) to compensate.

Checking Server Support: After upgrading a server, verify it now offers modern algorithms:

bash
ssh -v user@hostname 2>&1 | grep "host key type"

You should see algorithms like rsa-sha2-256 or ed25519 in the output, not just ssh-rsa.

Frequently asked questions

What does "Unable to negotiate with host port 22: no matching host key type found" mean?
SSH uses host key algorithms to verify the identity of the server you're connecting to. During the initial handshake, your SSH client and the remote server negotiate which algorithm to use. This error means the server only offers host key types (like ssh-rsa or ssh-dss) that your SSH client no longer accepts by default.
How do I fix "Unable to negotiate with host port 22: no matching host key type found"?
Your OpenSSH dropped legacy ssh-rsa/ssh-dss. Re-enable with -o HostKeyAlgorithms=+ssh-rsa or in ~/.ssh/config.
What causes "Unable to negotiate with host port 22: no matching host key type found"?
Server is running an older SSH daemon that only supports legacy host key algorithms (ssh-rsa, ssh-dss) OpenSSH client version is 8.8 or newer, which disabled ssh-rsa signatures by default Server hasn't been updated to support modern algorithms like rsa-sha2-256, rsa-sha2-512, or ed25519
Is the "Unable to negotiate with host port 22: no matching host key type found" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading