ssh unable to negotiate - no matching key exchange method found
Clash Royale CLAN TAG#URR8PPP
up vote
24
down vote
favorite
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 enduser@10.255.252.1
Unable to negotiate with 10.255.252.1 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 enduser@10.255.252.1
Unable to negotiate with 10.255.252.1 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.
ssh
add a comment |Â
up vote
24
down vote
favorite
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 enduser@10.255.252.1
Unable to negotiate with 10.255.252.1 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 enduser@10.255.252.1
Unable to negotiate with 10.255.252.1 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.
ssh
1
Maybe it's is already answered here
â Eduardo Baitello
Nov 6 '17 at 2:37
1
Ssh has a number of different encryption algorithms it can use, and there is no common one between your client and the server. Try usingssh -o KexAlgorithms=diffe-hellman-group-sha1 enduser@10.255.252.1
to force your client to use an older, less secure algorithm, and see if there is more recent firmware for your router.
â icarus
Nov 6 '17 at 2:39
1
ssh -vvv ...
will reveal all key exchange and cipher protocols offered by the server.
â David Foerster
Nov 6 '17 at 11:16
add a comment |Â
up vote
24
down vote
favorite
up vote
24
down vote
favorite
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 enduser@10.255.252.1
Unable to negotiate with 10.255.252.1 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 enduser@10.255.252.1
Unable to negotiate with 10.255.252.1 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.
ssh
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 enduser@10.255.252.1
Unable to negotiate with 10.255.252.1 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 enduser@10.255.252.1
Unable to negotiate with 10.255.252.1 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.
ssh
edited Nov 6 '17 at 14:47
psmears
43528
43528
asked Nov 6 '17 at 2:23
j0h
91421228
91421228
1
Maybe it's is already answered here
â Eduardo Baitello
Nov 6 '17 at 2:37
1
Ssh has a number of different encryption algorithms it can use, and there is no common one between your client and the server. Try usingssh -o KexAlgorithms=diffe-hellman-group-sha1 enduser@10.255.252.1
to force your client to use an older, less secure algorithm, and see if there is more recent firmware for your router.
â icarus
Nov 6 '17 at 2:39
1
ssh -vvv ...
will reveal all key exchange and cipher protocols offered by the server.
â David Foerster
Nov 6 '17 at 11:16
add a comment |Â
1
Maybe it's is already answered here
â Eduardo Baitello
Nov 6 '17 at 2:37
1
Ssh has a number of different encryption algorithms it can use, and there is no common one between your client and the server. Try usingssh -o KexAlgorithms=diffe-hellman-group-sha1 enduser@10.255.252.1
to force your client to use an older, less secure algorithm, and see if there is more recent firmware for your router.
â icarus
Nov 6 '17 at 2:39
1
ssh -vvv ...
will reveal all key exchange and cipher protocols offered by the server.
â David Foerster
Nov 6 '17 at 11:16
1
1
Maybe it's is already answered here
â Eduardo Baitello
Nov 6 '17 at 2:37
Maybe it's is already answered here
â Eduardo Baitello
Nov 6 '17 at 2:37
1
1
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 enduser@10.255.252.1
to force your client to use an older, less secure algorithm, and see if there is more recent firmware for your router.â icarus
Nov 6 '17 at 2:39
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 enduser@10.255.252.1
to force your client to use an older, less secure algorithm, and see if there is more recent firmware for your router.â icarus
Nov 6 '17 at 2:39
1
1
ssh -vvv ...
will reveal all key exchange and cipher protocols offered by the server.â David Foerster
Nov 6 '17 at 11:16
ssh -vvv ...
will reveal all key exchange and cipher protocols offered by the server.â David Foerster
Nov 6 '17 at 11:16
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
39
down vote
accepted
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...
Host 10.255.252.1
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:
Host 10.255.252.1
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 10.255.252.1
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 theCipher
line, but then it worked! Thanks!
â carlspring
May 31 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
Jul 8 at 16:18
@MikeV Indeed, thank you.
â Michael Kjörling
Jul 8 at 17:15
add a comment |Â
up vote
20
down vote
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 enduser@10.255.252.1
4
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
Nov 6 '17 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.
â Michael Kjörling
Nov 6 '17 at 8:10
add a comment |Â
up vote
1
down vote
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
Jan 22 at 3:49
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
39
down vote
accepted
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...
Host 10.255.252.1
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:
Host 10.255.252.1
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 10.255.252.1
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 theCipher
line, but then it worked! Thanks!
â carlspring
May 31 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
Jul 8 at 16:18
@MikeV Indeed, thank you.
â Michael Kjörling
Jul 8 at 17:15
add a comment |Â
up vote
39
down vote
accepted
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...
Host 10.255.252.1
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:
Host 10.255.252.1
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 10.255.252.1
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 theCipher
line, but then it worked! Thanks!
â carlspring
May 31 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
Jul 8 at 16:18
@MikeV Indeed, thank you.
â Michael Kjörling
Jul 8 at 17:15
add a comment |Â
up vote
39
down vote
accepted
up vote
39
down vote
accepted
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...
Host 10.255.252.1
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:
Host 10.255.252.1
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 10.255.252.1
and all other users on your system, and connections to all other hosts from your system, are unaffected by the changes.
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...
Host 10.255.252.1
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:
Host 10.255.252.1
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 10.255.252.1
and all other users on your system, and connections to all other hosts from your system, are unaffected by the changes.
edited Jul 8 at 17:15
answered Nov 6 '17 at 8:46
Michael Kjörling
15.8k74597
15.8k74597
In my case I had to remove theCipher
line, but then it worked! Thanks!
â carlspring
May 31 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
Jul 8 at 16:18
@MikeV Indeed, thank you.
â Michael Kjörling
Jul 8 at 17:15
add a comment |Â
In my case I had to remove theCipher
line, but then it worked! Thanks!
â carlspring
May 31 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
Jul 8 at 16:18
@MikeV Indeed, thank you.
â Michael Kjörling
Jul 8 at 17:15
In my case I had to remove the
Cipher
line, but then it worked! Thanks!â carlspring
May 31 at 17:14
In my case I had to remove the
Cipher
line, but then it worked! Thanks!â carlspring
May 31 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
Jul 8 at 16:18
According to the ssh_config man page (link) the config file syntax for the ciphers is "Ciphers" (note the trailing s).
â MikeV
Jul 8 at 16:18
@MikeV Indeed, thank you.
â Michael Kjörling
Jul 8 at 17:15
@MikeV Indeed, thank you.
â Michael Kjörling
Jul 8 at 17:15
add a comment |Â
up vote
20
down vote
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 enduser@10.255.252.1
4
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
Nov 6 '17 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.
â Michael Kjörling
Nov 6 '17 at 8:10
add a comment |Â
up vote
20
down vote
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 enduser@10.255.252.1
4
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
Nov 6 '17 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.
â Michael Kjörling
Nov 6 '17 at 8:10
add a comment |Â
up vote
20
down vote
up vote
20
down vote
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 enduser@10.255.252.1
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 enduser@10.255.252.1
edited Nov 6 '17 at 5:15
heemayl
33.1k36897
33.1k36897
answered Nov 6 '17 at 2:50
j0h
91421228
91421228
4
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
Nov 6 '17 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.
â Michael Kjörling
Nov 6 '17 at 8:10
add a comment |Â
4
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
Nov 6 '17 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.
â Michael Kjörling
Nov 6 '17 at 8:10
4
4
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
Nov 6 '17 at 5:16
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
Nov 6 '17 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.
â Michael Kjörling
Nov 6 '17 at 8:10
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.
â Michael Kjörling
Nov 6 '17 at 8:10
add a comment |Â
up vote
1
down vote
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
Jan 22 at 3:49
add a comment |Â
up vote
1
down vote
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
Jan 22 at 3:49
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Jan 22 at 3:17
Trent Three
362
362
1
Although often routers arenâÂÂt kept up to date or supported very well by the manufacturers.
â Guy
Jan 22 at 3:49
add a comment |Â
1
Although often routers arenâÂÂt kept up to date or supported very well by the manufacturers.
â Guy
Jan 22 at 3:49
1
1
Although often routers arenâÂÂt kept up to date or supported very well by the manufacturers.
â Guy
Jan 22 at 3:49
Although often routers arenâÂÂt kept up to date or supported very well by the manufacturers.
â Guy
Jan 22 at 3:49
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f402746%2fssh-unable-to-negotiate-no-matching-key-exchange-method-found%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Maybe it's is already answered here
â Eduardo Baitello
Nov 6 '17 at 2:37
1
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 enduser@10.255.252.1
to force your client to use an older, less secure algorithm, and see if there is more recent firmware for your router.â icarus
Nov 6 '17 at 2:39
1
ssh -vvv ...
will reveal all key exchange and cipher protocols offered by the server.â David Foerster
Nov 6 '17 at 11:16