mjhjmtu

I am trying to ssh to remote machine, the attempt fails:

$ ssh -vvv admin@192.168.100.14
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: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
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
rijndael-cbc@lysator.liu.se
aes128-ctr
... and there are several more.

And if I explicitly specify the algorithm like this:

ssh -vvv -c aes256-cbc admin@192.168.100.14

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.)