[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Suggested way to ssh into obsolete devices (with old ssh crypto)?

On Tue, Jul 06, 2021 at 10:18:44PM +0200, tomas@tuxteam.de wrote:
On Tue, Jul 06, 2021 at 02:11:21PM -0400, Michael Stone wrote:


It's entirely too common for obsolete encryption options that are
kept for "compatibility" end up being a vector for compromise, and
entirely reasonable to remove such options in order to provide the
most secure and maintainable tool for the vast majority of users.

That's the attitude of authoritarian software: "my software is smarter
than you".

The authors are free to hold that position, but so am I to utterly
dislike it.

This is ridiculous. If you want something that the maintainers think is unsafe to put in the mainstream distribution you're perfectly free to add (and maintain it) yourself. That's what free software is all about. I personally utterly dislike when people demand that other people provide them with things. But hey, it's a free world--dislike whatever you want.

The only authoritarian thing here is people trying to tell other people what they need to put in the software they maintain.

If you want ancient crypto options, just run an ancient binary.
They're very easy to find in archive.debian.org.

They're not as easy to run as soon as they start being outrun by
their dependencie's versions, and you perfectly know that.

So you want to run obsolete proprietary hardware with no upgrade path, and also complain that the free software is too hard and/or that the ability to make the free software do exactly what you want isn't "easy" enough for you. Seems legit.

Just to be sure that I wasn't dreaming that this wasn't actually a big deal, I just grabbed the openssh-client deb for etch from the archive, along with the library dependencies that couldn't be installed from bullseye (libssl, libkrb5) and it worked fine. If I copy the binary to ssh-oldasdirt and reinstall the current openssh, I can use either the current ssh or ssh-oldasdirt with no issues. If you want it easier than that I'm sure you can hire someone to make a custom repository or even rebuild the old package with a non-conflicting name like ssh-oldasdirt or whatever.

Of course, the real answer is to not purchase products with "secure"
management that can't be upgraded when it becomes "insecure"

See above. To me, this is a dangerous antipattern.

To me, leaving obsolete crypto in a security tool is an antipattern. Experience has shown again and again that this results in security bugs, sometimes really significant ones. Maintainers of such tools need to be responsible in what they release, even if there's a vocal minority that complains about it. The openssh team does a pretty good job of publishing a deprecation schedule *and* sticking to it.

Reply to: