0

Our vulnerability scanner is flagging some Linux appliances for an SSH vulnerability for key size too small, DSS algorithm 1024 bits. This most likely relates to the DSA key as that only be 1024 bits. I have regenerated new RSA keys with 2048 key size and the authorized_keys file only references the RSA key.

Under SSHD config, I have uncommented and removed the host key entries that reference the DSA key.

However, when I delete the RSA keys and restart the SSHD service the DSA keeps getting re-generated.

I am clearly missing something somewhere but don't know what.

1 Answers1

0

Your appliance must be pretty old, or patched, because OpenSSH upstream has disabled by default (but reversibly) DSA aka ssh-dss on both client and server since 7.0 in 2015. (You can find quite a few questions on several Stacks about this from that time, most like "Oh me oh my! SSH suddenly rejects my key/doesn't work! What happened?")

In addition, the 'standard' (upstream) sshd_config file has several HostKey entries, but all commented out with #, which means that the program actually uses its compiled-in default (and below 7.0 that default includes DSA). OTOH if you uncomment (enable) at least one HostKey entry, but leave commented or delete the one you don't want (i.e. DSA), it should use only the enabled one(s).

If that doesn't work, a clumsier method should be to create an empty ssh_host_dsa_key and (same).pub and make them and the directory unwritable (after ensuring the key(s) you want are valid), or on filesystems that support it make the files immutable.

Finally, an alternative that could shut up the scanner without actually improving security is to generate and install a DSA key with a larger group like 2048 bits. The OpenSSH-supplied ssh-keygen program cannot do this, but OpenSSL commandline can if it is available on your device; if not, but you can transfer data to your device, you can do openssl dsaparam -genkey -noout 2048 >file on any system and just transfer the resulting file to your device as ssh_host_dsa_key. Either way then do ssh-keygen -yf ssh_host_dsa_key >ssh_host_dsa_key.pub. In other cases if you want to do 'modern' DSA (FIPS186-3 sizes) you need OpenSSL 1.0.0 from 2010 or higher, but for SSH only, where the protocol forces SHA1, even OpenSSL 0.9.x is good enough.

The authorized_keys file on an OpenSSH server defines the keys (and algorithms) that will be accepted for client authentication. It has no relationship to or effect on server keys and authentication.

dave_thompson_085
  • 4,082