7 ms·

Don't remove it, add a "--yes-I-really-want-to-use-DSA" option. We sometimes have to connect to older systems that use insecure keys, and no those systems cann

by rwmj 3y ago

Don't remove it, add a "--yes-I-really-want-to-use-DSA" option. We sometimes have to connect to older systems that use insecure keys, and no those systems cannot be fixed (old network hardware, doing V2V conversions from old RHEL, etc)

throw0101d 3y ago
* 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.
- Sesse__ 3y ago
  So basically, the recommended solution is “instead of us maintaining DSA support, everybody should maintain their own fork of an old OpenSSH version”?
  - extinctpotato 3y ago
    Yes.
  - caboteria 3y ago
    https://xkcd.com/1172/ https://xkcd.com/1172/
  - morelisp 3y ago
    Not "everybody", just "not us".
  - mynameisvlad 3y ago
    DSA support isn’t free. It requires maintenance. We aren’t entitled to lifetime support.
    - pkaye 3y ago
      Is there active work being done on the DSA code recently?
      - timv 3y ago
        The main source code for DSA is here https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-dss.c 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.
  - crote 3y ago
    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.
  - quickthrowman 3y ago
    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.
    - womod 3y ago
      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.
      - quickthrowman 3y ago
        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.
  - Macha 3y ago
    So the people providing software for free should support things indefinitely because the people you've paid money for those things won't?
    - Sesse__ 3y ago
      Well, they are seemingly explicitly calling out Debian as your new favorite place for SSHv1 support :-) Who are no more paid than they are.
      - lilyball 3y ago
        I imagine the "people you've paid money" refers to the vendors of the old hardware that requires DSA.
    - lnxg33k1 3y ago
      Oh this is beautiful and perfect, couldn’t have said it better, people are so awesome in their entitlement
  - nayuki 3y ago
    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.
  - halJordan 3y ago
    If you have no problem using an obviated algorithm why is there suddenly a problem using an obviated ssh? These complaints almost beggar belief.
    - deleted 3y ago
      [deleted]
    - Jenda_ 3y ago
      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 https://news.ycombinator.com/item?id=38963372).
  - kelnos 3y ago
    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.
  - Panino 3y ago
    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 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 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.
  - 127361 3y ago
    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.
  - chasil 3y ago
    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.
  - throw0101d 3y ago
    > […] “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."
- anfogoat 3y ago
  > ...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.
  - rsaxvc 3y ago
    You can use a Windows build on wine.
  - throw0101d 3y ago
    > […] but this idea of "just" using past releases seems theoretical. * https://packages.debian.org/search?keywords=openssh-client-ssh1 https://packages.debian.org/search?keywords=openssh-client-s...
mschuster91 3y ago
> We sometimes have to connect to older systems that use insecure keys, and no those systems cannot be fixed 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".
- patrakov 3y ago
  Evil manager from hell: nope, you can still reconfigure the <thing> to use telnet. At least it would be then plain obvious that there is no security, instead of the current security theater with DSA.
  - throw0101d 3y ago
    > Evil manager from hell: nope, you can still reconfigure the <thing> to use telnet. Possible reply for some folks: our cyber-insurance mandates encryption for all logins.
    - midasuni 3y ago
      Telnet uses double rot 13 encryption.
  - robertlagrant 3y ago
    Or just use an existing version of OpenSSL. They aren't sending a terminator back in time to purge DSA support from all of time.
    - oynqr 3y ago
      That would be a better timeline than this one.
  - acdha 3y ago
    The grind of audit requirements tends to mean those managers are a lot more willing to do the right thing now – it’s less risk than putting your name in writing on the thing which the auditors / insurance company will be using to fail you.
csdreamer7 3y ago
They said it has been disabled by default for years. There is a cost to maintaining it and a security risk for untested code. I agree with this removal. > 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?
- Arnt 3y ago
  I tried to look for active DSA keys now, and didn't see anything but don't feel confident that there are in fact none. Hmm.
  - SoftTalker 3y ago
    Yeah old switches, BMCs, and other embedded SSH servers often use it. Really that stuff is too old to be using in a production environment but sometimes reality is different. 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.
    - Arnt 3y ago
      I don't want to be nervous about whether I need it, I'd prefer an alert when it's used, turned on by default for a year.
      - roblabla 3y ago
        It's been disabled by default since 2015 - you need to enable support for them in the config file, otherwise the client will error out. In other words, if you don't have the following line in your ~/.ssh/config, you're fine: PubkeyAcceptedKeyTypes=+ssh-dss
        Arnt 3y ago
        That's great. Do you know what happens when an old unattended client with an old old key connects to a new server?
