I am trying to log in to my DSL router, because I'm having trouble with command-line mail. I'm hoping to be able to reconfigure the router.

When I give the ssh command, this is what happens:

$ ssh [email protected]

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

so then I looked at this stackexchange post, and modified my command to this, but I get a different problem, this time with the ciphers.

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]

Unable to negotiate with port 22: no matching cipher found. Their offer: 3des-cbc

so is there a command to offer 3des-cbc encryption? I'm not sure about 3des, like whether I want to add it permanently to my system.

Is there a command to allow the 3des-cbc cipher?

What is the problem here? It's not asking for password.

  • 1
    Maybe it's is already answered here Commented Nov 6, 2017 at 2:37
  • 5
    Ssh has a number of different encryption algorithms it can use, and there is no common one between your client and the server. Try using ssh -o KexAlgorithms=diffe-hellman-group-sha1 [email protected] to force your client to use an older, less secure algorithm, and see if there is more recent firmware for your router.
    – icarus
    Commented Nov 6, 2017 at 2:39
  • 2
    ssh -vvv ... will reveal all key exchange and cipher protocols offered by the server. Commented Nov 6, 2017 at 11:16

7 Answers 7


This particular error happens while the encrypted channel is being set up. If your system and the remote system don't share at least one cipher, there is no cipher to agree on and no encrypted channel is possible. Usually SSH servers will offer a small handful of different ciphers in order to cater to different clients; I'm not sure why your server would be configured to only allow 3DES-CBC.

Now, 3DES-CBC isn't terrible. It's slow, and it provides less security than some other algorithms, but it's not immediately breakable as long as the keys are selected properly. CBC itself has some issues when ciphertext can be modified in transit, but I strongly suspect that the resultant corruption would be rejected by SSH's HMAC, reducing impact. Bottom line, there are worse choices than 3DES-CBC, and there are better ones. However, always tread carefully when overriding security-related defaults, including cipher and key exchange algorithm choices. Those defaults are the defaults for a reason; some pretty smart people spent some brain power considering the options and determined that what was chosen as the defaults provide the best overall security versus performance trade-off.

As you found out, you can use -c ... (or -oCiphers=...) to specify which cipher to offer from the client side. In this case adding -c 3des-cbc allows only 3DES-CBC from the client. Since this matches a cipher that the server offers, an encrypted channel can be established and the connection proceeds to the authentication phase.

You can also add this to your personal ~/.ssh/config. To avoid making a global change to solve a local problem, you can put it in a Host stanza. For example, if your SSH config currently says (dummy example):

Port 9922

specifying a global default port of 9922 instead of the default 22, you can add a host stanza for the host that needs special configuration, and a global host stanza for the default case. That would become something like...

    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
Host *
    Port 9922

The indentation is optional, but I find it greatly enhances readability. Blank lines and lines starting with # are ignored.

If you always (or mostly) log in as the same user on that system, you can also specify that username:

    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
    User enduser
Host *
    Port 9922

You don't need to add a Host * stanza if there was nothing in your ~/.ssh/config to begin with, as in that case only compiled-in or system-wide defaults (typically from /etc/ssh/ssh_config) would be used.

At this point, the ssh command line to connect to this host reduces to simply

$ ssh

and all other users on your system, and connections to all other hosts from your system, are unaffected by the changes.

  • In my case I had to remove the Cipher line, but then it worked! Thanks!
    – carlspring
    Commented May 31, 2018 at 17:14
  • According to the ssh_config man page (link) the config file syntax for the ciphers is "Ciphers" (note the trailing s).
    – MikeV
    Commented Jul 8, 2018 at 16:18
  • your solution worked for me!
    – Marinaio
    Commented Jan 27, 2022 at 16:08

Ok I read the manpage and figured it out.

I did not want to modify my config file, and so I searched the term "cipher" in the man page which showed me the -c option; this allows me to specify the encryption type. the end command was then:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc [email protected]
  • 6
    Be careful with choosing cipher by hand, you could very easily be choosing a weak(er) one unless you know what you are doing (usability et. al.).
    – heemayl
    Commented Nov 6, 2017 at 5:16
  • Ditto @heemayl. 3DES-CBC isn't so bad, but there are ciphers supported at least by recent-ish versions of OpenSSH that are for all intents and purposes completely broken. Tread carefully.
    – user
    Commented Nov 6, 2017 at 8:10
  • 2
    Definitely the most general solution. I used ssh [email protected] -c aes256-cbc to successfully connect after receiving the error Unable to negotiate with port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,[email protected]. Windows server (freeSSHd) and Windows client (cmd.exe)
    – Kar.ma
    Commented Apr 1, 2020 at 12:43

