OpenSSH announces DSA-removal timeline

Posted Jan 12, 2024 16:00 UTC (Fri) by draco (subscriber, #1792)
In reply to: OpenSSH announces DSA-removal timeline by pizza
Parent article: OpenSSH announces DSA-removal timeline

If they provide legacy support for obsolete crypto forever, nothing will ever change until it's a five alarm fire and lots of people are getting hurt.

And then the bigwigs will solemnly proclaim that security is their top priority despite blatant evidence to the contrary (cf. Boeing re safety).

At least if people get forced to HTTP, they can't pretend they thought it was still secure.

Browsers used to grade connection security quality, but I assume they found that it wasn't an effective lever to get people to improve

OpenSSH announces DSA-removal timeline

Posted Jan 14, 2024 6:52 UTC (Sun) by wtarreau (subscriber, #51152) [Link] (2 responses)

The method that works best to deprecate outdated security mechanisms is adding delays. It continues to work but pisses the users off every time, and gives a strong incentive for updating everything that can be updated. Nobody wants to endure a 5s pause at every connection to a device that can be fixed. When you know the device is unfixable, that's quite annoying but better than not being able to connect.

Note that another method to continue to reach outdated machines is to use a less outdated bouncing machine. I've done this quite a bit, leave an old always-up arm or atom board somewhere with an outdated (hence vulnerable) distro that you don't care about too much, and connect to that one over a modern SSH with ed25519 to bounce to the other one. I had to use that to connect to certain labs whose gateways only supported algorithms my implementation couldn't support in the past :-/

OpenSSH announces DSA-removal timeline

Posted Jan 13, 2025 11:58 UTC (Mon) by akostadinov (guest, #48510) [Link]

Nowadays better use a container image and run ssh from it. You can mount safe local filesystem paths if you need to transfer files.

You can use VPNs to connect to old vulnerable devices. If ISP is providing an insecure router, just use it to forward your traffic through your own secure router.

Sounds like OpenSSH and other crypto-professional teams need to provide more details with such announcements but maybe they don't realize how clueless generally people are about security. I don't exclude myself from this in different areas. Such lingering vulnerable devices are perfect for running somebody's bot farm. And perhaps that's why they became so cheap.

OpenSSH announces DSA-removal timeline

Posted Jan 13, 2025 15:11 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Yeah, I've set up a bastion host with an ancient Firefox to support old SSL ciphers to manage old equipment (APC NMC1 cards) until it ages out. We are just getting around to retiring pre-SSH serial terminal servers from our OOB. When equipment is capable of doing the job it was purchased for, and segmented off with network security controls, it's hard to justify spending capital budget to replace a working thing when there are always higher priority devices which need capacity expansion or are exposed to customer or malicious traffic and should maintain vendor support.

Just migrated to RHEL9 and had to deal with update-crypto-policies and ssh_config to be able to connect to our remaining IOS 12 (and 15?) devices, hopefully they are gone before moving to RHEL11, or we'll need to need to run an old bastion VM on our bastion management hosts. ssh natively supports the idea of a jump host these days so it's possible to integrate with automation just by throwing a few more options (-J iirc).