Note: This article covers material present in Version 1 Revision 3 and below.  Topics found below may be mitigated in the most current version of the ESXi 5 STIG.  Ensure you are using the most current version of the DISA STIG documents.

Here we go, SSH Client findings.  There are eleven (11) total findings in this section, all involving the SSH Client configuration as laid out in the ESXi 5 STIG.  You will learn that at the time of this article ESXi 5 and above does not contain the configuration file necessary to make these settings persist.  However, you can use the File and Setting Persistence article to build the configuration file necessary at each boot.  This “work around” will become unnecessary in future versions of our product.

Note: Building the ssh_config file per the above article is currently not officially supported. However, it is the easiest way to accomplish the settings below.
Note:All settings within the sshd_config file are case sensitive.  Options are typically all lower case {yes|no} and are all expressed as <settings> <option> within the configuration file.  The easiest way to verify an issue during your configuration is to have a second console open and run 'tail -f /var/log/auth.log' while attempting a connection.

GEN005516-ESXI5-703 – SSH Client Must Not Allow TCP Forwarding

First off the text here says to check for allowed MACs, so that’s obviously an artifact from another check.  We’re talking about Forward lists here, not MACs.  Don’t let that fool you.  Simple enough to comply, just don’t add any Forward lists to your ssh_config file.  Since you’re building it from scratch that should be easy enough.  Note, there are multiple Forwards lists possible (local|remote|dymanic).  All of them apply here, even though it’s not called out specifically.

GEN005518-ESXI5-704 – SSH Client Must Not Allow Gateway Ports

Again, we’re building this from scratch so there’s not going to be any Gateway Ports, right?  However, I do wish they would pick a GREP command line format and stick with it.  It seems like every check has some subtle difference in how they have you check for compliance.  This one is marked case insensitive.

GEN005520-ESXI5-705 – SSH Client Must Not Allow X11 Forwarding

Once again, we’re building this so no worries.  Don’t put ForwardX11 Yes into your config file and you’re golden.

GEN005529-ESXI5-708 – SSH Client Must Not Send Environment Variables to Server

Whoops!  Here’s our first major error of this section.  Aside from the obvious template failure they had when this check was constructed, the Check/Fix section is wrong as well.  They have you search for the AcceptEnv variable, which is a daemon configuration setting, not a client one.

What they meant to say here, at least I think it’s what they meant, is to check for SendEnv and ensure it says LOCALE, but I have a problem with this even beyond that.  If they are going to state that you either must NOT send environment variables, or if you do only send LOCALE, then do not lock the check/fix down to where only LOCALE is valid.  That’s just silly.  For your knowledge, you can put SendEnv with nothing after it in your ssh_config file and it will send no environment variables.  That’s the default behavior too, so adding nothing to your file would accomplish the same, but we’re in a seeing is believing world.  I recommend you put SendEnv LOCALE in your config file just to make everyone happy and explain to your IA group that the STIG isn’t quite accurate.

GEN005532-ESXI5-709 – SSH Client Must Not Permit Tunnels

Again, PermitTunnel is a daemon settings, not a client one.  The client doesn’t “permit” tunnels, that’s the SSH daemon’s job.  Could they have meant just Tunnel No here?  Not sure, but that’s what would make sense to me.

SRG-OS-000113-ESXI5 – SSH Client Must Resist Replay Attacks

It’s just Protocol 2.  Fancy words, easy fix.

SRG-OS-000157-ESXI5 – SSH Client Must Not Use CBC Ciphers

Ok, so they don’t want you using CBC based ciphers, that’s good… how about they tell you what TO use as well.  There are 14 choices available, and only 6 of them are CBC based.  Leaves some guess work in there for the implementer.  Personally I would use aes-256-ctr, aes-192-ctr, aes-128-ctr.  Those are the only ones that are FIPS 140-2 compliant and available.

SRG-OS-000158-ESXI5 – SSH Client Must Only Use MACs That Are FIPS 140-2 Compliant

