13

How can I disable DSA and ECDSA authentication on my server with OpenSSH 5.9? Sifting through the documentation material and doing a web search didn't yield any results - only an old bug report for the Debian package here (and those linked at the bottom of that bug) but no conclusion.

Assuming it is not possible to disable those two methods from inside the /etc/ssh/sshd_config, is it enough to do (Bash syntax): for i in /etc/ssh/ssh_host_{ecdsa,dsa}_key*; do echo -n ""|sudo tee "$i"; sudo chattr +i "$i"; done (below with line breaks for readability):

for i in /etc/ssh/ssh_host_{ecdsa,dsa}_key*;
do
  echo -n ""|sudo tee "$i"
  sudo chattr +i "$i"
done

I.e. to invalidate the host keys and then make them immutable, thus rendering attempts from sshd to regenerate the DSA and ECDSA host keys impossible.

The reason I want to disable DSA is because there are sources that claim weaknesses in the algorithm that have been actively abused, such as Wikipedia and this website. I dug a bit further and it seems credible. The more pragmatic and less theoretical advantage is the verification speed of RSA over DSA.

TL;DR: is it possible to configure sshd from OpenSSH in sshd_config to disable ECDSA and DSA? If not, can one prevent successful authentications with those methods by setting the host key files immutable?

0xC0000022L
  • 1,603
  • 2
  • 15
  • 20

3 Answers3

14

I will first dispute your reasons for deactivating DSA and ECDSA:

  • There is no known weakness in either which makes them "more vulnerable" than plain RSA.
  • There has been badly made implementations of DSA or ECDSA; however, there has also been badly made implementations of RSA, and in some case it resulted in RSA key leakage (e.g. Bleichenbacher's attack).
  • While (EC)DSA requires a fresh source of good randomness, (EC)DSA key generation is vastly easier to perform than RSA key generation. Badly generated RSA keys appear to happen a lot in practice. This article includes an interesting quote about Arjen Lenstra (whom I would personally trust much more on security matters than almost everybody else):

He said that other formulas such as Diffie-Hellman and DSA aren't as vulnerable because the duplication of a factor makes a key holder vulnerable only to the person who holds the corresponding certificate. "If you have a collision, you only affect one other person. You can hurt them and they can hurt you, but you haven't made it public to everybody and their mother."

  • If you do not have quality randomness on your server you are doomed anyway.

  • As for performance, DSA signature verification is no more expensive than the Diffie-Hellman key exchange which takes place anyway at the beginning of each connection. We are talking about one millisecond or so here on a basic PC; I suggest making actual measures before declaring some cryptographic algorithms guilty of slowness. And ECDSA will be typically ten times faster than DSA.

That being said, if you are really intent on deactivating (EC)DSA support on your SSH server, I suggest recompiling OpenSSH (starting with the source for the version packaged in your specific OS) after deactivating DSA and ECDSA in it (look for the key.c, function key_verify(): it suffices to modify it so that (EC)DSA verification always fails, and you will never accept any (EC)DSA-based authentication).

(There does not appear to be an option to selectively deactivate support for asymmetric algorithms. Your server will be deemed to implicitly allow DSA if it has a DSA key, which somehow makes sense. As for client authentication, in the SSH model, this is a decision which is up to each user, who decides to include or not include his RSA/DSA/ECDSA public key in his .ssh/authorized_keys. This might be a case for user education, after all.)

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • Turns out this isn't true (the last statement). I have even made it impossible for the server to provide the DSA host key (truncated the file and made it immutable), yet I am able to log in. Thanks anyway for the cross-referenced answer and a +1. – 0xC0000022L Jan 21 '13 at 12:22
  • 1
    Note that OpenSSH key generation nowadays caps DSA keys at 1024 bits, for strict RFC compliance and better interop with some other implementations, so without patching `ssh-keygen` you can't generate a DSA key of a length appropriate for modern use. Thus use RSA and ECDSA, but avoid DSA. – Phil P Nov 07 '13 at 15:09
  • I'm wondering whether your assessment from the first paragraph still stands: DSA being safe and all. Just wondering, since my question is from before Snowden's leaks. – 0xC0000022L May 05 '14 at 10:04
  • (@PhilP) Although ssh-keygen generates only 1k for DSA, OpenSSH can read and use an OpenSSL-generated DSA key of 2k or 3k, except that 7.0+ disables DSA by default so you have to configure it back on. However SSH _protocol_ uses only SHA1 with DSA regardless of size, limiting strength to 80bits; see cross https://crypto.stackexchange.com/questions/15051/why-does-openssh-use-only-sha1-for-signing-and-verifying-of-digital-signatures – dave_thompson_085 May 12 '17 at 05:23
  • 2
    I used DSA for a while after the 1k limit went in, with keys generated before that, but this is a "writing on the wall" situation. The protocol was _ambiguous_ about SHA1/SHA2 with larger keys, which is why the OpenSSH devs disabled larger key generation in their implementation. The RFC which came _later_ mandated SHA1, but at least one other implementation was using SHA2 because that's what the NIST standards said to use with larger keys. You can choose to enable DSA and do all sorts of jumping through hoops, but really, don't bother. We have better available now. – Phil P May 14 '17 at 02:35
8

EDIT: As indicated in dave_thompson_085's comment, this solution requires OpenSSH release 7.0 or newer, and will not work for OpenSSH 5.9 as requested by the original poster. Left as a reference for users of OpenSSH 7.0 and newer with the same goals.

As per the current OpenBSD sshd_config(5) man page, it is possible to restrict the use of DSA/ECDSA by excluding it from the HostKeyAlgorithms

http://man.openbsd.org/OpenBSD-6.1/sshd_config.5

In the HostKey section:

Note that sshd(8) will refuse to use a file if it is group/world-accessible and that the HostKeyAlgorithms option restricts which of the keys are actually used by sshd(8).

So by specifying other algorithms (you can get a list using “ssh -Q key”) you can eliminate it's use. Eg.

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

I should note that the above quotation is not in all older versions of the man page, so this may not work on your version.

DougC
  • 201
  • 2
  • 4
-1

It looks like there's an option that is legal for sshd_config:

DSAAuthentication no

does half of what you're looking for. I don't know if there's an equivalent for ECDSA. I found that option here.

  • Weird, this appears to be a new directive then. It's not in the version of `man sshd_config` I have. But thanks, appears there is a newer version that will have it. I looked for `Dsa`, `DSA` and `dsa` in the `man` page. +1 as this seems to be version-specific and clearly your answer would work would I have the "correct" version. – 0xC0000022L Jan 11 '13 at 18:05
  • 2
    http://www.openssh.com/txt/release-2.5.1p1 - `DSAAuthentication` is obsolete. – Zoredache Jan 11 '13 at 18:32
  • @Zoredache: so it's actually old, not new. Dang ... – 0xC0000022L Jan 11 '13 at 21:33
  • Yeah, I realized after I left that the reason it wasn't in the current man page is because it's deprecated. Thanks for catching that Zoredache. –  Jan 12 '13 at 00:08
  • 1
    `DSAAuthentication` is an alias for `PubkeyAuthentication`, so disabling it also disables RSA. – Phil P Nov 07 '13 at 15:07