|
|
Subscribe / Log in / New account

OpenSSH announces DSA-removal timeline

OpenSSH announces DSA-removal timeline

Posted Jan 11, 2024 23:18 UTC (Thu) by gus3 (guest, #61103)
In reply to: OpenSSH announces DSA-removal timeline by pizza
Parent article: OpenSSH announces DSA-removal timeline

Just because DSA is weak, and we shouldn't be using it any more, does that mean all of OpenSSH is now off-limits? Hardly.


to post comments

OpenSSH announces DSA-removal timeline

Posted Jan 11, 2024 23:40 UTC (Thu) by pizza (subscriber, #46) [Link] (10 responses)

> Just because DSA is weak, and we shouldn't be using it any more, does that mean all of OpenSSH is now off-limits? Hardly.

Pray tell, how exactly are we to use DSA-lacking OpenSSH to communicate with DSA-only gear?

It's easy to say "you shouldn't be using X any more" when you aren't having to pay for X's replacement.

OpenSSH announces DSA-removal timeline

Posted Jan 12, 2024 0:31 UTC (Fri) by hmanning77 (subscriber, #160992) [Link] (3 responses)

You wouldn't, but you would keep an old version of OpenSSH around if you need it. The announcement even notes that Debian provides a package for people who still need to connect using the SSHv1 protocol.

OpenSSH announces DSA-removal timeline

Posted Jan 12, 2024 5:59 UTC (Fri) by lkundrak (subscriber, #43452) [Link]

I'm not sure if my distro provides anything similar, but I got accustomed to using dropbear's dbclient to connect to gear OpenSSH is no longer able to. No idea if it supports DSA though.

I guess there might be other SSH clients out there which might be used for the same purpose. PuTTY maybe?

OpenSSH announces DSA-removal timeline

Posted Jan 13, 2024 16:31 UTC (Sat) by mgb (guest, #3226) [Link] (1 responses)

I tried Debian's openssh-client-ssh1 yesterday. Unfortunately it uses the same /etc/ssh/ssh_config as does Debian's openssh-client but ssh1 doesn't understand modern algorithms so it took some fiddling to switch back and forth between the modern ssh and older ssh1 commands even though they can be co-installed.

OpenSSH announces DSA-removal timeline

Posted Jan 14, 2024 8:51 UTC (Sun) by cjwatson (subscriber, #7322) [Link]

Yeah, it wasn't so much of a problem at the time of the split but it is now. I might have a look into getting it to use separate config files.

OpenSSH announces DSA-removal timeline

Posted Jan 12, 2024 2:49 UTC (Fri) by geofft (subscriber, #59789) [Link] (2 responses)

You are not expected to use DSA-lacking OpenSSH. There are more options in the world than just telnet and the version of OpenSSH that will be released next year. In fact, you're using one of those options right now!

There is a very well-written section in the announcement to which you are replying that answers your exact question. For your convenience, here is a copy of that section:

 * 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.
(In particular, if you're considering telnet as a possible option, then clearly you don't care that much about security, and so running an outdated OpenSSH version shouldn't be a concern.)

OpenSSH announces DSA-removal timeline

Posted Jan 12, 2024 9:33 UTC (Fri) by Sesse (subscriber, #53779) [Link] (1 responses)

There are different risks. Using telnet means the conversation with the device, including passwords, is not private to a listener on the network. Using an old SSH client may mean that your local machine is vulnerable to an attacker, should it have a buffer overflow or similar. (It may _also_ mean that the conversation with the device is not private to a listener on the network, or it may mean that it is not private to NSA if they are prepared to invest a couple of million dollars in it.)

OpenSSH announces DSA-removal timeline

Posted Jan 12, 2024 9:43 UTC (Fri) by tomsi (subscriber, #2306) [Link]

How is this different? Isn't it the ssh server that is the attack vector? So you run the latest most secure SSH server to be safe.

And only use the DSA client to connect to DSA equipment.

OpenSSH announces DSA-removal timeline

Posted Jan 15, 2024 5:20 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

> It's easy to say "you shouldn't be using X any more" when you aren't having to pay for X's replacement.

Then pay someone to maintain SSH with DSA. OR return the favor of the community-maintained SSH, and maintain an open-source one. Not mutually exclusive.

OpenSSH announces DSA-removal timeline

Posted Jan 15, 2024 12:32 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

> It's easy to say "you shouldn't be using X any more" when you aren't having to pay for X's replacement.

It's easy to say "you should support X forever" when you don't have to pay for the cost of ongoing support.

OpenSSH announces DSA-removal timeline

Posted Jan 15, 2024 14:25 UTC (Mon) by pizza (subscriber, #46) [Link]

> It's easy to say "you should support X forever" when you don't have to pay for the cost of ongoing support.

Ahem.

Telling folks what they "should" be doing is not "paying the cost of ongoing support"

...and I say that as someone that actively maintains software and drivers for equipment that was EOL'd well over a decade ago.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds