TransWikia.com

ssh Unable to negotiate: "no matching cipher found", is rejecting cbc

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.

5 Answers

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

  1. Launch a terminal.
  2. Paste the line into the terminal: sudo nano /etc/ssh/ssh_config
  3. Enter your password. Press Enter. SSH config file will be displayed.
  4. Un-comment the line: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
  5. Press Ctrl + 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

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP