SSH Server Public Key Too Small
We will look at one more interesting SSH vulnerability reported by Qualys scanner appliance on RHEL6 servers. This one is classified as Confirmed Severity 2 (Medium) vulnerability level with PCI Vulnerable.
Below is the vulnerability details from scan report
Vulnerability: SSH Server Public Key Too Small
Category: General remote services
PCI Vuln: Yes
THREAT: The SSH protocol (Secure Shell) is a method for secure remote login from one computer to another.The SSH Server is using a small Public Key. Best practices require that RSA digital signatures be 2048 or more bits long to provide adequate security. Key lengths of 1024 are acceptable through 2013, but since 2011 they are considered deprecated.
IMPACT: A man-in-the-middle attacker can exploit this vulnerability to record the communication to decrypt the session key and even the messages.
SOLUTION: DSA keys and RSA keys shorter than 2048 bits are considered vulnerable. It is recommended to install a RSA public key length of at least 2048 bits or greater, or to switch to ECDSA or EdDSA.
Basically, the scanner has identified there is a weak server host key (based on the key length) present on the system. In this case, from the Results section, the key in question is SSH-DSS which is of 1024 bits.
The solution in our environment was pretty straight forward as below:
- Since we were already using RSA key (2048 bits) on our servers, we just had to delete these DSA Key (1024 bits) because DSA Keys of 2048 bits cannot be created using ssh-keygen tool.
- Configured SSHD not to regenerate these DSA key after every sshd restart.
Let me explain below how this is done and before that some technical ssh checks/stuffs to understand before we actually tweak any ssh config on server.
- Check what version of SSH protocol is enabled on our server
root@linuxminion# sshd -T | grep -i protocol protocol 2
- Check what server hostkey’s are allowed based on the config
root@linuxminion# sshd -T | grep -i hostkey hostkey /etc/ssh/ssh_host_rsa_key hostkey /etc/ssh/ssh_host_dsa_key
From above command output, We have ssh_host_rsa_key and ssh_host_dsa_key enabled.
[ NOTE: hostkey – Specifies a file containing a private host key used by SSH]
[ A host key is a cryptographic key used for authenticating computers in the SSH protocol. Host keys are key pairs, typically using the RSA, DSA, or ECDSA algorithms. Public host keys are stored on and/or distributed to SSH clients, and private keys are stored on SSH servers ]
Since we now know, SSH authentication to this server can happen by using RSA and DSA hostkeys but do we really have those keys on our server ?
- Check for the actual keys under /etc/ssh/
[root@linuxminion]# ls -l /etc/ssh
-rw-------. 1 root root 125811 Mar 20 22:25 moduli
-rw-r--r--. 1 root root 2047 Mar 20 22:25 ssh_config
-rw-------. 1 root root 4232 Apr 23 08:39 sshd_config
-rw-r--r--. 1 root root 5 May 31 2013 sshd.deny
-rw-------. 1 root root 668 Jun 10 2015 ssh_host_dsa_key
-rw-r--r--. 1 root root 590 Jun 10 2015 ssh_host_dsa_key.pub
-rw-------. 1 root root 1679 Jun 10 2015 ssh_host_rsa_key
-rw-r--r--. 1 root root 382 Jun 10 2015 ssh_host_rsa_key.pub
Yes, we see them i.e., both DSA & RSA keys (public & private) available on the server.
- Check the key length(serverkey bits) of these keys by below command
[root@linuxminion]# ssh-keygen -lf /etc/ssh/ssh_host_dsa_key 1024 54:5e:b0:4d:b5:59:0f:33:7f:c5:3f:30:3f:4c:f2:f0:82 /etc/ssh/ssh_host_dsa_key.pub (DSA) [root@linuxminion]# ssh-keygen -lf /etc/ssh/ssh_host_dsa_key.pub 1024 54:5e:b0:4d:b5:59:0f:33:7f:c5:3f:30:3f:4c:f2:f0:82 /etc/ssh/ssh_host_dsa_key.pub (DSA) Where : -l Show fingerprint of specified public key file -f filename Specifies the filename of the key file
Voila…!!! The above DSA key is of 1024 bits length and this is what the scanner is complaining about.
Since RSA hostkeys were being used on our servers, we just went and deleted these DSA hostkeys (both public & private)
[root@linuxminion]# rm -f /etc/ssh/ssh_host_dsa_key [root@linuxminion]# rm -f /etc/ssh/ssh_host_dsa_key.pub
Be aware that though we have deleted these keys, this is not yet completely fixed as these keys would be re-generated every time sshd service is restarted. So that means Qualys would identify them and report this vulnerability again.
So how do we fix this completely i.e., stop this DSA key regeneration?
Well this can be accomplished as below.
- Check for the value of “AUTOCREATE_SERVER_KEYS” parameter that is set in configuration file /etc/sysconfig/sshd for the sshd service.
[root@linuxminion]# cat /etc/sysconfig/sshd #Configuration file for the sshd service. #The server keys are automatically generated if they ommited #to change the automatic creation uncomment the appropriate line. #AUTOCREATE_SERVER_KEYS=RSAONLY #AUTOCREATE_SERVER_KEYS=NO AUTOCREATE_SERVER_KEYS=YES #Do not change this option unless you have hardware random #generator and you REALLY know what you are doing/ export SSH_USE_STRONG_RNG=0 #export SSH_USE_STRONG_RNG=1
Since the value is set to YES, the DSA server keys would be regenerated post sshd service restart. To stop this from happening, the below config option needs to be used i.e., we are disabling DSA key autogeneration and enabling only RSA keys.
- Below is how the config file looks post tweaking.
[root@linuxminion]# cat /etc/sysconfig/sshd #Configuration file for the sshd service. #The server keys are automatically generated if they ommited #to change the automatic creation uncomment the appropriate line. #AUTOCREATE_SERVER_KEYS=RSAONLY #AUTOCREATE_SERVER_KEYS=NO AUTOCREATE_SERVER_KEYS=RSAONLY #Do not change this option unless you have hardware random #generator and you REALLY know what you are doing/ export SSH_USE_STRONG_RNG=0 #export SSH_USE_STRONG_RNG=1
Once done, restart the SSHD service and check to verify for non generation of DSA keys.
[root@linuxminion]# service sshd restart
We had our Qualys appliance re-scan the servers and as expected the report didn’t show up this ssh vulnerability and was successfully remediated.