Sep 142015
 

If you run ancient operating system with an old version of SSH client then you are going to hit this “No Kex Alg” problem soon.

have u tried

For example Solaris 9

$ ssh -Vxx
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f

So what a hell is it? What’s causing it? Well, modern operating system like Debian Jessie are packaged with OpenSSH 6.7 or newer  – and Openssh 6.7 disables a number of ciphers, as per changelog http://www.openssh.com/txt/release-6.7  As Russel rightly pointed out in comments section below ‘”kex” is “key exchange”.x

 

So it’s time to upgrade your client! However, if for some bizarre reasons those pesky sysadmins are refusing to upgrade client software then that leaves you with two options:

  • if you have physical access to client simply spill coffee or some other beverage on it (alright, just joking)
  • or edit /etc/ssh/sshd_config on the server, append the following line and restart sshd daemon
KexAlgorithms diffie-hellman-group1-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

 

Now your old client should be able to connect to server plus you have successfully created security vulnerability on your machine. How exciting!

If you’re still dying to know what mechanisms your system supports run:

ssh -Q cipher
ssh -Q mac
ssh -Q kex

I know more about ssh ciphers, macs, kex now that I ever wanted to know.