Hizonner 3y ago
I don't think I've ever seen an actual DSA key in use in SSH, and I was using it before there was an RFC. Even the oldest actual deployments tended to ignore the patent and use RSA. > 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.
- o11c 3y ago
  When I got into Linux around 2010 there was something that encouraged me to make a DSA key instead of an RSA one ...
  - Macha 3y ago
    Arch Wiki was still recommending dsa around that time: https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66753 https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66...
    - dharmab 3y ago
      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.
  - Piskvorrr 3y ago
    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.
- arisudesu 3y ago
  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.
_jal 3y ago
Worse that old network gear is technically incompetent business partners. 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.
- freedomben 3y ago
  Indeed. I can't imagine what it's going to be like 10 years from now when the mountain of SaaS offerings start disappearing and there'se zero options to "run it a little longer"
laserbeam 3y ago
Write a guide for how to obtain and install an old version of openssh for that usecase. Make it available within your org. Problem solved.
Lord_Zero 3y ago
Use an older version of OpenSSH then.
harshreality 3y ago
Couldn't you grab an old distro image (or livecd), install/run it in a VM, and use that? Archive.org even has an iso of redhat 6.2. :)
shawnz 3y ago
It's already disabled by default, which is basically what you are asking for. However, disabling it by default doesn't solve the problem of the maintenance burden. That's what this change is meant to solve: > [...] we no longer consider the costs of maintaining DSA in OpenSSH to be justified.
- V-eHGsd_ 3y ago
  exactly. and if the added burden of having to maintain (or more likely, just download) a version of ssh that supports dsa means that some piece of legacy hardware is no longer cost effective, then it's probably time to upgrade that legacy hardware. 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.
dehrmann 3y ago
Do they support telnet?
pbhjpbhj 3y ago
But then Linus from LTT will end up using DSA by accident! /s

by rwmj 3y ago

throw0101d 3y ago

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

Sesse__ 3y ago
So basically, the recommended solution is “instead of us maintaining DSA support, everybody should maintain their own fork of an old OpenSSH version”?
- extinctpotato 3y ago
  Yes.
- caboteria 3y ago
  https://xkcd.com/1172/ https://xkcd.com/1172/
- morelisp 3y ago
  Not "everybody", just "not us".
- mynameisvlad 3y ago
  DSA support isn’t free. It requires maintenance. We aren’t entitled to lifetime support.
  - pkaye 3y ago
    Is there active work being done on the DSA code recently?
    - timv 3y ago
      The main source code for DSA is here https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-dss.c 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.
- crote 3y ago
  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.
- quickthrowman 3y ago
  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.
  - womod 3y ago
    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.
    - quickthrowman 3y ago
      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.
- Macha 3y ago
  So the people providing software for free should support things indefinitely because the people you've paid money for those things won't?
  - Sesse__ 3y ago
    Well, they are seemingly explicitly calling out Debian as your new favorite place for SSHv1 support :-) Who are no more paid than they are.
    - lilyball 3y ago
      I imagine the "people you've paid money" refers to the vendors of the old hardware that requires DSA.
  - lnxg33k1 3y ago
    Oh this is beautiful and perfect, couldn’t have said it better, people are so awesome in their entitlement
- nayuki 3y ago
  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.
- halJordan 3y ago
  If you have no problem using an obviated algorithm why is there suddenly a problem using an obviated ssh? These complaints almost beggar belief.
  - deleted 3y ago
    [deleted]
  - Jenda_ 3y ago
    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 https://news.ycombinator.com/item?id=38963372).
- kelnos 3y ago
  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.
- Panino 3y ago
  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 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 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.
- 127361 3y ago
  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.
- chasil 3y ago
  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.
