E.g.
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@x.x.x.x
> We are also likely to start exploring a post-quantum signature algorithm soon and are mindful of the overall size and complexity of the key/signature code.
Vulnerabilities like heartbleed and Log4Shell is what you get when you have limited developer capacity but insist on endlessly keeping legacy code around.
Yea, it is annoying to keep your systems up to date, and yes some (let’s be honest very small but vocal minority of) users cannot update and will be left in the cold. But security is everyone’s responsibility at all layers, and even stable OSS doesn’t owe it to you to support legacy cases at the expense of just moving forward.
It sucks but I do believe hamstringing users with complex and unsupported use cases is (unfortunately) the right thing to do. The less support these old and vulnerable systems get, the more annoying or impossible they will be to maintain, and the more inclined users will be to shut down systems that probably should have been deprecated decades ago.
Bracing myself for ire…
Whole stuff is about security and that kind of implies some “probably best before” tags anyway. Sacrificing security is not worth it and your reasoning is sane.
I understand the security aspect, I know that telnet is insecure, but I know when, how and why it's insecure and use it accordingly... just add some -use-bad-crypto flag, maybe even make it as a module/plugin, and leave it working as it did.
In the realm of operating systems and protocols, that sounds absolutely ideal. Microsoft has the right approach here.
Imagine if every software was coded by this logic... nobody uses BMP images anymore? Just remove them from gimp... if users want BPM support, they'll use gimp 1.x. Security? Unencrypted http is insecure, just remove support for http from firefox/chrome... if users need to use http, they'll just uninstall the current version, backup their profile, install an old version, that doesn't support the lastest tls standards, open that website, copy the text they need from there into notepad, uninstall the old version, install the new version, restore their profile, open gmail and paste the text to an email... oh wait, you've missed something and need to copy some more text... whoops, back to uninstalling.
You would install Nix and run something similar to "nix run nixpkgs-23.11#openssh <address>"
export LC_ALL=C
nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/2322899a1fa85f6547004b2829af81e7b444f506.tar.gz -p openssh
ssh -V
OpenSSH_6.1p1, OpenSSL 1.0.0i 19 Apr 2012
Also, ossified infrastructure is not a good thing. That's yet another problem we need to solve as a civilisation. Not everything new is good but some old things are genuinely inferior and should be replaced.
Granted, I speak very generally while this thread pertains specifically to OpenSSH. I also understand the added burden of maintaining more and more code, which end-users might not properly appreciate.
Ultimately though, people use computers to achieve something and expect software to help them in that endeavour. Software cutting off features, and thus the users, will always draw ire because it inhibits people from using computers to achieve something.
Arguments from devs that software must move forward mean nothing to users who want or need to do something right now.
For comparison, Microsoft deprecated SMBv1 the same year OpenSSH deprecated DSA and removed it in 2016.
If you look at any company’s internal tooling, this is universally well understood. Migrations and upgrades are a pain in the ass in the short term but a net positive in the long term. I don’t want to break their systems, but software evolves over time and if you expect something that worked once to always work, that’s not realistic expectations for any software I’ve ever been a part of.
Think about it: A computer is a tool, but most tools never "stop working" per se. That screwdriver? It used to work when it was first invented and it will still work a thousand years from now. That car? Keep it maintained and it will take you places for at least the better part of a century. That boat? We can keep boats floating forever.
Computers are one of the few, if not only, piece of tool that demands it be replaced every few years, and it probably hasn't even broken down yet which would merit a replacement.
Maybe it did not and will not -- old screwdriver is probably flat blade, now people use Philips or Pozidriv screws and in some time most will be Torx.
> That car? Keep it maintained and it will take you places for at least the better part of a century. That boat? We can keep boats floating forever.
The same: the fuel and oil is changing (maybe you will not even be able to source gasoline in 2050 if everyone migrated to electric vehicles), and specific spare parts are no longer manufactured.
I guess with large old boats also come expensive support contract - similar to paying someone for a super-long-term individual software support.
> Computers are one of the few, if not only, piece of tool that demands it be replaced every few years, and it probably hasn't even broken down yet which would merit a replacement.
Computers are also relatively new and quickly advancing in features, while the other examples you have mentioned were mostly "stable" for 100 years.
On the other hand, macOS is also pretty common on desktops and they don't honor backwards compatibility very much.
What system do you still need to access where your user has a DSA key?
Why can't you generate an RSA-2048 key, like you should've done over a decade ago?
The server might've generated a DSA host key, along with an RSA host key, but that won't prevent you from connecting, it'll just use the RSA one if your client only supports RSA (of {RSA, DSA}). If you purposely disabled RSA host keys so that it only has a DSA host key, it's time to generate an RSA host key and configure its use, just like an RSA key for the account you need to continue to access.
If you don't know of any such systems but you're worried you might run into one in the future, nothing is stopping you from using an old distro livecd to access such an old and insecure ssh server.
That's the rationale. It helps motivate people like you to finally upgrade the ssh servers on these systems, or at least replace the keys with non-dsa ones.
And it'll always be possible to connect to these, just not with current openssh. There's old ssh, and there's other ssh implementations still.
Senior Engineer: “Should we write that code?”
Staff Engineer: “We should delete that code."