Enabling SSH Access in ESXi 5.0 for Non-root Users.

With the release of ESXi 5.0 VMware permanently did away with one of the core components of its flagship product: the service console. Owing to its roots in Linux the original versions of ESX were in fact modified versions of Red Hat Enterprise Linux and had all the trimmings of a full Linux host. Of course modifying anything in there was done at your own peril but for the most part you could treat it just like a Linux box when there was a challenge you needed to overcome. However the Service Console was also the most patched aspect of ESX and thus moving away from it meant a more secure hypervisor, at the cost of removing some flexibility.

Of course some of the functionality remains but its far from what it used to be. Instead of being a fully fledged Linux box under the hood it’s now a custom BusyBox implementation giving you a somewhat familiar environment but with all the cruft reduced to a minimum. When ESXi was first introduced I was quite sceptical as I spent a good deal of my time in the Service Console when troubleshooting virtual environments but since I’ve spent the last 6 months developing an ESXi 5.0 standard operating environment I’ve grown to appreciate the simplicity, mostly because the tools to manage ESXi outside the service console have matured considerably.

One thing it doesn’t do well however is remote access. Back in the ESX days it was a pretty simple matter of creating a new user and giving them shell access and there was nothing more that needed to be done. Whilst it’s trivial to re-enable SSH you’ll soon find out that whilst you’re able to access it with the built in root account you can’t access it with any other account, even if you’ve granted them shell access (the complete opposite to how it has been in the past). For my SOE this isn’t acceptable and so I’ve been developing a solution to the problem.

Engaging my Goolge-Fu I quickly stumbled across two posts that detailed a process of how to do this on ESXi 4.1. Now many of the problems in 4.1 are shared with 5.0 so I figured that these would probably work for me. Upon testing them however neither of them work meaning that there’s been some changes to the way that ESXi does its SSH authentication in 5.0. Thankfully those posts, coupled with some insight from work mates, pointed me to the right solution.

One of the solutions we found that worked for us was modifying /etc/security/access.conf to have the user in it that you wanted. That ends up looking something like this:

+:dcui:ALL
+:root:ALL
+:vpxuser:ALL
+:vslauser:ALL
+:UserToGiveSSHTo:ALL
-:ALL:ALL

That works, right up until you reboot. That particular file isn’t blessed with the sticky bit that ESXi puts on certain files so any changes to it are lost upon reboot. Additionally that appears to only work for a single user which would make adding additional users something of a bother. As it turns out both these problems are rather easily solved.

The access.conf file also works with groups, although this isn’t documented anywhere. So for the example file above if you just use a group name instead of a single user name all users contained in that group will get shell access, so long as the user was granted that when it was created. To get around the rebooting problem you can edit the rc.local file (which does have the sticky bit on it) which is a script file that runs after ESXi is done loading, allowing you to run scripts at start up. All that you need to do then is sed in the permission line for the group/user you want to enable access for. An example rc.local file is below:

#!/bin/sh

export PATH=/sbin:/bin

log() {
echo "${1}"
/bin/busybox logger init "${1}"
}

# execute all service retgistered in ${rcdir} ($1 or /etc/rc.local.d)
if [ -d "${1:-/etc/rc.local.d}" ] ; then
for filename in $(find "${1:-/etc/rc.local.d}" | /bin/busybox sort) ; do
if [ -f "${filename}" ] && [ -x "${filename}" ]; then
log "running ${filename}"
"${filename}"
fi
done
fi

sleep 4
sed -i '$ i\+:GroupOrUserThatNeedsAccess:ALL' /etc/security/access.conf

I’ve tested this and it works on one of my freshly minted ESXi 5.0 boxes.

One of our concerns with this was the potential security implications of enabling SSH in this way. ESXi uses PAM for authentication and what the above modifications to access.conf does is tell PAM to authorize that account for any check that invokes it, including SSH authentication. Now that sounds bad since it seems like that would be akin to granting those users administrator rights (indeed that is the supported way of giving users SSH access to ESXi hosts) but ESXi only uses PAM for authentication, not authorization. This means that whilst they’ve got wide open access when it comes to PAM ESXi uses its own in built permissions to control user access. So this means you can have restricted accounts that are allowed to login via SSH and then su to root if they need more permissions, which is still supported in BusyBox.

So this is probably as close as you’ll ever get to having the same level of control that you have in your current ESX environments when you make the switch to ESXi. Personally I think it’s pretty elegant and its very maintainable unlike many of the other solutions I tried before reaching this one. If you have any questions or comments feel free to hit me up in the comments, on twitter or send me an email.