Skip to main content
DevOps Insightsguides & answers

OpenSSH · troubleshooting

Unable to negotiate: no matching host key type found. Their offer: ssh-rsa

Your SSH client and the server share no allowed algorithm, usually because the server offers only retired ones: ssh-rsa SHA-1, old key exchange or CBC. Update or reconfigure the server; allow the old algorithm for that one host only as a stopgap.

Reproduced on OpenSSH 10.3p1, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

  • The full error line, which ends with Their offer: and the server's list.
  • ssh -V on the client; access to the server's sshd configuration, or to whoever manages the device.

Run this first

step 1 of 2
ssh -V

Look for Your client version

Retirements happened in specific releases: CBC in 7.6, group14-sha1 in 8.2, ssh-rsa signatures in 8.8.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Which negotiation failed?

Cause space

3 of 3 still possible

  • The server only signs with ssh-rsa (SHA-1)Common
  • The server only offers retired key exchange methodsOccasional
  • The server only offers CBC ciphersOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    ssh -V

    Retirements happened in specific releases: CBC in 7.6, group14-sha1 in 8.2, ssh-rsa signatures in 8.8.

    Look for Your client version

  2. Step 2

    ssh -vv HOST 2>&1 | grep -E 'peer server KEXINIT|KEX algorithms|host key algorithms|ciphers ctos|Their offer'

    Shows what each side proposed: the lines after peer server KEXINIT proposal are the server's, the ones before are your client's.

    Look for Which list (KEX, host key, ciphers) has no entry in common

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

The server only signs with ssh-rsa (SHA-1)

Common

An old SSH server or device that predates RSA SHA-2 signatures, or is configured to offer only ssh-rsa. OpenSSH 8.8 and later refuse it by default.

Confirm

ssh -vv HOST 2>&1 | grep -E 'peer server KEXINIT|host key algorithms|Their offer'

Their offer: ssh-rsa, with no rsa-sha2-256 or rsa-sha2-512

Fix

  • Fix the server: upgrade its SSH software, or configure it to offer rsa-sha2-512 and rsa-sha2-256 (or an Ed25519 or ECDSA host key).
  • As a stopgap for that host only, add to ~/.ssh/config: Host OLD-HOST, then HostKeyAlgorithms +ssh-rsa and PubkeyAcceptedAlgorithms +ssh-rsa (the second only if your key login also fails), as OpenSSH's release notes suggest.
ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@OLD-HOST

For one connection; put the same two lines under a Host OLD-HOST block to keep it. Remove once the server is fixed.

The server only offers retired key exchange methods

Occasional

Devices limited to diffie-hellman-group14-sha1 or older SHA-1 key exchanges. OpenSSH removed group14-sha1 from its default proposal in 8.2.

Confirm

ssh -Q kex

Whether the method in Their offer is still supported by your client at all

Fix

  • Upgrade or reconfigure the device to offer curve25519-sha256 or diffie-hellman-group14-sha256 or newer.
  • Stopgap for that host: KexAlgorithms +diffie-hellman-group14-sha1 in a Host block.

The server only offers CBC ciphers

Occasional

Old devices that only know aes128-cbc, aes256-cbc or 3des-cbc. The OpenSSH client has not offered CBC ciphers by default since 7.6.

Confirm

ssh -Q cipher

The cipher from Their offer in your client's supported list

Fix

  • Enable CTR or GCM ciphers on the device, or upgrade it.
  • Stopgap for that host: Ciphers +aes128-cbc in a Host block.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Before logging in, the SSH client and server agree on the maths they will use: how to prove the server's identity, how to set up a shared key, and how to encrypt. Newer OpenSSH versions have dropped some old, weakened options. When an old server, switch or appliance only knows those, the two sides find nothing in common, and the client stops and tells you exactly what the server offered.

Words used on this page

Host key algorithm
How the server proves its identity. ssh-rsa means an RSA key signed with SHA-1; rsa-sha2-256 and rsa-sha2-512 use the same RSA key with SHA-2.
Key exchange (kex)
How both sides agree on session keys, for example curve25519-sha256 or the older diffie-hellman-group14-sha1.
Cipher
The encryption for the session, for example aes128-ctr or the older aes128-cbc.
Their offer
The list the server sent. Comparing it with ssh -Q for your client shows what is missing.
What is actually happening

Reproduced on OpenSSH 10.3p1 with a throwaway local server: a server offering only ssh-rsa as its host key algorithm made the client stop with Unable to negotiate with 127.0.0.1 port 22999: no matching host key type found. Their offer: ssh-rsa. The very same RSA host key offered as rsa-sha2-512 connected normally.

That is the point OpenSSH's 8.8 release notes make: SHA-1 RSA signatures were disabled by default, and there is no need to replace ssh-rsa keys, because RSA keys can sign with SHA-2 (supported since 7.2). The problem is a server that only signs with SHA-1.

The same family of errors covers the other negotiations. A server limited to diffie-hellman-group14-sha1 gave no matching key exchange method found (removed from the defaults in 8.2), and one limited to aes128-cbc gave no matching cipher found (the client stopped offering CBC in 7.6). Each connected once the matching option re-enabled that one algorithm.

The usual servers are old network equipment, embedded devices, old appliances and sometimes old Git hosting or SFTP servers, rather than current Linux distributions.

How to tell this is your problem
WhereWhat you see
ssh, scp, sftp, git over SSHUnable to negotiate with HOST port 22: no matching host key type found. Their offer: ssh-rsa
Key exchange variantUnable to negotiate with HOST port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1
Cipher variantUnable to negotiate with HOST port 22: no matching cipher found. Their offer: aes128-cbc

How to know it is actually fixed

  • ssh HOST connects without the Unable to negotiate error.
  • After the server is fixed, the connection still works with the Host exception removed.

Stopping it happening again

  • Keep network devices' SSH firmware current, and give them Ed25519 or ECDSA host keys where supported.
  • Record every per-host legacy exception in ~/.ssh/config with a comment and a date, so it gets removed.

Security considerations

  • Re-enable an old algorithm only for the one host that needs it (a Host block in ~/.ssh/config), never with Host * or in the global ssh_config.
  • Treat it as temporary, as OpenSSH's release notes do: upgrade or reconfigure the device, then remove the exception.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next