2

I'm running Kali Linux with ssh -V of OpenSSH_7.7p1 Debian-3, OpenSSL 1.0.2o 27 Mar 2018. I tried to SSH to a server (a hacking challenge) and got the response Unable to negotiate with ********* port 22: no matching cipher found. Their offer: 3des-cbc,blowfish-cbc,cast128-cbc,idea-cbc.

I've tried editing my /etc/ssh/ssh_config file to add one of those four to my Ciphers listing, but the I got the message /etc/ssh/ssh_config line 38: Bad SSH2 cipher spec 'aes128-cbc,blowfish-cbc'.

I've also tried specifying a Cipher with -c, eg ssh ********* -c blowfish-cbc, but then I get Unknown cipher type 'blowfish-cbc'.

Interestingly, when I tried -c with 3des-cbc, I actually got a different response:

 ssh ********* -c 3des-cbc

 Received disconnect from ********* port 22:2: Handshake failed
 Disconnected from ********* port 22

Am I correct in thinking that my late version of SSH doesn't allow using those ciphers? And how would I get around that?

Update: I've been asked to clarify how this isn't a duplicate of this question. The solution given there was to update the server's config, which is obviously not an option available to me here. Also, there, the -c option was working, and the only question was why it was neccesary, whereas here it doesn't appear to be.

However, I did learn from there the ssh -Q cipher command, which does in fact respond that my ssh client supports 3des-cbc, though not the other 3. This might imply that in fact -c 3des-cbc is the right approach, and I just need to debug it further to discover why the handshake fails. So maybe it does contain my answer, albeit very indirectly.

Yaakov Saxon
  • 121
  • 1
  • 4
  • I think [idea](http://www.quadibloc.com/crypto/co040302.htm) has some [security problems](https://www.cvedetails.com/cve/CVE-2001-1470/) and [here](https://security.stackexchange.com/questions/180544/is-there-a-list-of-weak-ssh-ciphers) ... so, perhaps the goal is find some exploit for one or two of the weak ciphers that have been enabled on the server... – RubberStamp Nov 16 '18 at 16:19
  • That's interesting. Would that work as an attack on the server itself, or just on the secure/private nature of ssh? To put it another way, would such an attack be of any use if there are no other users ssh'ing into that server (as is, I believe, the case with this particular challenge)? – Yaakov Saxon Nov 16 '18 at 16:24
  • > Would that work as an attack on the server itself,.... It wouldn't be fun to give away too many details... it's a challenge, right? ... Have a look at [cbc](https://www.kb.cert.org/vuls/id/958563/) – RubberStamp Nov 16 '18 at 16:39

1 Answers1

1

Check your ssh_username in your .json files. I am fairly certain that this is the route to take. Knowing the one cipher got the handshake to fail tells me it is in the handshake itself and that is all in the .json files. The others wern't even tryin to negotiate. Good luck.

Michael Prokopec
  • 2,202
  • 7
  • 21