7 ms·

I don't understand the rationale for removing support for any algorithm. I can understand disabling support, but why remove it? I have often needed to connect

I don't understand the rationale for removing support for any algorithm. I can understand disabling support, but why remove it? I have often needed to connect to ancient systems that only support very old algorithms. From a modern ssh client, I will usually need to specify the needed algorithm on the ssh command line in order to connect. E.g. ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@x.x.x.x

halJordan 3y ago
Two of the big reasons are to keep code clean and security. Reference the latest linux kernels, and how they achieved most of their performance increases (hint they removed old code and simplified the codepaths). The second reason is to prevent it's use. It is not just good enough to consider the "happy path." There are unhappy paths where an adversary is able to make use of these abilities. When the aggregate unhappy paths overwhelm the single happy path, it's time to bite the bullet.
- mistrial9 3y ago
  ... plus hardware vendors, some very large companies and security consultants financially benefit from churn
  - woodruffw 3y ago
    Consultants might benefit, I don't think that hardware vendors (especially network appliance vendors) really do: these kinds of changes are purely an expense for them, since they have to reallocate engineers to fix things that were otherwise on "autopilot" for their support contracts.
imrejonk 3y ago
They provide a good reason for completely removing the DSA code: > 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.
- appplication 3y ago
  I am a proponent of ruthlessly deprecating, deleting, and decommissioning. I fully understand there are a LOT of downsides with this approach, but legacy code is such a huge and difficult to quantify drain on developer productivity, in addition to a vector for exploitation and other bugs. 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…
  - szundi 3y ago
    Problem is that lots of cases just cannot be replaced, period. But probably those people will keep around some old ubuntu and will be hacked through those, also not removing but keeping around after the deadline until it needs work would also make sense. If work would be needed, then just remove. We might have like 2-10 years before that happens. 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.
    - ajsnigrutin 3y ago
      Yep, I work with some old industrial hardware, and most of it is stuck in the year it was made and never upgraded... rs232, rs485, telnet, etc., is a thing you see very often. Now with modern networks, you can isolate those machines and the machines controlling/monitoring them pretty efectively, so those segments never touch the internet, but you still need to connect to those devices and use them. Telnet and rs* just work, because noone complained about zero security there and wanted them removed... but now we're removing stuff that's still in use on newer devices that are not even at hal their 20, 30, 40year lifespans. 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.
tasty_freeze 3y ago
In such situations you can build (and maybe just download) a version of OpenSSH from before this feature was removed.
deleted 3y ago
[deleted]
forward1 3y ago
Engineer: “I can write that code.” Senior Engineer: “Should we write that code?” Staff Engineer: “We should delete that code."
- pixl97 3y ago
  Salespeople, I done sold a feature that needs that code.
snvzz 3y ago
>I have often needed 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.
harshreality 3y ago
The announcement explains the rationale. If you don't like it, volunteer to pay for ongoing maintenance. 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.
- deleted 3y ago
  [deleted]

halJordan 3y ago

Two of the big reasons are to keep code clean and security. Reference the latest linux kernels, and how they achieved most of their performance increases (hint they removed old code and simplified the codepaths). The second reason is to prevent it's use. It is not just good enough to consider the "happy path." There are unhappy paths where an adversary is able to make use of these abilities. When the aggregate unhappy paths overwhelm the single happy path, it's time to bite the bullet.

mistrial9 3y ago
... plus hardware vendors, some very large companies and security consultants financially benefit from churn
- woodruffw 3y ago
  Consultants might benefit, I don't think that hardware vendors (especially network appliance vendors) really do: these kinds of changes are purely an expense for them, since they have to reallocate engineers to fix things that were otherwise on "autopilot" for their support contracts.

imrejonk 3y ago

They provide a good reason for completely removing the DSA code: > 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.

appplication 3y ago
I am a proponent of ruthlessly deprecating, deleting, and decommissioning. I fully understand there are a LOT of downsides with this approach, but legacy code is such a huge and difficult to quantify drain on developer productivity, in addition to a vector for exploitation and other bugs. 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…
- szundi 3y ago
  Problem is that lots of cases just cannot be replaced, period. But probably those people will keep around some old ubuntu and will be hacked through those, also not removing but keeping around after the deadline until it needs work would also make sense. If work would be needed, then just remove. We might have like 2-10 years before that happens. 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.
  - ajsnigrutin 3y ago
    Yep, I work with some old industrial hardware, and most of it is stuck in the year it was made and never upgraded... rs232, rs485, telnet, etc., is a thing you see very often. Now with modern networks, you can isolate those machines and the machines controlling/monitoring them pretty efectively, so those segments never touch the internet, but you still need to connect to those devices and use them. Telnet and rs* just work, because noone complained about zero security there and wanted them removed... but now we're removing stuff that's still in use on newer devices that are not even at hal their 20, 30, 40year lifespans. 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.

tasty_freeze 3y ago

In such situations you can build (and maybe just download) a version of OpenSSH from before this feature was removed.

deleted 3y ago

[deleted]

forward1 3y ago

Engineer: “I can write that code.” Senior Engineer: “Should we write that code?” Staff Engineer: “We should delete that code."

pixl97 3y ago
Salespeople, I done sold a feature that needs that code.

snvzz 3y ago

>I have often needed 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.

harshreality 3y ago

The announcement explains the rationale. If you don't like it, volunteer to pay for ongoing maintenance. 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.

deleted 3y ago
[deleted]