When I started dealing with *nix servers, openssh servers came with dsa as well as rsa host keys, with openssh clients preferring the rsa key. These days openssh servers have dsa, rsa as well as ecdsa host keys, with openssh clients preferring the ecdsa host key.

To what extent do I still need/want to have openssh configured to provide dsa host keys?

Mostly wondering in regards to non-openssh client implementations.

  • Laziness. I support an application whose engineers have been distributing DSA keys for 10 years... but there's no reason to anymore. The notes below about compatibility are correct. – ewwhite Apr 25 '14 at 12:08

I can't think of anything widely used that lacks support for at least RSA, and really if you are using a terminal emulator on windows (for example) that only supports DSA you should stop using it and download putty, or update it.

The option is there to provide compatibility. However, it also adds to your security surface; an attacker could weaken your cryptography by convincing a client to only declare support for DSA. This scenario is rather far-fetched. If it concerns you, then you should disable DSA.

The only scenario I can imagine that would likely result in a serious compromise is if one of your users used a DSA keypair on an untrusted or compromised computer which always negotiated DSA and generated duplicate ephemeral values for creating DSA signatures; the result would be that the user's key could be compromised, but it doesn't seem like this is the path of least resistance for an attacker. Unless your system is used by international spies, you probably don't need to worry about it. See this question on one of our sister sites: https://security.stackexchange.com/q/29262/12223.

There isn't really a direct way to disable DSA. Debian bug 528046 proposes it and provides a patch (for an option PubKeyTypes), and met with support, but has not been actioned since 2009, with no evidence of anything upstream.

| improve this answer | |
  • There's a way to disable DSA now, and it's the default too. – joshudson Oct 27 '16 at 18:06

Your answer is probably found here:


Most recommendations are for RSA keys for a variety of reasons, so DSA keys are largely there for backwards compatibility. DSA was introduced when SSH2 came out since at the time RSA was still patented and DSA was more opensourcy. That has since changed.

Because of all of this, DSA keys are pretty much useless. They'll work, and ssh-keygen will even produce them if you ask it to, but someone has to specifically ask it and that means they can use RSA if you force them to. To the best of my knowledge, nothing did DSA-only. DSA keys are OK to forbid.

| improve this answer | |
  • Yes, I do realize that dsa host keys are about backward comparability, but my question (which probably could have been clearer) is about whatever there still is a need for that backward comparability. – andol Apr 25 '14 at 5:11

The only reason I can come up with security-wise is if prime factorization falls but discrete log doesn't then RSA falls but DSA stands. In that case you would be asking how to disable RSA. If discrete log falls than both RSA and DSA fall. However if your ssh still requires exactly 1024 bits for DSA, fix that now.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.