* What if I have devices that only support DSA?
Removing DSA from OpenSSH will not remove endpoints that require DSA
from the world and users may still need to connect to them. Although
new releases of OpenSSH will no longer support DSA, past releases and
alternate SSH implementations will continue to do so.
We recommend that users with an ongoing need to connect to DSA-only
endpoints maintain a legacy release of an OpenSSH client for this
purpose, similar to what was recommended when support for the SSHv1
protocol was removed.
For example, Debian maintains a "openssh-client-ssh1" package built
from OpenSSH 7.5 for the purpose of connecting to SSHv1 endpoints.
This package or something similar is likely to be sufficient for
DSA-only endpoints too.https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ss...
You can see that the team did a big refactor of key handling about 14 months ago that required multiple rounds changes to the DSA code.
That's the sort of cost that legacy code brings - it's not about make changing to the DSA feature, it's about the cost of maintaining the DSA code when you make changes across the codebase.
In the original mail, DJM mentions that they'd like to explore a post-quantum signature algorithm. Adding that to the codebase is likely to require some broad changes to key management, and that will be less work if there are fewer supported key types.
I’m going to assume that the hardware that supports DSA only has long been abandoned by its manufacturer.
Of course a reasonable solutions would be to run it in some sandbox/VM.
Additionally, the old client will be difficult to use in a current OS because of library and general system incompatibility (Debian with openssh-client-ssh1 is a rare exception, and it's just a command-line ssh, not the library mentioned in https://news.ycombinator.com/item?id=38963372).
If there's a wide need for it, hopefully everybody won't maintain their own fork; all that's necessary is people band together and maintain a single fork.
"Any user can create any number of user authentication RSA keys for his/her own use. Each user has a file which lists the RSA public keys for which proof of possession of the corresponding private key is accepted as authentication. User authentication keys are typically 1024 bits."
ECDSA key authentication was added in OpenSSH 5.7, released in January 2011:
https://www.openssh.com/txt/release-5.7
Ed25519 key authentication was added in OpenSSH 6.5, released in January 2014:
https://www.openssh.com/txt/release-6.5
And RSA support has been around since the beginning.
I think the overlap between "must use DSA keys" and "uses modern OpenSSH" is practically zero, and the level of pushback in this thread doesn't correspond to reality.
Again, air-gapping and limiting the physical extent of the network to the room or building would provide significant protection against attacks here.
$ rpm -qi putty | tail -1
Putty is a SSH, Telnet & Rlogin client - this time for Linux.
$ rpm -qi dropbear | tail -2
Dropbear is a relatively small SSH server and client. It's particularly useful
for "embedded"-type Linux (or other Unix) systems, such as wireless routers.
"Instead of of us maintaining DSA for a smaller and smaller population, that small/shrinking population should take some responsibility on themselves."
Absolutely not faulting the devs in any way for wanting to rid themselves of having to maintain the DSA bits, but this idea of "just" using past releases seems theoretical. I'd be surprised if I managed to compile an OpenSSH release from even just a couple of years ago. There'd be some glibc incompatibility or something equally gnarly.
* https://packages.debian.org/search?keywords=openssh-client-s...
> systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc)
If you can't update a system, you have no business exposing it to a network. Full stop.
Otherwise known as “security”, yes
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?
Or you could... not do that... and expect to be hacked, over and over.
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.
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?
It's already insecure, so don't update.
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.
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.
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.
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. :]
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.
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.
But the OpenSSH devs are specifically saying “just use the old version if you need 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.
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?
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.
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.
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.
> [...] we no longer consider the costs of maintaining DSA in OpenSSH to be justified.
and you (the general you) should probably be thanking the openssh folks for all the work they've done for the last 8+ years keeping the dsa code around which allowed you (the general you) to externalize that cost.
> those systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc)
How old are these old systems? V2V conversions? What version of RHEL?
Hmm.
Keep an older release of openssh if you need it for those. No sense keeping obsolete code for obsolete use cases in the codebase, it's a maintenance an testing headache and a security risk.
PubkeyAcceptedKeyTypes=+ssh-dss
You presumably have a configuration option allowing the old encryption in your server configuration, which is your warning that you're running a legacy system.
At least there's now a way to tell management "hey, there is no choice, <thing> must be replaced because we literally won't be able to connect to it any more".
Possible reply for some folks: our cyber-insurance mandates encryption for all logins.
Speaking in very general terms, let's just say that we've had to maintain an extremely locked down machine running a version of sshd from about a decade ago hosted in its own DMZ, all for one particular partner. It is monitored for everything we can think of, and I still find myself stressing about possible ways someone could escape from that machine - I'm mostly surprised we haven't been attacked through them yet.
Their problem is they bought proprietary software that's no longer supported, and look at it as a one-time purchase rather than a forward commitment. Our problem is the nontechnical relationship is important and we can't cut them off.