267

I am unable to ssh to a server that asks for a diffie-hellman-group1-sha1 key exchange method:

ssh 123.123.123.123
Unable to negotiate with 123.123.123.123 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

How to enable the diffie-hellman-group1-sha1 key exchange method on Debian 8.0?

I have tried (as proposed here) to

  1. add the following lines to my /etc/ssh/ssh_config

    KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr

  2. regenerate keys with 

    ssh-keygen -A

  3. restart ssh with 

    service ssh restart

    but still get the error.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
j1088099.mvrht.com.
  • 3,013
  • 3
    In 2020 and Ubuntu 20 I have solved this problem by installing putty, simply: apt install putty then used putty to connect to old server... – Aleksandar Pavić Aug 25 '20 at 08:36
  • 2
    I got Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,kexguess2@matt.ucc.asn.au so I added the first offer into config and it worked – JCQian Dec 16 '20 at 14:56
  • Why would you restart your OpenSSH server after tinkering with the client-side config? Admittedly it's the system-wide client-side config, but that still doesn't make it relevant for the server. – 0xC0000022L Jun 15 '21 at 21:13

5 Answers5

427

The OpenSSH website has a page dedicated to legacy issues such as this one. It suggests the following approach, on the client:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 123.123.123.123

or more permanently, adding

Host 123.123.123.123
    KexAlgorithms +diffie-hellman-group1-sha1

to ~/.ssh/config.

This will enable the old algorithms on the client, allowing it to connect to the server.

