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 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
rijndae[email protected]
... 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.

  • 1
    Related - unix.stackexchange.com/questions/333728/… - shows info on how to disable.
    – slm
    Jul 28, 2018 at 19:01
  • 4
    I had the same problem and found you can easily change this in the web interface (since ssh didn't work for me...), but going to "Terminal --> advanced settings" in the DSM control panel, and selecting the "high" profile -- for some reason, I had a manual selection enabled there... I sure hope that's something I did and forgot about, and not something done by a previous DSM update! -- choices are now aes128-ctr, aes128-gcm, aes192*, aes256*, dhge-sha256, curve25519-sha256, hmac-sha2-256
    – Zak
    Jan 1, 2019 at 12:39
  • I have a similar problem but the server offers me no ciphers. I get 'Their offer: none'. What could be going wrong?
    – borizzzzz
    Dec 4, 2022 at 13:41

4 Answers 4


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

  • 2
    This is true and correct. But I can't update the firmware unless I can SSH to it first.
    – Yanzzee
    Dec 16, 2021 at 17:40

create a file inside ~/.ssh/config and paste below content

Host *
  SendEnv LANG LC_*
  Ciphers +aes256-cbc

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.

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.

  • At least "High" should be selected on the Synology. Nov 17, 2021 at 21:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .