Timeline to remove DSA support in OpenSSH

Original Article ↗ Hacker News Discussion ↗

OpenSSH plans to fully remove support for the legacy DSA public-key algorithm by early 2025, following years of it being disabled by default and long-standing guidance from NIST to phase out 1024‑bit DSA. Commenters weigh the security and maintenance benefits of deleting obsolete cryptography—freeing the project to simplify key handling and prepare for post‑quantum algorithms—against the operational pain for organizations that still must reach unupgradable hardware, industrial systems, and air‑gapped environments. The prevailing view is that those with such legacy needs should pin or containerize old OpenSSH releases or use alternative clients, rather than expect upstream to maintain weak algorithms indefinitely.

Deprecation timeline & history

  • OpenSSH plans a phased removal of DSA:
    • 2024-03: DSA optional at compile time, enabled by default.
    • 2024-06: DSA optional, disabled by default.
    • 2025-01: DSA removed from OpenSSH.
  • Commenters note this follows long-standing guidance:
    • NIST recommended ending 1024‑bit DSA use by 2010.
    • OpenSSH never supported larger DSA keys and already disabled DSA by default in OpenSSH 7 (2015).

Rationale for removing DSA

  • Main reasons cited:
    • DSA in SSHv2 is limited to 1024‑bit public / 160‑bit private keys and considered weak.
    • Maintaining legacy code is costly, especially during refactors and when adding new algorithms (e.g., possible post‑quantum signatures).
    • Old, rarely tested code paths are seen as security risks.

Impact on legacy systems

  • Some users still need DSA to reach:
    • Old network hardware, switches, BMCs, iLO, telco gear, industrial control, old RHEL, and partner systems.
  • Concern: “cannot be fixed” systems may remain in service for decades, especially in industrial and critical infrastructure.
  • Others argue such systems should be isolated, air‑gapped, or replaced; if they can’t be updated, they shouldn’t be exposed to wider networks.

Responsibility and entitlement

  • Strong theme: open-source maintainers are not obligated to support obsolete crypto indefinitely.
  • Counterpoint: pushing deprecation cost downstream increases total work and can be hard in heavily regulated or bureaucratic environments.
  • Some argue a “dangerous/legacy” flag or plugin model would be preferable to complete removal.

Alternatives & workarounds

  • Suggestions:
    • Keep an older OpenSSH client (possibly in a VM, container, or special “legacy jump host”).
    • Use distro packages that preserve old protocols (e.g., ssh1 client).
    • Use alternate SSH implementations (Dropbear, PuTTY), or even telnet in tightly controlled networks.
  • Concerns raised about compiling very old OpenSSH on modern systems and about security of legacy clients.

Related crypto discussions

  • Clarifications on DSA parameters and its inherent 160‑bit private key under the SSHv2 spec used.
  • Discussion of other key types: RSA, ECDSA, Ed25519.
  • Side thread noting major clouds: AWS adds Ed25519 support; Azure and some GCP components reportedly still lack it.