Surviving an SSH Audit

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 Ciphers (Default)

SSH Macs (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

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

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

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

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

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 thoughts 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.

Leave a Reply

Your email address will not be published. Required fields are marked *