Unix & Linux Asked by lesnik on February 20, 2021
I am trying to ssh to remote machine, the attempt fails:
$ ssh -vvv [email protected]
OpenSSH_7.7p1, OpenSSL 1.0.2o 27 Mar 2018
.....
debug2: ciphers ctos: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
Unable to negotiate with 192.168.100.14 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
As far as I understand the last string of the log, the server offers to use one of the following 4 cipher algorithms: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc. Looks like my ssh client doesn’t support any of them, so the server and client are unable to negotiate further.
But my client does support all the suggested algorithms:
$ ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
[email protected]
aes128-ctr
... and there are several more.
And if I explicitly specify the algorithm like this:
ssh -vvv -c aes256-cbc [email protected]
I can successfully login to the server.
My ~/.ssh/config doesn’t contain any cipher-related directives (actually I removed it completely, but the problem remains).
So, why client and server can’t decide which cipher to use without my explicit instructions? The client understands that server supports aes256-cbc, client understands that he can use it himself, why not just use it?
Some additional notes:
There was no such problem some time (about a month) ago. I’ve not changed any ssh configuration files since then. I did update installed packages though.
There is a question which describes very similar-looking problem, but there is no answer my question: ssh unable to negotiate – no matching key exchange method found
UPDATE: problem solved
As telcoM explained the problem is with server: it suggests only the obsolete cipher algorithms. I was sure that both client and server are not outdated. I have logged into server (by the way, it’s Synology, updated to latest available version), and examined the /etc/ssh/sshd_config. The very first (!) line of this file was:
Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
This is very strange (the fact that line is very first in the file), I am sure I’ve never touched the file before. However I’ve changed the line to:
Ciphers aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
restarted the server (did not figure out how to restart the sshd service only), and now the problem is gone: I can ssh to server as usual.
The -cbc algorithms have turned out to be vulnerable to an attack. As a result, up-to-date versions of OpenSSH will now reject those algorithms by default: for now, they are still available if you need them, but as you discovered, you must explicitly enable them.
Initially when the vulnerability was discovered (in late 2008, nearly 10 years ago!) those algorithms were only placed at the tail end of the priority list for the sake of compatibility, but now their deprecation in SSH has reached a phase where those algorithms are disabled by default. According to this question in Cryptography.SE, this deprecation step was already happening in year 2014.
Please consider this a gentle reminder to update your SSH server, if at all possible. (If it's a firmware-based implementation, see if updated firmware is available for your hardware.)
Correct answer by telcoM on February 20, 2021
Just add -c param with one of the supported ciphers (aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc):
ssh -c aes256-cbc [email protected]
Answered by Antonio Feitosa on February 20, 2021
The same problem as the OP bugged me for a long time, on a Synology server too, and the ssh -c aes256-cbc diskstation.local has been a useful stop gap measure. But knowing one’s server use obsolete ciphers is not really reassuring.
The real solution is not to wait that Synology updates the firmware (or at least not only), as I naively did for several years know, but to check the configuration of the server. The allowed ciphers are hidden behind Terminal & SNMP>Advanced parameters. Choosing anything would allow more modern ciphers, and anything but low security will deactivate the -cbc ciphers.
Answered by Frédéric Grosshans on February 20, 2021
You can update your ssh configuration from the file located at: /etc/ssh/ssh_config
sudo nano /etc/ssh/ssh_configCiphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbcCtrl + X. Press Enter to save and exit.Answered by Farhan A. Rafi on February 20, 2021
create a file inside ~/.ssh/config and paste below content
Host *
SendEnv LANG LC_*
Ciphers +aes256-cbc
Answered by Yash Jagdale on February 20, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP