About: The purpose of this document is to present a functional workaround in resolving the OpenSSH MaxAuthTries Bypass/CVE-2015-5600 vulnerability in ESXi 5.5, since the vendor is unlikely to release a fix in the near future (note that these lines were written about 2 years back), since it consists of upgrading OpenSSH to version 7.0 (according to the package's own release notes), but the software packages that are bundled with an ESXi release tend to be pretty static - in this case, ESXi 5.5 U3c (the version that was current at the time of this having been written initially) contains version 5.6p1 of OpenSSH.

Workaround: The fix consists of a modification that needs to be done to the SSH daemon's configuration file, the /etc/ssh/sshd_config, namely of disabling OpenSSH's modern keyboard-interactive authentication method, which allows the use of various types of authentication methods that utilize a keyboard as a means of proving identity, such as one-time passwords or a PIN that is generated based on a server challenge, and instead enabling the legacy password method, which only accepts a static 'username/password' pair for the same purpose. Of course, if you are using the publickey authentication method then the point is moot and you are better off disabling the keyboard/password authentication altogether.

Working instructions:

• verify the current login method by running ssh -v ESXi_hostname/IP_address from a *nix machine that has network access to it, such as the vCSA you should see the below line in the output, which confirms the vulnerability:

debug1: Authentications that can continue: publickey,keyboard-interactive

• login to the ESXi host via SSH (preferably not via the above session, as it will keep printing debug information)

• run vi /etc/ssh/sshd_config

• once the file is open in Vi, locate the UsePAM yes line and enter the following below it:

  ChallengeResponseAuthentication no
PasswordAuthentication yes

  • check out this Vi 'cheat sheet' for help in using the editor
  • the PasswordAuthentication directive should already be there, so simply replace the no with a yes

• save the modifications and confirm them by running less /etc/ssh/sshd_config (or by grepping for them)

• restart the SSH daemon by running /etc/init.d/SSH restart

• verify the workaround by re-running the ssh -v ESXi_hostname/IP_address command from the external system and confirming that the previous output line has now become the one below:

debug1: Authentications that can continue: publickey,password

For the sake of having a reference, below you will find two examples of the sshd_config file, one in its vanilla state (should have been previously untouched), and one modified as per the instructions found here:

# running from inetd
# Port 2200
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

UsePrivilegeSeparation no

SyslogFacility auth
LogLevel info

PermitRootLogin yes

PrintMotd yes
PrintLastLog no

TCPKeepAlive yes

X11Forwarding no

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc

MACs hmac-sha1,hmac-sha1-96

UsePAM yes
# only use PAM challenge-response (keyboard-interactive)
PasswordAuthentication no

Banner /etc/issue

Subsystem sftp /usr/lib/vmware/openssh/bin/sftp-server -f LOCAL5 -l INFO

AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys

# Timeout value of 10 mins. The default value of ClientAliveCountMax is 3. 
# Hence, we get a  3 * 200 = 600 seconds timeout if the client has been
# unresponsive.
ClientAliveInterval 200

# sshd(8) will refuse connection attempts with a probability of "rate/100"
# (30%) if there are currently "start" (10) unauthenticated connections.  The
# probability increases linearly and all connection attempts are refused if the
# number of unauthenticated connections reaches "full" (100)
MaxStartups 10:30:100

# running from inetd
# Port 2200
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

UsePrivilegeSeparation no

SyslogFacility auth
LogLevel info

PermitRootLogin yes

PrintMotd yes
PrintLastLog no

TCPKeepAlive yes

X11Forwarding no

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc

MACs hmac-sha1,hmac-sha1-96

UsePAM yes
# only use PAM challenge-response (keyboard-interactive) -- this has been changed, see below

###An attempt to work around the 'OpenSSH MaxAuthTries Bypass' vulnerability -- 19.05.2016 -- IT
## will be implemented by doing the following:
# 1. explicitly entering the 'ChallengeResponseAuthentication' directive and setting it to 'no' (OpenSSH implicitly defaults it to 'yes')
# 2. modifying the 'PasswordAuthentication' directive, by setting it to 'yes' (normally comes defined as 'no')
ChallengeResponseAuthentication no
PasswordAuthentication yes
### end of workaround - to revert, remove everything in this paragraph (quotes included, as they will no longer serve a purpose), with the exception of 'PasswordAuthentication', which should be changed to 'no'

Banner /etc/issue

Subsystem sftp /usr/lib/vmware/openssh/bin/sftp-server -f LOCAL5 -l INFO

AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys

# Timeout value of 10 mins. The default value of ClientAliveCountMax is 3. 
# Hence, we get a  3 * 200 = 600 seconds timeout if the client has been
# unresponsive.
ClientAliveInterval 200

# sshd(8) will refuse connection attempts with a probability of "rate/100"
# (30%) if there are currently "start" (10) unauthenticated connections.  The
# probability increases linearly and all connection attempts are refused if the
# number of unauthenticated connections reaches "full" (100)
MaxStartups 10:30:100

#Disable the (enabled by default) UseDNS directive, as it serves no purpose (in our particular infrastructure) and only serves to delay the SSH login to the host - 13.04.2016 - IT
UseDNS no