Cannot ssh. "no matching key exchange method found"

Hi,

I’m a bit of a newbie at this but I’ve previously been able to ssh into my HAOS system but recently it comes up with the error:

Unable to negotiate with 192.168.68.108 port 22: no matching key exchange method found. Their offer: mlkem768x25519-sha256,sntrup761x25519-sha512,[email protected],ext-info-s,[email protected]

HAOS is running on a laptop that is connected via Wi-Fi. I can access home assistant and have the Advanced SSH & web terminal Add on installed so I can access the terminal. But I cannot figure out why it wont let me connect from my windows command line on the same network.

I have a RaspberryPi and an OrangePi on the same network and I can SSH into both of those just fine.

Any help or suggestions would be greatly appreciated.

It is yelling you that none of the encryption methods used on the client match the ones used on the server, so they can not agree to on one to talk through.

What client are you using?

I was using windows command Prompt but also doesn’t work on an SSH app on my phone.

Try putty instead

Thank you so much that worked.

Strange that it was working before though.

Thanks for your help.

It would be good to know why it stopped working in the first place.

During some research I got to the ssh_config file which looks like this:

#Host *
#   ForwardAgent no
#   ForwardX11 no
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected]
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k

HostKeyAlgorithms -ecdsa-sha2-nistp256,[email protected],ecdsa-sha2-nistp384,[email protected]>
KexAlgorithms -diffie-hellman-group14-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
MACs -hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,[email protected],[email protected],[email protected]

But again I’m not sure if anything is wrong here.

Did you recently update the Advanced SSH & web terminal Add on ?

Yes I did 2 days ago which I think is the reason it’s not working now.

I will raise an issue on the Github page.

https://github.com/hassio-addons/addon-ssh/issues/904

Seems like they changed the KEX limitations.

No reason to raise an issue on GitHub.
The change is intended and working as it should.
Over time some encryption algorithms will be too weak due to increases in general computing power or due to discovered security holes and these will therefore be disabled in updates.

This got me too. I used to be able to ssh as hassio, but I updated the Advanced SSH & Web terminal add on, and now that my SSL certificate has expired my TrueNAS cron script that fetches a new cert can’t ssh copy it over to Home Assistant.
Now I have no way to manually update the certificate because SSH does not work and Home Assistant is refusing local access too.
WAF is plummeting, thanks a lot Advanced SSH & Web terminal add on. Maybe I forgot to read “Breaking” in the release notes.

The addon works.
Your client does not, because it is outdated.

There might be a way to lower the standards or copy the certificate.
Have you read the documentation?

In Configuration settings, compatibility_mode: true.

It appears to break many common ssh configurations according to comments on that issue.

The applied pull request that added Key Exchange limitations to disable weaker KEX, and change the moduli primes filter in the docker build from >=3071 bits to >=3072 bits,

So this means those of us who were living on the edge of secure will be updating the ssh tools and keys on the various devices to comply - at least until the next security audit. :slight_smile:

1 Like

Yeah, no. According to the discussion on this issue, new restrictions are waaaay too strong.

It is like that with every move on this subject and the terms is set by the OpenSSH team, which do not back down.
SSH is a security app, so security will be first priority.

This is imply not true. My client is not outdated and, I have this problem too.
This is a list optimised for Putty users.

For instance:

curve25519-sha256
[email protected]

Are gone and, both of these are perfectly safe to use.

It is simply checkbox security. They want to get a green audit and, I am not against that but, they have removed cyphers that would not have prevented this.

It is not optimized for putty users.
Putty just happens to follow the same standards released by OpenSSL, which many other vendors does.
If your client does not have these algorithms installed, then it is outdated, even though it might be the newest from the vendor. The vendor have just not followed up with his algorithm libraries.

I have no idea why curve25519-sha256 is not in the list anymore, if it have been in the past.
I could only find an issue with an implementation that had a security hole, but if that implementation was use so widespread that it warranted a removal, I do not know.

They follow the standards from OpenSSL.