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

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

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

I have tried (as proposed here) to

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

regenerate keys with

restart ssh with

but still get the error.

3 Answers 3

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

or more permanently, adding

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

/.ssh/config file. Host 192.168.1.123 and under it Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc . – eigenfield Aug 1 ’18 at 17:18

/.ssh/config way worked. – raven Mar 24 ’20 at 6:25

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:

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

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

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-

Cannot connect to Cisco devices (diffie-hellman-group1-sha1) #796

Comments

Chinggis6 commented Jul 5, 2017 •

I installed through chocolatey on Windows 10.

And when adding:

The latter option passes in Linux ssh though.

The text was updated successfully, but these errors were encountered:

bagajjal commented Jul 5, 2017 •

Are you sure you are using win32-openssh?
From task manager, go to «details» tab.. click on the sshd, right click and select «open file location»

If yes, please share the sshd.log in the logs folder and also ssh client logs (ssh.exe -vvv user@ip)

DarwinJS commented Jul 5, 2017 •

manojampalam commented Jul 6, 2017

Issue is with cipher negotiation failure — that happens when client and server do not speak any common ciphers.
Do a «ssh -vv» and check what’s being negotiated. (sample below: ctos means client to server)

ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr

bagajjal commented Jul 18, 2017

Closing this issue as there is no update in last 2 weeks..
Please reopen with the required information.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

How To Disable diffie-hellman-group1-sha1 for SSH

I have found that my server via SSH still supports diffie-hellman-group1-sha1. To stay compliant with latest PCI Compliance I have been trying to figure out how to disable diffie-hellman-group1-sha1. Weakdh.org doesn’t exactly give clear instructions on how to disable this nor anything on the web. What is the proper way to disable this algorithm without disabling Port 22 for SSH on Ubuntu? Below is what algorithms my server supports when running ssh -Q kex .

3 Answers 3

gives you the list of client supported algorithms. The server ones you will get from sshd -T | grep kex (on the server of course).

And if you want to remove one, just take the list you get from previous command, remove the algorithm you are interested in and put it in the /etc/ssh/sshd_config (or replace existing line there with the kex algorithms).

man sshd_config

So to disable «diffie-hellman-group1-sha1» , specify required Algorithms with Parameter KexAlgorithms

Example

In OpenSSH 7.6 if you want to remove one or more options and leave the remaining defaults you can add the following line to /etc/ssh/sshd_config :

Note the — at the start of the comma separated list. The above line would disable diffie-hellman-group1-sha1 and ecdh-sha2-nistp256.

This is detailed further in man sshd_config under KexAlgorithms :

One final note, after making any changes to /etc/ssh/sshd_config always verify them using sshd -t before restarting sshd.

SSH : Unable to negotiate with XXX.XXX.XX.XXX : no matching key exchange method found. They offer: diffie-hellman-group1-sha1 [closed]

Want to improve this question? Update the question so it’s on-topic for Stack Overflow.

Closed 4 years ago .

I’m trying to clone a repo on Windows with MINGW64 and I get this error.

*Already check the doc http://www.openssh.com/legacy.html and the Solution in the post http://www.openssh.com/legacy.html and still get the error.

Already added this to my config file Host somehost.example.org KexAlgorithms +diffie-hellman-group1-sha1

1 Answer 1

group1 is weak and should be disabled; see https://weakdh.org/sysadmin.html

A server that only supports group1 is really bad. Asking the server operator to upgrade it is the right fix.

If you’re desperate to connect to it anyway, you should be able to tell your client to enable it with the ssh option KexAlgorithms +diffie-hellman-group1-sha1 . It can be set in the ssh config file or on the command line with -o . If you want to use the command line option you’ll need to tell git to pass the option to ssh, which is explained in the answers to this question: Passing ssh options to git clone

/.ssh/config. Then it worked. I suspect the issue was that when I gave these parameters to the repository specific git config file, the ssh hostname that git was picking up was the actual IP address, while when I gave these parameter to the ssh config file, ssh applied it to the FQDN of the hostname, and it worked. It is weird. – zafar142003 Jul 18 ’17 at 4:50

Issue with cloning git repository

I am trying to clone the git repository and i am getting error

/.ssh/config and added

but still I am getting same error.

Other solution is to use the command ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@127.0.0.1 -p 2222 but I am getting connection refused with port no 22 as well.

I am using windows machine.

/.ssh/config (search for ssh-agent.exe in the Task Manager). This worked for me after upgrading Git for Windows to v2.25.1. – S. Marti Mar 10 ’20 at 9:29

7 Answers 7

Your problem is described in details here:

If the client and server are unable to agree on a mutual set of parameters then the connection will fail.
OpenSSH (7.0 and greater) will produce an error message like this:
Unable to negotiate with 127.0.0.1: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Setting alternate ssh keys

now add the public key under your server account and try again.

attach my ssh config for people who come across the same issue

use larger postBuffer if come accross another issue

I am using windows, for my case git clone fails in Jenkins (running under system user).

/.ssh/config will make the clone running as the current user works.

For other users, the OpenSSH won’t pick up the config. I have to add the above config into the global config file: «C:\Program Files\Git\etc\ssh\ssh_config» to make it work.

This happens after I updated the git-for-windows client, new git disable some old key exchange method. Another work around is install older version of git. eg: https://github.com/git-for-windows/git/releases/tag/v2.20.1.windows.1

Appending the file C:\Program Files\Git\etc\ssh\ssh_config with below content worked for me:

Include above lines in .config file and add .config file in .ssh directory where id_rsa.pub and other files are located.

This error occurs when the client and server are unable to agree on the key exchange algorithm to use. You can see in the error log what key exchange algorithms the server is offering to use. In case when your client is unable to work with the methods offered by the server, the error is thrown. To fix this issue changes can be made on the client or server side. If you can change the server’s configuration, that would be the better path to take as you wouldn’t have to make changes in all clients. To fix the issue on the server side, you need to upgrade/configure the server to not use deprecated algorithms.

If change on the server side is not possible, one could simply force the client to re-enable the key exchange algorithms the server is ready to work with. You can do this permanelty by updating the

/.ssh/config file on linux or C:\Program Files\Git\etc\ssh\ssh_config file on windows and adding the following lines :