- throw0101d 3y ago
  > […] “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."
anfogoat 3y ago
> ...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.
- rsaxvc 3y ago
  You can use a Windows build on wine.
- throw0101d 3y ago
  > […] but this idea of "just" using past releases seems theoretical. * https://packages.debian.org/search?keywords=openssh-client-ssh1 https://packages.debian.org/search?keywords=openssh-client-s...

mschuster91 3y ago

> We sometimes have to connect to older systems that use insecure keys, and no those systems cannot be fixed 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".

patrakov 3y ago
Evil manager from hell: nope, you can still reconfigure the <thing> to use telnet. At least it would be then plain obvious that there is no security, instead of the current security theater with DSA.
- throw0101d 3y ago
  > Evil manager from hell: nope, you can still reconfigure the <thing> to use telnet. Possible reply for some folks: our cyber-insurance mandates encryption for all logins.
  - midasuni 3y ago
    Telnet uses double rot 13 encryption.
- robertlagrant 3y ago
  Or just use an existing version of OpenSSL. They aren't sending a terminator back in time to purge DSA support from all of time.
  - oynqr 3y ago
    That would be a better timeline than this one.
- acdha 3y ago
  The grind of audit requirements tends to mean those managers are a lot more willing to do the right thing now – it’s less risk than putting your name in writing on the thing which the auditors / insurance company will be using to fail you.

csdreamer7 3y ago

They said it has been disabled by default for years. There is a cost to maintaining it and a security risk for untested code. I agree with this removal. > 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?

Arnt 3y ago
I tried to look for active DSA keys now, and didn't see anything but don't feel confident that there are in fact none. Hmm.
- SoftTalker 3y ago
  Yeah old switches, BMCs, and other embedded SSH servers often use it. Really that stuff is too old to be using in a production environment but sometimes reality is different. 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.
  - Arnt 3y ago
    I don't want to be nervous about whether I need it, I'd prefer an alert when it's used, turned on by default for a year.
    - roblabla 3y ago
      It's been disabled by default since 2015 - you need to enable support for them in the config file, otherwise the client will error out. In other words, if you don't have the following line in your ~/.ssh/config, you're fine: PubkeyAcceptedKeyTypes=+ssh-dss
      - Arnt 3y ago
        That's great. Do you know what happens when an old unattended client with an old old key connects to a new server?

Hizonner 3y ago

I don't think I've ever seen an actual DSA key in use in SSH, and I was using it before there was an RFC. Even the oldest actual deployments tended to ignore the patent and use RSA. > 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.

o11c 3y ago
When I got into Linux around 2010 there was something that encouraged me to make a DSA key instead of an RSA one ...
- Macha 3y ago
  Arch Wiki was still recommending dsa around that time: https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66753 https://wiki.archlinux.org/index.php?title=SSH_keys&oldid=66...
  - dharmab 3y ago
    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.
- Piskvorrr 3y ago
  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.
arisudesu 3y ago
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.

_jal 3y ago

Worse that old network gear is technically incompetent business partners. 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.

freedomben 3y ago
Indeed. I can't imagine what it's going to be like 10 years from now when the mountain of SaaS offerings start disappearing and there'se zero options to "run it a little longer"

laserbeam 3y ago

Write a guide for how to obtain and install an old version of openssh for that usecase. Make it available within your org. Problem solved.

Lord_Zero 3y ago

Use an older version of OpenSSH then.

harshreality 3y ago

Couldn't you grab an old distro image (or livecd), install/run it in a VM, and use that? Archive.org even has an iso of redhat 6.2. :)

shawnz 3y ago

It's already disabled by default, which is basically what you are asking for. However, disabling it by default doesn't solve the problem of the maintenance burden. That's what this change is meant to solve: > [...] we no longer consider the costs of maintaining DSA in OpenSSH to be justified.

V-eHGsd_ 3y ago
exactly. and if the added burden of having to maintain (or more likely, just download) a version of ssh that supports dsa means that some piece of legacy hardware is no longer cost effective, then it's probably time to upgrade that legacy hardware. 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.

dehrmann 3y ago

Do they support telnet?

pbhjpbhj 3y ago

But then Linus from LTT will end up using DSA by accident! /s