261

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,[email protected],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.

Improve this question
3
  • 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, 2020 at 8:36
  • 2
    I got Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: curve25519-sha256,[email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,[email protected] so I added the first offer into config and it worked
    – JCQian
    Dec 16, 2020 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, 2021 at 21:13

4 Answers 4

Reset to default
418

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.

Improve this answer
13
  • 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, 2017 at 9: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, 2018 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 1, 2018 at 6: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 1, 2018 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, 2020 at 6:25
59

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,[email protected],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
Improve this answer
8
  • 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, 2017 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, 2017 at 12:50
  • 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, 2019 at 4: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 1, 2020 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, 2022 at 16:44
9

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

Problem:

ssh [email protected]
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 [email protected]

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 [email protected]                    
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#
Improve this answer
1
  • 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 6, 2021 at 13:45
-2

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,[email protected],[email protected],[email protected]
MACs hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-512,hmac-md5,hmac-md5-96,[email protected],[email protected],[email protected],[email protected],[email protected],hma[email protected],[email protected],[email protected],[email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,[email protected],[email protected],[email protected],ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected]
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,[email protected],[email protected]

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.

Improve this answer
3
  • 3
    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 7 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 9 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 9 at 21:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .