sshd and kex algorithms
 

A Kex Algorithm is a Key Exchange algorithm. I won't bore you with the details, but they are crucial to sshd negotiations. Apparently this problem is so obscure it gets empty results pages from google.

I have 2 trusty old boxes with Mandrake10 installed in about 2005. They're beginning to show their age. I just acquired a newish box that I'm installing freshest and newest of everything.

Old boxes run sshd -V: OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090703f

New box runs sshd -V: OpenSSH_6.8p1, OpenSSL 1.0.2a 19 Mar 2015

A bit of a difference, huh? New box shells into old boxes fine. Not so the other way around.

Here's some lovely debug output of the situation:
After much learning about ssh in general, I discover the 2 versions of sshd cannot agree on which cipher to use. I think about it and come to this conclusion: why teach the old dog new tricks, when I can teach the new dog old tricks.

I find a tidbit on some site that says you can add a Ciphers line in /etc/sshd/sshd_config like this:
So I add it to new box sshd_config. Now my lovely debug output looks like this:
"No kex alg"? Huh?

This is where I started getting empty google results. Finally, on this site, I found this tidbit:
Into my sshd_config it goes and Voila!
Now they agree on ciphers and kex algs. Perfect.

Peace and cheer.

It's not a problem ;) it's supposed to be that way.

You're using 6.8 in the new machine. In 6.7 those old algorithms were removed because they are unsafe: http://www.openssh.com/txt/release-6.7

Adding them back in rather defeats the purpose of using SSH. Then there is the old unsupported OS there. So you might find it better to upgrade your systems to a maintained version of your distro with a recent implementation of SSH.

Indeed. I read some of that stuff about keeping ahead of the NSA. Hey, now they've infiltrated the kernel with SELinux. The great Kernel War is right around the corner :). I can just see geeks with pocket protectors shivving each other in the dimly lit corridors of the CS Faculty building the night before a new release... :D

I kinda figured that there was a reason for dropping the older algorithms, thanks for the link. I wanted to put this here for the benefit of others who may encounter the same problem issue, however unlikely.

In my defence, all I do is shell into the various PCs on my LAN, so I could be using telnet, but now I know a lot more about a tool I take for granted. As a matter of fact, with all the trouble getting ssh working full duplex through a PC generation gap, I seriously thought about it. My router keeps all ports <10000 closed, so getting pounded by script kiddies is not an issue... well... I trust my router, and I watch my logfiles... occasionally... *shrug*

Yeah, if I needed to shell in from outside the LAN I would certainly make sure my ssh was new, clean and mean. This begs the question:

Any idea if there's a way in sshd_config to specify something like, eg:
?

Peace and cheer.

Match would have been the way to do that, but neither KexAlogrithm nor Ciphers are in the subset of keywords that Match can modify. But one way around that would be to make a second sshd_config file set to listen on a different port but otherwise using the settings you want. You'd then need an init script to launch that second instance of sshd using that second sshd_config to make it automatic on boot like the other services.