October 30, 2014

SSH - no matching cipher found

Edit: Please do your research, this may re-introduce vulnerable ciphers -- i don't have time to be safe. lmao.  
Please reference https://stribika.github.io/2015/01/04/secure-secure-shell.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After a recent update of either Debian testing (Jessie) or OSX (Mavericks), I could no longer SSH from OSX into my Debian testing boxes.
I really don't know which OS update was at fault, but when I tried to SSH into my Debian testing boxes, i received the following message:
no matching cipher found: client blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
I can't have that -- my daughter needed to play on the minecraft server and she NEEDED TO PLAY NOW!
What this told me is that that my client (OSX) expected blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc but my server (Debian) supported aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
That sucks; stupid computer! (Wow, had not said that once since leaving Windows®)
Via web searches, I found that I could force a cipher like so: ssh -c aes128-ctr username@hostname so i did successfully. (I could just as well used ssh -c none username@hostname, but that's risky)
Once logged into my Debian box(es), I edited the ssh daemon config:
sudo nano /etc/ssh/sshd_config
and added the following to the bottom:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
As you can see, since I didn't know if there is an order of preference or not, I erred on the safe side and added the previously supported server ciphers before the client's expected ciphers.
Afterward I had to restart and verify the SSH Daemon:
sudo service sshd restart ; sudo service sshd status
On my OSX client, I tried to SSH and it complained WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! .. Oh my lord the world will end.
An easy fix was ssh-keygen -R hostname, where hostname was my Debian's hostname or IP obviosuly.
Now it worked as expected (and should have never failed in the first place).
-end-
But Daddy, you forgot the minecraft server... START THE MINECRAFT SERVER NOW!
~~~
As always, good luck!

Please consider crypto tipping:
  

12 comments:

  1. Thank you! Get this same error message after I updated my OS X Yosemite to latest beta 10.10.1 and tried to ssh (mosh) to my Debian Box. With your instructions I fixed it :)

    ReplyDelete
  2. Thanks for this, Steronius! I had the strangest problem trying to log in to an OSX development MBP from a newly acquired Macbook Air created by cloning (w Carbon Copy Cloner) the disk on the aforementioned MBP, so you can imagine my surprise when the cipher used by the original could not be matched by the clone. I have no idea why this should have worked: the cloning process was obviously imperfect, but I don't know where it might have failed. The thing is it did work!

    Thanks again.

    ReplyDelete
  3. This just saved my butt... needed to SCP a file from a broken linux based IPS appliance to my mac.... Thanks!

    ReplyDelete
  4. Seems like my issues with OSX 10.11 was aes128-cbc when trying to use SCP to transfer files from some networking devices to OSX.

    Appreciate the tip on this!

    ReplyDelete
  5. I follow this procedure in my ubuntu 16.04 Desktop afer installing openssh-server. But I got an error messages: "no hex alg", and cannot connect. What's wrong?.

    ReplyDelete
    Replies
    1. from a quick search i saw "no kex alg" and resources suggest an issue with host keys.
      look at [https://discourse.osmc.tv/t/ssh-login-no-kex-alg/2971/5] and [http://forums.macnn.com/79/developer-center/347192/ssh-error-no-kex-alg/] which MAY lead you in a direction.

      This might work too:
      ssh -o 'HostKeyAlgorithms ssh-rsa,ssh-dss' user@host

      Delete
  6. So what i've found out is that arcfour and blowfish-cbs are undesired and potentially a security issue. Your best bet is to remove those two from the above instruction.

    I do not know if arcfour256 and arcfour128 are also undesired or not, but this URL [http://www.sgvulcan.com/2014/10/21/latest-openssh-disables-arcfour-and-blowfish-cbc/] reports that arcfour256 is the fastest cypher for file transfers. (Maybe add it as the first cypher?)

    ReplyDelete
    Replies
    1. According to Nessus, arcfour128 and arcfour256 are weak ciphers and should not be used.

      Delete
  7. For me, what fixed what to add this lines to /etc/ssh/sshd_config:

    Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192
    -cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

    KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exch
    ange-sha1,diffie-hellman-group1-sha1

    HostkeyAlgorithms +ssh-dss

    ReplyDelete
  8. https://stribika.github.io/2015/01/04/secure-secure-shell.html

    ReplyDelete
  9. Thanks for this. Helped me solve an issue copying via SCP from Linux box to a Cisco router.

    ReplyDelete
  10. Thanks, that you remember me, tu ACTIVATE Adblock... I hate begging...

    ReplyDelete

Comments, Suggestions or "Thank you's" Invited! If you have used this info in any way, please comment below and link/link-back to your project (if applicable). Please Share.
I accept Bitcoin tips of ANY amount to: 1GS3XWJCTWU7fnM4vfzerrVAxmnMFnhysL
I accept Litecoin tips of ANY amount to: LTBvVxRdv2Lz9T41UzqNrAVVNw4wz3kKYk