For example debian 9
1 2 |
$ ssh -Vxx SSH protocols 1.5/2.0, OpenSSL 0x0090700f |
So what the hell is it? What’s causing it? Well, a modern operating system like Debian Jessie are packaged with OpenSSH 6.7 or newer – and OpenSSH 6.7 disables some ciphers, as per changelog http://www.openssh.com/txt/release-6.7 As Russel rightly pointed out in the comments section below ‘”kex” is “key exchange”.x
Solution:
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 the client, merely 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
1 |
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:
1 2 3 |
ssh -Q cipher ssh -Q mac ssh -Q kex |
I know more about ssh ciphers, macs, kex now that I ever wanted to know.