Stephen Kitt
  • 434,908
  • I also faced this problem today, but that was due to the network. I changed the network and the issue was gone – Luv33preet Jun 14 '17 at 09:59
  • 11
    Tried above, but got Unable to negotiate with 192.168.1.123 port 22222: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc – daparic Jul 31 '18 at 22:01
  • @ifelsemonkey that’s a different problem, note that the offer you get isn’t the same as the one in the question. – Stephen Kitt Aug 01 '18 at 06:20
  • 15
    Confirmed it was a different problem. I was able to resolve it by adding the following entry into my ~/.ssh/config file.

    Host 192.168.1.123 and under it Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc.

     – daparic Aug 01 '18 at 17:18
  • -oKexAlgorithms resulted in the same error for me(alghough I'm using git not ssh). but the ~/.ssh/config way worked. – raven Mar 24 '20 at 06:25
  • Add -oCiphers=aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc also on the ssh command-line will make it work if you get the no matching cipher message. – gaoithe Aug 25 '20 at 10:53
  • I have the issue that I can't connect to my new Ubuntu 20 server anymore from my iTerminal App on my iPhone. How do I solve this? – basZero Nov 30 '20 at 15:55
  • @basZero you’re trying to connect to a server requiring new algorithms with a client which doesn’t support them, which is the opposite scenario to that addressed in my answer; see arod’s answer which explains how to configure your server to allow such connections. – Stephen Kitt Nov 30 '20 at 15:57
  • Is there a way to enable this algorithm globally and permanently, so that I don't need to write this in the command every time? – Aaron Franke Jan 06 '21 at 02:38
  • @Aaron see the middle of the answer, “or more permanently, adding ... to ~/.ssh/config.” You can specify Host *. – Stephen Kitt Jan 06 '21 at 05:35
  • rsync -e 'ssh -oKexAlgorithms=+diffie-hellman-group1-sha1' ... for anyone who gets this "Unable to negotiate" error with rsync. – Bob Stein Mar 22 '21 at 15:25
  • Adding KexAlgorithms +diffie-hellman-group1-sha1 and the host/server IP on the client side resolved the issue for me. – Samir May 25 '21 at 18:09
  • To quickly confirm what your client config looks like, use ssh -Q kex and ssh -Q ciphers for the respective list – conny Jul 09 '23 at 00:34
60

I tried this solution, but my problem was that I had many (legacy) clients connecting to my recently upgraded server (ubuntu 14 -> ubuntu 16).

The change from openssh6 -> openssh7 disabled by default the diffie-hellman-group1-sha1 key exchange method.

After reading this and this I came up with the changes I needed to do to the /etc/ssh/sshd_config file:

#Legacy changes
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc

But a more wide legacy set of changes is (taken from here)

#Legacy changes
KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr
arod
  • 781
  • 10
    Hopefully you’ll be able to upgrade your clients at some point, the legacy algorithms were disabled for very good reasons and shouldn’t be re-enabled lightly (you probably realise that, I just thought it worth pointing out for other readers). – Stephen Kitt Jun 14 '17 at 11:10
  • 3
    This works on the server side (unlike the very similar, accepted answer which focused on the client-side.) – knb Sep 15 '17 at 12:50
  • 1
    To add for future people to find, I was connecting via SSH from a Mac running OpenSSH_7.9p1 to a Cisco 3750 switch running:

    Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(55)SE12, RELEASE SOFTWARE (fc2).

    I added the following to the client config and was able to ssh in: KexAlgorithms +diffie-hellman-group1-sha1 Ciphers +aes128-cbc

     – DYoung Mar 12 '19 at 04:36
  • 3
    For many "internal" servers (where the whole network is locked down to trusted users) diffie-hellman is perfectly sufficient. Disabling it breaks a lot of legacy tools for no good reason, requiring expensive development effort to modify the legacy code that no one has looked at in ages. So having a way to enable it server-side is still valuable. – Hashman Sep 01 '20 at 20:42
  • Just to put some justification out there: my Cisco devices with SFTP clients use SHA1 and I can't change that. So I needed a server that allows it.

    I am getting this error: /etc/ssh/sshd_config line 25: Bad SSH2 cipher spec '3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr'

     – Arrow_Raider Mar 30 '22 at 16:44
  • @Hashman the KexAlgorithm is all of them some type of Diffie-Hellman-Merkle conversation - the difference is what encryption/hash algorithm is used - sha1 ISN*T GOOD ENOUGH any longer. – Stefan Skoglund Feb 27 '23 at 08:30
  • @Arrow_Raider Look if you can use some type of rules so that the Cisco devices isn't accessible from outside at least. – Stefan Skoglund Feb 27 '23 at 08:31
  • @StefanSkoglund it's good enough for legacy OpenVMS servers "hidden" behind layers of firewalls and grey beards. Point being that routers aren't the only thing that people ssh into. – RonJohn Apr 01 '23 at 04:59
10

I was also facing the same issue but resolved it by executing below command. You can do it without restarting SSH server-

Problem:

ssh test@123.123.123.123
protocol identification string lack carriage return
Unable to negotiate with 123.123.123.123 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
root@shoesdekho#

Solution:

ssh -o KexAlgorithms=diffie-hellman-group1-sha1 test@123.123.123.123

On other system I have observed that using above command also it was not working. Try adding Ciphers with the command. See full command as below-

root@shoesdekho#ssh -o KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes256-cbc test@123.123.123.123                    
protocol identification string lack carriage return
Warning: Permanently added '123.123.123.123' (RSA) to the list of known hosts.
Password:

This computer system is restricted to authorized users.
 Unauthorized access attempts will be prosecuted.
 If unauthorized, disconnect now.


bookmiday#
IRSHAD
  • 647
  • Thank you - your second solution (with the addition of the Ciphers) fixed my problem - I was trying unsuccessfully to ssh to an ancient Mac OS X 10.4 (Tiger) G5 system and this actually worked. – Paul R Mar 06 '21 at 13:45
5

problem01:

“Unable to negotiate with xxxx port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1”

solution01:

vim ~/.ssh/config and adding:

Host *
    KexAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group14-sha1

problem02:

“no matching host key type found. their offer: ssh-rsa”

solution02:

vim ~/.ssh/config and adding:

Host * 
    PubkeyAcceptedAlgorithms +ssh-rsa 
    HostKeyAlgorithms +ssh-rsa
Terry wang
  • 179
  • 1
  • 3
-1

If you want to be done with the headaches forever, never to ever have to worry or contend with this again, append this to the end of your /etc/ssh/ssh_config file:

Ciphers 3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
MACs hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-512,hmac-md5,hmac-md5-96,umac-64@openssh.com,umac-128@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-md5-96-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com
KexAlgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,curve25519-sha256,curve25519-sha256@libssh.org,sntrup761x25519-sha512@openssh.com

This comes with the usual warnings from others here... Whaaa the sky is falling you so insecure. Whaaa.... To such people, I say keep your negativity and unhelpful comments to yourself. We're all professionals here. We know what the risks are of using deprecated ciphers and key exchanges. Sometimes there are use cases, like accessing end-of-life or old systems.

BTW, the above can be limited to specific hosts if desired. Not a bad idea, but that is up to you. What you do with the power and capability gained from the above is now your responsibility to exercise judiciously.

Zack A
  • 278
  • 5
    Please note that we are not all professionals here, in fact the vast majority of our users are neither professional nor particularly knowledgeable. Which is why they come to us to help, and why it is important to explain the dangers and limitations of our answers in a way that non experts can understand. Also, we expect users to be civil to each other. Please watch your tone. – terdon Mar 07 '23 at 19:10
  • 1
    I disagree. My post was VERY clear that this is not an ideal way to do things, and I suggested limiting it to a single host. But how the end user configures their system is ultimately entirely on them. They assume responsibility for what they do. My beef with this place is that people will downvote you just because they would do something differently. Even if your answer is both correct and solves the issue - as is the exact case here. This is why I take my talent and knowledge elsewhere to help others. No one here appreciates it. – Zack A Mar 09 '23 at 16:19
  • 1
    I also disagree, this was a useful post for me to determine which cipher it was that I needed, then prune it down to just the one. It was a big time saver and clear in the response that it was an insecure operation. The question was about how to re-enable a weak cryptographic standard, but the question wasn't downvoted, the answer was. I think that is a bit like shooting the messenger. – Josiah DeWitt Mar 09 '23 at 21:22