Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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:
Apparently this problem is so obscure it gets empty results pages from google.
...
I find a tidbit on some site that says you can add a Ciphers line in /etc/sshd/sshd_config like this:
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.
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...
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:
Code:
if (client = 192.168.1.*) {
KexAlogrithm blahblah
Ciphers blahblah
}
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.
Last edited by Turbocapitalist; 06-16-2015 at 08:20 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.