Hacker News Reader

Comment by throw0101d | Hacker News Reader

    * 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.

View on HN

So basically, the recommended solution is “instead of us maintaining DSA support, everybody should maintain their own fork of an old OpenSSH version”?

Yes.

https://xkcd.com/1172/

Not "everybody", just "not us".

DSA support isn’t free. It requires maintenance. We aren’t entitled to lifetime support.

Is there active work being done on the DSA code recently?

The main source code for DSA is here

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.

Nah, it simply won't be maintained by anyone - just like the gear still requiring DSA. Nobody is going to stop you from using the last DSA-included OpenSSH build for the next few decades, just don't expect any updates.

Probably not since replacing the ancient equipment only capable of DSA is likely cheaper than maintaining an OpenSSH fork.

I’m going to assume that the hardware that supports DSA only has long been abandoned by its manufacturer.

You'd be suprised, the shear amount of black box vendor nonsense out there borders on astronomical. Weird telco stuff, old cisco hardware, BMCs in servers, it would mean gutting probably millions of dollars of equiment. It's stupid, but throwing the baby out with the bathwater over openssh won't make anyone happy.

Some day that stuff is going to unexpectedly break and cause more problems. There are two choices; pain now when you have a chance to plan, or more pain later when you’re forced to react.

So the people providing software for free should support things indefinitely because the people you've paid money for those things won't?

Well, they are seemingly explicitly calling out Debian as your new favorite place for SSHv1 support :-) Who are no more paid than they are.

I imagine the "people you've paid money" refers to the vendors of the old hardware that requires DSA.

Oh this is beautiful and perfect, couldn’t have said it better, people are so awesome in their entitlement

I mean that's the deal you enter into with open-source software. In exchange for having full access to the source code for free, you should have no expectations of entitlement of new features or continued support from upstream.

If you have no problem using an obviated algorithm why is there suddenly a problem using an obviated ssh? These complaints almost beggar belief.

Because the old algorithm only endangers the communication and the remote device (and this may even not be the case, as such an old device should not be exposed to the world), while the old client may compromise security of the local computer. (fortunately, bugs in SSH client are uncommon; with e.g. browsers it's a different story)

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).

More or less, yes. You get OpenSSH for free; you are not paying for it, and not paying to support its development. Critically, you are not paying for its developers to support old, obsolete, broken cryptography. Keeping DSA would be an added maintenance burden that the OpenSSH team just isn't prepared to continue taking on.

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.

I started using OpenSSH in OpenBSD 2.6, released in 1999, and I don't believe I've ever even used a DSA key. Here's a quote from the release notes of OpenSSH 1.2.3, released March 6, 2000:

"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.

Or just not upgrading the entire operating system, say for example in an industrial control system. Because we find that this old version of SSH no longer compiles on modern operating systems. Thus making the whole system more vulnerable, so that it can keep communicating with some 10-year old device that cannot be easily replaced.

Again, air-gapping and limiting the physical extent of the network to the room or building would provide significant protection against attacks here.

You could alternately install alternate SSH clients (non-OpenSSH) for this purpose.

  $ 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.

The focus for SSH is safety. These others shift more to broad compatibility; I do wish they would throw warnings for weak ciphers.

> […] “instead of us maintaining DSA support, everybody should maintain their own fork of an old OpenSSH version”?

"Instead of of us maintaining DSA for a smaller and smaller population, that small/shrinking population should take some responsibility on themselves."

> ...past releases and alternate SSH implementations...

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.

You can use a Windows build on wine.

> […] but this idea of "just" using past releases seems theoretical.

* https://packages.debian.org/search?keywords=openssh-client-s...

Reply on news.ycombinator.com