This makes sense, especially since the first default MAC in the list is MD5.  Let’s fix that.  Oh wait, you want ONLY hmac-sha1 in the list.  That’s not the only FIPS 140-2 compliant MAC available, but the STIG says you can only configure hmac-sha1 so there you go.  For your information, there’s SHA2 variants available to you as well here.

SRG-OS-000159-ESXI5 – SSH Client Must Only Use FIPS 140-2 Approved Ciphers

Holy crap on a stick!  Ok, listen guys, just use aes ciphers that do NOT end in cbc.  The check only has you look to see if the ciphers listed start with 3des and/or aes, but that’s not good enough to comply with the rest of the document.

By the way, the example says (3des-ctr) is valid, and it could be in most cases, but it’s not a valid choice to this implementation.  The non-cbc aes ciphers are your only choice here.

GEN005501-ESXI5-9778 – SSH Client Must Use SSHv2 Protocol

It’s Protocol 2 again.  See SRG-OS-000113-ESXI5.

GEN005525-ESXI5-09994 – SSH Client Must Not Use GSSAPI

If you want to be technical, we didn’t compile Kerberos support into OpenSSH on the platform so this setting, if applied, will throw and error in your logs.  No worries, you can just ignore the error.


Ok, that’s it.  Let’s build that ssh_config file for you now.  I’ve going to provide the actual script block that goes along with the File and Setting Persistence post I referenced earlier.  Use the block below along with that article to set the ssh_config settings and allow them to faux persist.

if [ ! -f /etc/ssh/ssh_config ]; then
cat > /etc/ssh/ssh_config <<-__BlockDelimiter
Protocol 2
GatewayPorts no
ForwardX11 no
Ciphers aes-256-ctr, aes-192-ctr, aes-128-ctr
MACs hmac-sha1
GSSAPIAuthentication no

# I know the below is wrong, but seeing is believing
# These will throw errors in your log since they are not client settings
AcceptEnv LOCALE
PermitTunnel no

# This is what I think they meant
Tunnel no

Ok, that’s it. Use the above code block along with the File and Setting Persistence article and set your ssh_config file. The file and settings will be created on every boot.  Just remember to reboot.  Next I will cover what’s left in the ESXi 5 Server portion of the STIG.

3 thoughts on “Blog Series: ESXi 5 STIG – ESXi Server SSH Client

  1. Eric,
    I tried using your code block above, and I have to give you some ribbing here. You’re busted for not doing what DISA didn’t do either, i.e. testing what you wrote.

    1. “GSSAPIAuthentication No” ssh client reports unsupported option.
    2. “AcceptEnv LOCALE” & “PermitTunnel No” also cause ssh client to report unsupported option.
    3. It’s been two weeks since I did this but I’m pretty sure “No” has to be replaced with “no” and your Cipher names are wrong.
    4. For some reason, I couldn’t connect the ssh client to anything other than local host (I only checked on the local subnet; it’s an isolated OOB so there is not default gateway). I probably need to open a ticket for this but if you are going to test this now…. maybe you can confirm if you see the same thing. What I saw was the client hangs with nothing written to the log.

    I still think the better option to all of these would be to “rm /ssh” in the /etc/rc.local.d/ or /etc/rc.local and mark all of these as N/A! I wonder if DISA would include that as a valid option in the STIG.


    • Damn, busted. Yep, you’re absolutely right. Option settings are always lower case. No should be no. I’ll fix the article now. Thank you for pointing this out so everyone can benefit. I’ll double check the ciphers as soon as I get a chance, might be tomorrow morning.

      1. GSSAPIAuthentication errors because we didn’t compile in Kerberos to openSSH. This can be ignored in the logs or marked N/A if your IA approves just based upon my word. 🙂 I’m working on getting this requirement removed.
      2. AcceptEnv and PermitTunnel error because they are not SSH client configuration commands, they belong to SSHD. The STIG is wrong, and I pointed that out in the above text. At least I thought I did.
      3. Ciphers I’m testing, can’t get to the details I need at the moment.

Comments are closed.