After upgrading to ESX 4.1, I needed to SSH (Secure SHell) in to do some maintenance and noticed that my SSH account was unable to gain access with an “Access Denied” message. ESX blocks any SSH attempts from the root account by default for security reasons, so I normally use a regular user and then su into root access. No dice with 4.1, even after troubleshooting by changing the password and creating a new normal user. At this point I knew it had to be some sort of access control.
The PAM Access Control Module
In ESX 4.1, the pam_access control module uses this file to control access: /etc/security/access.conf
Viewing the contents, the file contains a list of users and groups that have access.
In the picture above, I added my service account for the Veeam backup software (named Veeam), which is not normally there.
In order to grant access to your regular user, you’ll need to “properly” modify the file and add any additional users or groups that need access. The alternative is to make the user an Administrator (the root group).
I am not certain what driving force resulted in this change. My only thought is that this is in an effort to phase out any 3rd party tools that utilize the service console in anticipation of a service console-less ESXi host (as ESX is on the way out) and encourage everyone to use the API. Except that Veeam Backup & Recovery, a very powerful and popular backup software, requests that it have SSH to each host – it’s not required, but running agent-less is usually frowned upon based on what I’ve read and heard.
Creating a User in ESX 4.X
You can skip this step if you already have a regular user account and just want to allow it to SSH.
The most user friendly method is to use the GUI in the vSphere Client to create a user account. This is not done through the vCenter server, but rather by connecting to the ESX host directly from the vSphere Client.
From there, select the “Local Users & Groups” tab and then right click in the list to add a new user.
Create a Login Name and UID that are not currently in use. The User Name is a friendly name, and can be something a bit more descriptive. Make sure to select “Grant shell access to this user” and put the user in the Group named “users”.
Using vCLI to Allow SSH
The next step is to “properly” allow SSH for this regular account. Rather than edit the file directly, many users on the VMware Communities pages state that the changes are rolled back after restarting the host. So, do it right the first time.
First, download vCLI from VMware’s website.
Next, Greg Swallow provided the command to use on his blog here. I’ll simply repost the command (all credit goes to Greg).
Example: You make a regular account named “peanutbutter” and wish to grant it SSH on the VMware ESX server named “jelly”
C:Program Files (x86)VMwareVMware vSphere CLI>binvicfg-user.pl --server jelly --username root --protocol HTTPS --entity user --login peanutbutter --operation modify --role admin
A prompt will request the root password, and then state that the command was successful. You can now SSH with this account.
Additional Thoughts
With most servers having a remote management method attached (such as Dell’s DRAC) it may not be all that necessary to SSH for normal administrative purposes. I utilize an IP KVM at work, but it’s still a bit cumbersome to have to launch a session, authenticate, and then connect to the ESX host via KVM (or a DRAC-like interface). Either way, the proposed solution above is simple enough to deal with in most environments, and there really isn’t much actual work involved, so get it out of the way so you can set up a proper SSH environment – don’t be tempted to just elevate everyone to Admin (root).
