34.Key AbstractDigital Esm W900

OpenSSH will remove DSA keys from its support in the near future. Let's examine the OpenSSH team's reasoning for making this change, the process, and the proposed timeline.

What is the Justification for Removing DSA Keys from OpenSSH Support?

OpenSSHDSA is inherently insecure, being limited to a private key of 160 bits and the use of SHA1 as a digest. Its estimated security is = 80-bit symmetric equivalent.

OpenSSH has been disabling DSA keys as a default since 2015. However, it still offers optional support. DSA is the only mandatory-to-implement algorithm in the SSHv2 RFCs, mostly because alternative algorithms were encumbered by patents when the SSHv2 protocol was designed and specified.

Since then, things have changed. RSA has no restrictions and is widely supported. ECDSA provides significant performance and safety benefits over modp DSA. EdDSA offers further performance and protection improvements over both.

DSA should only be used on deeply-legacy devices at this time. The OpenSSH team no longer believes that the costs associated with maintaining DSA within OpenSSH are justified, and we agree here at LinuxSecurity!

Cryptography library maintainers can remove other SSH implementations.

Process and Proposed Timeline

OpenSSH's next release (due in March of 2024) will still make DSA available by default, but it will be optional during compile time. OpenSSH users and downstream distributors can use this option in order to investigate the impact of DSA's removal on their environment, or hard-deprecate DSA early if desired.

A release of OpenSSH around June of 2024 will change the compile-time setting to disable DSA. Users/distributors can still enable it if necessary.

The DSA code is being removed completely in the first OpenSSH version after January 1, 2025.

Frequently Asked Questions

What happens if my device only supports DSA?

OpenSSH's removal of DSA will not eliminate endpoints that require DSA. Users may still be required to connect to these endpoints. OpenSSH releases in the future will not support DSA. However, older releases and alternative SSH implementations still will.

It is recommended that users who have a need to continue to connect to DSA only endpoints use an older version of OpenSSH for this purpose. This was the recommendation when support for SSHv1 was removed.

For example, Debian maintains a "openssh-client-ssh1" package built from OpenSSH 7.5 for the purpose of connecting to SSHv1 endpoints. It is possible that this package, or something similar, will be enough for DSA-only endpoints.

Isn't OpenSSH in violation of RFC4253 by this?

The OpenSSH team has answered this question with the statement, "We are no further than we were in 2015 when we stopped providing DSA as a default".

Why now? Why not earlier/later?

The OpenSSH team believes that enough time has elapsed since DSA became disabled by default for most users to stop using the algorithm. OpenSSH will also be exploring a post-quantum signature algorithm in the near future, and we are aware of the size and complexity of key/signature codes.

Next Steps: How To Upgrade Your SSH Keys to Ensure They Are Supported

To upgrade SSH keys, follow the steps below:

  1. Generate a new public/private key pair using the ssh-keygen command.
  2. Copy the private key to the remote server using the ssh-copy-id command.
  3. Remove the old key from the remote server by editing the "authorized_keys" file.
  4. Test the new key by trying to connect to the remote server using the public IP address or hostname.

Upgrading your SSH key will improve the security of your network connections and make it more difficult for malicious hackers to gain unauthorized access to your Linux environment.

Have additional questions about upgrading your SSH keys? Please reach out to us on X @lnxsec- we're here to help! We'd also love to hear your thoughts on this upcoming change.

Stay safe out there, OpenSSH users!