It’s often seen from most scanners a number of issues being raised in regard to SSH security. They are mostly around :
- Use of weak arcfour ciphers
- SSH Weak ciphers
- SSH weak Mac algorithms
- SSH insecure key exchange etc.
as an example we will cover how to harden a weak understanding of the defaults and how to harden. I will be demonstrating with a debian box (Kali to be specific). The SSH version is as below:
OPENSSH 7.2 (Debian)
The default configuration can also be seen by using the Q switch in SSH to see what is currently supported.
SSH Ciphers (Default)
SSH Macs (Default)
We would need to assess the status of the defaults; we will use a tool called SSH Audit which can be downloaded from github. We will check for only failed configuration issues rather than warnings and information to get a perspective first.
Failed SSH Configuration
As is seen the default configuration is not quite robust. All is not lost ; the principle here is all is enabled unless secure configurations are chosen. This is intentional because really its variant on the environment (versions of SSH in use; SSH client algorithm support etc). In research (google tsk tsk tsk) I found a nice resource that gives a starter pack on what values to feed /etc/ssh/sshd_config. The resource can be found here. From this resource ; I added the configuration below based on my SSH version.
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
As much as the configuration here seems good; It did not quite cut it because we reduce the fails but not completely; In further research i realised I haven’t set the host key algorithm hence the fail; during this time I also read abit as to why some of these algorithms are discouraged, the writeup can be found here.
Fails after new configuration
Enter the new line host key algorithm.
HostKeyAlgorithms ssh-rsa,rsa-sha2-512,rsa-sha2-512,rsa-sha2-512
on doing a more detailed scan for all log levels we now have warnings and informational as seen below ;
Check SSH configuration
Killing the last bit of warnings we simply modify our configuration to use only those strong ciphers; In this case I ended up with the master sheet below :
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com
HostKeyAlgorithms ssh-rsa,rsa-sha2-512,rsa-sha2-512,rsa-sha2-512
On scanning now :
SSH on Paranoia
We can additionally do an nmap just to get the feel of what we are working with.
Check supported SSH algorithms using Nmap
Hope this has been helpful. Above all note that the perfect situation may not be workable in some instances especially if backward compatibility is a factor. This can however be used to attempt to harden to the highest level possible.
2 replies on “Surviving an SSH Audit”
There isn’t any only solution-but heaps of options – like I stated in the beginning, there’s no hard
and quick manual that states into the idea solutions into all of your issues.
Today if you introduce a specific problem to a panel of experts, you’re
guaranteed to get many distinctive opinions and remedies at yield.
This will turnout to become vexing.
Very true , It’s a guide to offer a good start when one has no clue how it goes 🙂