openssh bugs - Sep 2025 - [Bug 3861] New: The build option --enable-dsa-keys no longer works.

https://bugzilla.mindrot.org/show_bug.cgi?id=3861

            Bug ID: 3861
           Summary: The build option --enable-dsa-keys no longer works.
           Product: Portable OpenSSH
           Version: 10.0p2
          Hardware: ix86
                OS: All
            Status: NEW
          Severity: critical
          Priority: P5
         Component: Build system
          Assignee: unassigned-bugs at mindrot.org
          Reporter: barry.nelson at amobiledevice.com

## Rationale for Maintaining DSS Key Support in OpenSSH Clients

**Document Version:** 1.0
**Date:** 2025-09-08
**Audience:** OpenSSH Developers, Security Engineers, System
Administrators

**1. Executive Summary**

The proposal to remove support for Digital Signature Standard (DSS)
keys in OpenSSH clients has raised concerns regarding accessibility and
compatibility. While DSS is considered cryptographically weak by modern
standards, outright removal poses significant risks to users and
systems that still rely on it. This document outlines the rationale for
retaining DSS support, balances the security concerns with practical
considerations, and proposes a phased deprecation strategy instead of
immediate removal.

**2. Background: DSS and its Current Status**

DSS was a widely adopted standard for digital signatures, particularly
in government and enterprise environments, during the 1990s.  Its
primary weaknesses are its use of SHA-1 hashing algorithm and the
relatively short key lengths available (typically 1024 bits).  Modern
cryptographic standards like ECDSA and Ed25519 offer substantially
improved security and performance. However, a complete and immediate
transition away from DSS remains impractical.

**3. Arguments for Retaining DSS Support (Client-Side)**

*   **Compatibility with Legacy Systems:**  A substantial number of
legacy systems, particularly within government and enterprise
infrastructure, still utilize DSS for authentication. These systems may
be difficult or costly to upgrade or replace in the short term. 
Removing DSS support from the client would effectively prevent access
to these systems.  This would create significant operational
disruptions.
*   **User Migration Time:** Forcing a migration away from DSS requires
a substantial investment of time and resources for individual users and
organizations.  A sudden removal of client support would disrupt
workflows and potentially create accessibility barriers. Gradual
deprecation allows for a more controlled transition.
*   **Server-Side Considerations:**  While server-side DSS support
*should* be phased out aggressively, the timeline for this transition
is typically longer than that for the client due to the interconnected
nature of server infrastructure. Client removal should *follow* server
deprecation, not precede it.
*   **Minimal Client-Side Risk:** The client-side risk associated with
DSS support is comparatively low.  The primary vulnerabilities lie in
the server-side implementation of DSS and the algorithms used to
generate and verify DSS signatures. The client's role is primarily to
*verify* the signature, not to *generate* it. While a compromised
client could be used maliciously, this is a general risk applicable to
any supported key type.
*   **Continued Use in Embedded Systems**: DSS may still be used in
some
specialized embedded systems and devices for authentication.

**4. Proposed Mitigation Strategies & Phased Deprecation**

Rather than immediate removal, we propose a phased deprecation
approach:

*   **Warning Messages:** Introduce prominent warning messages in the
client when DSS keys are used, clearly indicating the known
cryptographic weaknesses.  These warnings should be visible to all
users, regardless of their technical expertise.
*   **Limited Algorithm Support:**  Restrict the supported hashing
algorithms used with DSS keys to SHA-256 or better, to mitigate the
vulnerability associated with SHA-1.
*   **Documentation:** Provide comprehensive documentation detailing
the risks associated with DSS and outlining best practices for
migration to stronger key types.
*    **Monitoring & Reporting:** Implement monitoring and reporting to
track the usage of DSS keys, which can inform the timeline for further
deprecation steps.

**5. Conclusion**

While DSS is a legacy standard, abruptly removing support for it in the
OpenSSH client would introduce significant operational and
accessibility
challenges.  A phased deprecation approach, combined with clear
warnings, continued monitoring, and support for stronger algorithms,
strikes a balance between security best practices and the practical
realities of a complex IT landscape.  Client-side DSS support should
remain, but its usage should be actively discouraged and closely
monitored.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3861

Barry Nelson <barry.nelson at amobiledevice.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|ix86                        |All

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3861

Barry Nelson <barry.nelson at amobiledevice.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |barry.nelson at amobiledevice.
                   |                            |com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3861

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Barry Nelson from comment #0)
> ## Rationale for Maintaining DSS Key Support in OpenSSH Clients
> 
> **Document Version:** 1.0
> **Date:** 2025-09-08
> **Audience:** OpenSSH Developers, Security Engineers, System
> Administrators
> 
> **1. Executive Summary**
> 
> The proposal to remove support for Digital Signature Standard (DSS)
> keys in OpenSSH clients has raised concerns regarding accessibility
> and compatibility. While DSS is considered cryptographically weak by
> modern standards, outright removal poses significant risks to users
> and systems that still rely on it. This document outlines the
> rationale for retaining DSS support, balances the security concerns
> with practical considerations, and proposes a phased deprecation
> strategy instead of immediate removal.
The deprecation *was* phased.  It's been disabled by default at run
time since version 7.0 (2015), the removal has been warned in the
release notes a year prior to removal (version 9.7, 2024-03-11) then
again in version 9.8 (2024-07-01), then it required explicit enabling
at compile time six months prior to removal (9.9, 2024-09-19) then
finally removed in 10.0 (2025-04-09). 

