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.
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-nistp512,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.