Disabling authentication via DSA keys in OpenSSH?

  • 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*;
      echo -n ""|sudo tee "$i"
      sudo chattr +i "$i"

    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?

    Why do you want this?

    @Zoredache: because of http://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity ... but it doesn't really matter, does it? ;)

  • 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.)

    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.

    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.

    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.

    (@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

    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.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM