When I got into Linux around 2010 there was something that encouraged me to make a DSA key instead of an RSA one ...

Encouraged, sure. Last time I saw something that actually required DSA, it was literally decades old, and that encounter didn't happen in this decade either. I do have some tools for ancient machines, such as with SSHv1 support, but it's more akin to archeology than access to working machines.

Arch Wiki was still recommending dsa around that time: https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66...

There was a lot of suspect advice on the TLS and SSH pages. I did a pass a couple of years ago, updating the recommendation to EC keys if possible and RSA otherwise, with links to relevant academic sources.

Don't confuse the Internet and networks please. Older machines are completely fine to be used in private firewall-protected networks, as long as they're facing only LAN. SSH still be required to access them.

They’re the perfect target to hit when looking to pivot across/through a network though. Not to mention the risk of being hit during a ransomware event. Keeping around legacy hardware/software is the pinnacle of fuck around and find out.

You're offering hypothetical, worst-case whataboutisms. In the real world, any shop that isn't stupid will use defense-in-depth to protect the unupgradable bits.

> You're offering hypothetical, worst-case whataboutisms

Otherwise known as “security”, yes

Whatever. Imaginary paranoia strawman that is the wrong kind of paranoia: the unactionable, ego-based kind. You completely ignored defense-in-depth approaches like airgapped systems and adding additional layers and protections to mitigate your hypothetical non sequitur. If you fail at these then you don't actually understand security and are just arguing without a leg to stand on.

Your attitude here is confusingly hostile.

But sure! If I have a server I currently use OpenSSH to connect then I certainly _could_ airgap the machine and require anyone using it to be in physical proximity to it. But don't you think that might be unrealistic in the vast majority of scenarios?

If you have a server that you can't secure properly because it only supports obsolete, known-broken cryptography, then yes, absolutely, you should airgap it or find some other way to protect it.

Or you could... not do that... and expect to be hacked, over and over.

But the airgap scenarios are very real, and they make it more difficult to just go online and grab an old ssh client that will do the job.

It seems that the argument for removing support for the old algorithms involves the need to maintain them in the new releases. This only becomes a problem if/when the code and/or regression testing is refactored. So eventually the effort required to remove support becomes less than the effort needed to continually support the old algorithms.

The OpenSSH maintainers can of course do anything they like, but removing support for legacy algorithms is basically passing the problem down to (probably less capable) users who are stuck without the ability to connect to their legacy systems.

You do recall that the source control doesn't disappear, even after support is pulled? I've built ancient versions (specifically in case of SSH, to get arcfour for whatever convoluted system); this wasn't a simple operation, but feasible, even for someone with just a general knowledge of SSH and its build toolchain.

Maintaining code also takes time and effort: smaller codebase, effort better spent. If it's too costly to just keep an ancient version of ssh around, and even too costly to pay someone to do that for you, how's it suddenly NOT too costly for the maintainers? If you're going to the lengths of having a special airgapped network of legacy systems, how do you NOT have the tools to use with those systems?

I think you missed my remark about the inability to pull an old version from within an airgapped environment. It's usually still possible, but the level of difficulty can vary depending upon security requirements. Imagine a security officer refusing to approve the introduction of an older and insecure program into a secure environment.

Assuming the airgapped systems are currently working, nothing will stop them working as they are in the future.

It's already insecure, so don't update.

I think that you are making a lot of assumptions about the purpose of airgapped systems. Why would you assume that no changes or development work occurs? In my experience, there are often legacy components that are a critical part of a larger system. Also, in my experience, such environments are often segregated into smaller enclaves. Some of those may have the most up-to-date tools available.

I very much did not miss that: "how do you NOT have the tools to use with those systems?"

The hypotetical airgapped secure environment, running an old version of SSH (which only supports DSA) has no requirements for a SSH client, just "eh, just bring whichever openssh that you happen to have, and let's assume it works"? That's a failure to plan: if your network is airgapped, you can't expect to have client software in compatible versions appear out of thin ether.

I appreciate that you're trying to drill down and improve your understanding of such environments, which you obviously do not have much knowledge of. I'm limited in how much specific information I can disclose, but I'm certain that I'm not the only one who has worked in these environments and faced these challenges.

Here's a hypothetical example of a situation closely matching some of my experiences: A long-term support contract exists for some legacy system that cannot be updated because it is under configuration control. The contract involves peripheral development activities, which are best done with the most modern tools available. The whole environment is airgapped, and has security protocols that require security updates to the peripheral development systems, and these are done under a strict and bureaucratic review process. The legacy system interoperates with the development system via a single network connection, which is monitored by a separate entity. (The system is airgapped, but is part of a larger airgapped network, and is protected from unauthorized access even within the airgapped environment.) So you've got a new environment talking to a legacy environment via SSH, and they need to share a common security algorithm. If a new development environment is spun up, and its SSH client does not support the legacy algorithm, then a long and complex delay occurs in which multi-level approvals are required from bureaucrats who are generally not qualified to understand the problem, and are thus inclined to deny approval, to introduce the legacy SSH client software, which will be compared with the modern SSH client for any change history related to security issues, which would include the deletion of these security algorithms. The legacy SSH client would be assumed to be a security risk by the ignorant bureaucrats, and a months-to-years-long process ensues to convince them otherwise.

