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.

So we need to talk about GEN005537-ESXI-000111 – SSH Daemon Must Use Privilege Separation for a moment.  There’s a lot of confusion around this finding so let us sort through it together.

First off let’s draw a line in this discussion, nothing can be done about this on ESXi 5.0.  The setting just will not work.  The reason?  We did not compile chroot into ESXi 5.0.  However, in 5.1 and 5.5 it is absolutely configurable, with a little finesse and TLC.  Let’s take a look.

Note: The following instructions are not supported by VMware, nor were they tested in any way, shape or form by QA, so I cannot guarantee how they will react in your environment.  Please implement this on an isolated or single host first to make sure there are no unintended consequences.  To date I have not seen any reports of the below settings, if applied correctly, causing issue.

In addition to this article you are going to need to review Blog Series: ESXi 5 STIG – File and Setting Persistence.  This is necessary because we need to create the default chroot location for the privilege separation user.

Creating the chroot Directory

First off we need to give the privilege separation user it’s own empty directory as home.  OpenSSH is compiled on ESXi 5.1 and 5.5 to use the default of /var/empty for this, which means that’s what it’s looking for so lets create it.  As I stated before, we need to utilize the File and Setting Persistence article I blogged about previously.  Review that now, understand it, then come back.

Now that you’re back here’s what we need to do.  If you’ve followed my other posts then your local.sh file has some additional settings in it for the ssh_config findings.  We’re not going to worry about that, leave them in place, we just want to add something above it.  SSH into your ESXi host and edit the /etc/rc.local.d/local.sh file with vi and add the following above the settings from the SSH Client article, or at the very least above the exit 0 line.

mkdir /var/empty

Save and verify your changes.  You will also need to create this right now, unless you want to wait until a reboot to test. From your command line also run mkdir /var/empty. The above local.sh settings will cover persistence through a reboot, and what you just created from the command line covers now. Good to go, let’s hit the next point.

Creating the sshd Group

Next we need a special local group for the privilege separation user.  Now, if you remember from my previous articles, the concept of local groups from the vCenter Client no longer exists, so we have to do this from the command line.  Our file of interest here is /etc/group.  Use your trusty VI skills here and edit this file.  We need to add a new line to this file, and come up with a group number.  It should look something line this.

sshd:x:600

Now the groupID here, 600, I just made up.  Save this file and verify it’s correct.  It will persist on its own, no need to place this into local.sh.

Creating the sshd User

Next we need to create the sshd user, set his home directory, and give him no login shell. Now, you can do this from the vCenter Client, but since we are on the command line lets just do it here. The file of interest is /etc/passwd. Open it with VI and add the following at the end of this file.

sshd:x:600:600:sshd PrivSep User:/var/empty:/sbin/nologin

Save and verify this file, it will persist automatically. You’ve now successfully created the chroot directory to persist, the sshd group, and the sshd user. That’s the pieces you need for Privilege Separation to work, now let’s set it in SSH and test it out.

Setting PrivSep In sshd_config

The final step, aside from testing, is turning the feature on in the sshd_config file.  The file here is /etc/ssh/sshd_config.  Open this in VI and find the line UsePrivilegeSeparation no.  Change this to yes, then save and close the file.  Now, let’s test that you can successfully SSH into the box.

Testing

If you’re applying a STIG to ESXi you probably do not need me to walk you through testing steps.  The important thing here is to first, make sure you have SSH enabled prior to testing, because you all followed my docs and have a 15 minute timeout on SSH, right?  Anyway, I’d hate for you to test, fail, and then find out it was because it wasn’t enabled or timed out.

Attempt to login via SSH.  If you get in, all is well.  If not you are likely to see an error similar to ssh_exchange_identification: Connection closed by remote host.  If you see that error something isn’t right with the PrivSep configuration.  Back on your console connection run tail /var/log/auth.log and see what it says.  The log should tell you exactly what’s wrong, but if not just verify all your files (/var/empty, /etc/group, /etc/passwd, /etc/ssh/sshd_config) and make sure they are configured per this document.

As always if you have any questions, concerns, or corrections please feel free to leave a comment below.

 

2 thoughts on “Blog Series: ESXi 5 STIG – ESXi Server SSHD Privilege Separation

  1. Hey Eric,
    Thanks for this EXTREMELY helpful series on ESXi Server settings. Please tell us you are going to continue on with your opinions and tips on the other 2 parts of the STIG. I am especially interested in STIG finding ESXi5-VM-000001 which is a CAT 1 hit for not having limits and reservations for EVERY VM !! That is crazy talk. I asked DISA about that and recieved a disertation on the setting most of which I disagree with. CAT 1 hits are hard to look the other way on.

    • I am going to continue them, yes. I’m glad you they are helpful!

      End of year slowed down the additional posts. We’re getting ready to see revision 2 of the entire ESXi STIG in a few weeks. I’m tempted to wait until I have a draft copy of that revision before I post more. Just to try and keep the duplication down.

Comments are closed.