I encountered this problem when setting up a new SFTP server (on Ubuntu 22). Telling all the clients to update their keys and ciphers was not an option (welcome to the trenches).

I added KexAlgorithms +diffie-hellman-group1-sha1 to the bottom of the /etc/ssh/sshd_config file - but before the Match group sftp part of the configuration - otherwise I was getting the following error:

Jun 22 09:43:22 sftp02 sshd[88559]: /etc/ssh/sshd_config line 140: Directive 'KexAlgorithms' is not allowed within a Match block

After that, I still needed to update the ciphers:

Jun 22 09:44:45 sftp02 sshd[88613]: Unable to negotiate with port 46973: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth]

Solution: add this to the sshd_config:

HostkeyAlgorithms +ssh-rsa,ssh-dss

Don't forget to restart ssh service afterwards. In my case:

systemctl restart sshd.service
  • 3
    In summary, it worked for me: I added this fragment into /etc/ssh/sshd_config: # to work with legacy ssh client, in my case, supervised legacy client KexAlgorithms +diffie-hellman-group1-sha1 HostkeyAlgorithms +ssh-rsa,ssh-dss Between de Banner and the sftp subsystem section. Restart ssh service, and it worked like a charm. Thanks!
    – Jordi
    Commented Oct 4, 2022 at 8:57
  • You should simply reload instead of restart : systemctl reload sshd.service
    – fred727
    Commented Feb 21 at 12:23

I recently ran into this problem using PuTTY to connect to a newer version of Ubuntu. It seems earlier versions of PuTTY didn't have updated ciphers. So downloading the latest version of PuTTY fixed the problem. That could be another solution.

  • 1
    Although often routers aren’t kept up to date or supported very well by the manufacturers.
    – Guy
    Commented Jan 22, 2018 at 3:49

Many years later, in 2022 , I have hundreds of those everyday in the logs of all my sshd servers :

Jan  9 00:00:46 server sshd[335552]: Unable to negotiate with x.x.x.x port 53994: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

I'd just tell people : clients needing those SHA1 cyphers are never legitimate users.


Those sha1 based cyphers are no more included in a NORMAL, SECURE, modern ssh server. DONT add those cyphers, forget it, its 99% sure all of those log messages come from bots trying to find VULNERABLE SSH servers using old sha1 cyphers.

If you ever have legitimate clients needing those old cyphers, you have to upgrade the client , not dwngrade the server by adding old unsecure, unsupported sha1 cyphers.

Sure, there are reasons if you need to connect to a very old device needing those, but I hope people will read this warning :) Adding those old cyphers in a ssh client is ok if you know why. But adding those on a ssh server in 2022 is nonsense :)

This is just a warning for ssh server admins finding this thread when googling for this error message ssh unable to negotiate - no matching key exchange method found .

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Jan 15, 2022 at 11:12
  • 2
    My trusty-old OpenWRT repeater cannot be upgraded and I couldn't connect, and now I can and life is great again. Although OP has a point, there's still situations where one CAN and MUST use old stuff. Commented Jan 17, 2022 at 19:54
  • 1
    sure, there are reasons, but I hope people will read this warning :) adding those in a ssh client is ok if you kow why. adding those on a ssh server in 2022 is nonsense :)
    – neofutur
    Commented Feb 2, 2022 at 20:45

Another answer for MacOSX and CLI comamnds (SFTP, for example): refer to this article @ http://www.openssh.com/legacy.html (OpenSSL Legacy Options). I was getting a consistent error of "could not negotiate" which was solved by information in this article, specifically the setting of a configuration parameter in the "~/.ssh/config" file.

BTW, I got this error when my destination SFTP server (not under my administration) finally turned off TLS 1.0 (SSL encryption option) and requires TLS 1.1 or 1.2.


On Ubuntu

#cat /etc/ssh/ssh_config

add below

Ciphers aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc and KexAlgorithms +diffie-hellman-group1-sha1

  • 3
    The specifics don’t depend on the client system, but on the target system and the ciphers and key exchange algorithms it supports. Commented Jun 18, 2021 at 9:42
  • 1
    You probably don't want to enable 3DES globally (and certainly not for all users) - just for the few ancient systems that you're happy to use a weaker cipher with. Commented Jun 24, 2021 at 8:39

You must log in to answer this question.

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