So, this essentially boils down to "someone else, ANYONE not me, should simplify the bureaucratic process for me (because there's the actual issue), and I've picked OpenSSH maintainers for the job. Oh, and for free, too."

You're not expecting the toolchain to appear out of thin ether, that was my misunderstanding: you fully expect volunteers to provide you with it for free, for your highly specific situation; in return, you offer...nothing? That's not a very enticing trade.

I sense there may be other ways around this, but those would a) cost you (in a broad sense; after all, the infrastructure is supposedly critical) money, and/or b) cost you (perhaps in a stricter sense) time, effort, perhaps influence. I agree that's rather inconvenient, given the alternative.

Personally, I'm able to do what is needed to make things work. My whole point was that by pushing the work from the OpenSSH dev team to downstream, the sum total of work will increase.

> Otherwise known as “security”, yes

Content-free, arrogant, hostile quip that you chose to start.

> Your attitude here is confusingly hostile.

I don't know, perhaps it's you who is projecting and has the problem.

Have a nice day and a happy new year. :]

Security is about risk profiling and making good tradeoffs between things like cost, convenience, timeliness, and confidentiality/integrity/availability. All computer security is basically futile because in the face of a sufficiently motivated attacker, so chasing perfection is wasting your time.

If you're doing home security, you don't use armed guards and reinforced steel doors, with the defense of depth of an extra-secure bulletproof safe room, because the security would cost more than the value it provides. You might use a good deadbolt though.

The same goes for computer security. In combination with certain security approaches like air gapping, a technically insecure out of band management network can quickly become a dramatically less plausible means of being exploited compared to say - unsexy things like email phishing attacks. So replacing all your servers with ones with supported out of band management systems can simply not be a reasonable priority to have.

Instead we'll have the company going bust for constantly having to replace critical machinery in the name of "security". Sometimes it is necessary to keep old equipment around and it can be secured using physical methods (an air-gap).

Old outdated versions of OpenSSH are are also fine to use in private protected environments where security isn't a concern so there's not much problem

Exactly. There are untold 10's to 100's of millions of critical infrastructure systems that cannot be upgraded containing insecure and horrible SSH implementations. Defense-in-depth by layers of other security measures and isolation permits them to be reasonably secure for their use prior to lifecycle replacement where possible.

Furthermore, no one should place remote access servers on the internet and should instead place them on a private, internal network behind an infrastructure VPN-jumpbox such as OpenVPN or Wireguard.

Only a few extremist developers in control of all of their own software and who don't have to interact with anything in the real world can maintain the idealistic purity to forever run only the latest version of everything.

> idealistic purity to forever run only the latest version of everything

But the OpenSSH devs are specifically saying “just use the old version if you need this”?

You're sweeping several huge assumptions under the rug. While it might work for the moment incidentally but it isn't a long-term solution.

It seems only fair to me that if someone is insisting that they must connect to ancient systems that they should be expected to use only-slightly ancient software to do so. Or fork it, of course. If the team doesn’t want to be responsible for maintenance you’re welcome to take it on.

I'm not sure that I understand this.

The openssh developers supporting outdated systems and software forever also isn't a long term solution. Why should they pay this cost, but not you (or your company)?

If you can keep unsupported hardware in operation, why can't you keep a containerized openssh image around, or maybe a VM image, or ideally a statically linked executable?

Maybe your company can hire an expert in software archival to set this up and maintain it if needed, or an extra developer to maintain an openssh fork that supports your environment.

Expecting other people (who you don't even pay) to support your outdated systems doesn't really make sense.

> If you can't update a system, you have no business exposing it to a network. Full stop.

Ah, another i-know-better tells everyone how to do the things.

Okay, I cut the CAT5 cable with a wire cutter with nonconductive grips (shoulda be safe!), you don't whine what you can't access your mortage/medical history/whatever else thing and should physically be present at the facility to receive the documents.

Deal?

Deal, Because I don't want my mortgage, medical history, and other important and sensitive documents exposed to the internet by companies that can't be bothered to secure their systems.

The alternative is these systems never get updated until the next big "welp, the private information of 10 million people just got leaked to the open web". For example, equifax.

The sibling thread is for you.

> If you can't update a system, you have no business exposing it to a network. Full stop.

What about isolated networks, a single Ethernet switch for example, used for industrial automation? We can't keep replacing equipment every 5 years because they keep changing crypto protocols.

Many industrial networking protocols have no security at all. No encryption. Not even a password. They achieve their security by being disconnected from the outside world, constrained to a single room or building. If an attacker can get physical access to the wires, then we have a lot more to worry about than network security.

In this case though literally what are you even complaining about? If it's physically isolated so you don't need to update the old hardware, then you don't need to update OpenSSH either. Right? You can just leave whatever terminal you use right now on whatever it runs right now forever.

That's the basic discontinuity here. The reason one would want to keep OpenSSH updated and continuing to receive development work is for use in a networked environment without full physical security from the world. If you have something stuck on DSA it shouldn't have any exposure to the world. So there's no problem here. At the very least one could softgap with old-ssh-in-VM that is completely restricted in what it can access.

Sorry, I likely screwed up my reasoning in that comment, I was under a lot of pressure at the time. The option to delete my post is gone, so I can't remove it.