You can see these all here: https://www.openssh.com/releasenotes.html. 
Quoting the 9.7 release notes (2024-03-11):


Future deprecation notice
========================
OpenSSH plans to remove support for the DSA signature algorithm in
early 2025 and compile-time disable it later this year.

DSA, as specified in the SSHv2 protocol, is inherently weak - being
limited to a 160 bit private key and use of the SHA1 digest. Its
estimated security level is only 80 bits symmetric equivalent.

OpenSSH has disabled DSA keys by default since 2015 but has retained
run-time optional support for them. DSA was the only mandatory-to-
implement algorithm in the SSHv2 RFCs[3], mostly because alternative
algorithms were encumbered by patents when the SSHv2 protocol was
specified.

This has not been the case for decades at this point and better
algorithms are well supported by all actively-maintained SSH
implementations. We do not consider the costs of maintaining DSA in
OpenSSH to be justified and hope that removing it from OpenSSH can
accelerate its wider deprecation in supporting cryptography
libraries.

This release makes DSA support in OpenSSH compile-time optional,
defaulting to on. We intend the next release to change the default
to disable DSA at compile time. The first OpenSSH release of 2025
will remove DSA support entirely.
> *   **Compatibility with Legacy Systems:**  A substantial number of
> legacy systems
The previous versions of the client don't magically cease to exist. 
These legacy versions of OpenSSH can be used to connect to those legacy
systems.  Debian, for example, has openssh-client-ssh1 which supports
both ssh-dss and SSH1.
> *   **User Migration Time:** Forcing a migration away from DSS
> requires a substantial investment of time and resources for
> individual users and organizations.  A sudden removal of client
> support would disrupt workflows and potentially create accessibility
> barriers. Gradual deprecation allows for a more controlled
> transition.
The gradual deprecation started in 2015.  Users had a literal decade.

[...]
> [...] Restrict the supported hashing
> algorithms used with DSS keys to SHA-256 or better, to mitigate the
> vulnerability associated with SHA-1.
ssh-dss is only specified with SHA-1 (RFC4253 section 6.6).  What you
are proposing is an entirely new public-key authentication method.  We
already have public-key authentication methods that are both better
than ssh-dss and already widely deployed.
> *   **Documentation:** Provide comprehensive documentation detailing
> the risks associated with DSS and outlining best practices for
> migration to stronger key types.
People don't seem to read the documentation we already provide so I
don't see how that would make any difference.
> *    **Monitoring & Reporting:** Implement monitoring and reporting
> to track the usage of DSS keys, which can inform the timeline for
> further deprecation steps.
Stock OpenSSH code has no kind of telemetry that would allow this type
of monitoring.
> **5. Conclusion**
[...]
> Client-side DSS support [...] should be actively discouraged
It's extremely actively discouraged.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3861

--- Comment #2 from Barry Nelson <barry.nelson at amobiledevice.com> ---
You are missing the point. It should have been completely disabled and
removed from the server side for some time before removing it on the
client side. It is still often needed on the client side for connecting
to older equipment where the server software is in firmware and cannot
be updated.

What options do we have?

Buy new equipment? (Send me a check please... :) )
Use telnet? (Like that's better?)
Run the older ssh software? (That seems counter productive to getting
the new version accepted.)

I propose that the client should build with DSA disabled in the config,
and the server side should have it disabled and removed completely by
default.

Apparently the CFLAG -DWITH_DSA still works, BUT that enables it for
BOTH the client and the server, although it is off by default in the
config for both. The configure script option --enable-dsa-keys no
longer works for client or server.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3861

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX
                 CC|                            |djm at mindrot.org

--- Comment #3 from Damien Miller <djm at mindrot.org>
---
> What options do we have?
1. Go to your vendors and request they update their SSH
implementations.
2. Use an alternate client (e.g. PuTTY) or an old version of the
OpenSSH client that you retain for communicating with legacy devices
(Debian has the openssh-client-ssh1 package that include DSA support)
3. Use an alternate access mechanism, e.g. serial, telnet, etc.

The code for DSA has already been fully deleted
(https://github.com/openssh/openssh-portable/commit/a32d28d7925). We
have no intention of bringing it back.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3861

--- Comment #4 from Barry Nelson <barry.nelson at amobiledevice.com> ---
Those vendors include small companies named HP and Cisco. :(
This really should have been dropped from the server code completely
first.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.