I am trying to ssh to remote machine, the attempt fails:
$ ssh -vvv firstname.lastname@example.org 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@example.com,firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,email@example.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,email@example.com debug2: compression stoc: none,firstname.lastname@example.org 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@example.com aes128-ctr ... and there are several more.
And if I explicitly specify the algorithm like this:
ssh -vvv -c aes256-cbc firstname.lastname@example.org
I can successfully login to the server.
~/.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:
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:
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.