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.
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:
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 :)
ReplyDeleteThanks 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!
ReplyDeleteThanks again.
This just saved my butt... needed to SCP a file from a broken linux based IPS appliance to my mac.... Thanks!
ReplyDeleteSeems like my issues with OSX 10.11 was aes128-cbc when trying to use SCP to transfer files from some networking devices to OSX.
ReplyDeleteAppreciate the tip on this!
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?.
ReplyDeletefrom a quick search i saw "no kex alg" and resources suggest an issue with host keys.
Deletelook 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
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.
ReplyDeleteI 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?)
According to Nessus, arcfour128 and arcfour256 are weak ciphers and should not be used.
DeleteFor me, what fixed what to add this lines to /etc/ssh/sshd_config:
ReplyDeleteCiphers 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
https://stribika.github.io/2015/01/04/secure-secure-shell.html
ReplyDeleteThanks for this. Helped me solve an issue copying via SCP from Linux box to a Cisco router.
ReplyDeleteThanks, that you remember me, tu ACTIVATE Adblock... I hate begging...
ReplyDelete