How to use check_esxi_hardware / CIM access without root user on ESXi

Written by - 0 comments

Published on - Listed in VMware Virtualization Linux


The monitoring plugin check_esxi_hardware is a widely used script to monitor the health of physical hardware of a VMware ESXi server. There is one major (security) problem though: The script needs to use the root user to access the CIM server in the background. But there's a technical workaround how to avoid using the root user to access the information from the ESXi CIM server. By using the esxcli command, we can create an (internal) user on the ESXi server with the necessary permissions.

This was successfully tested on ESXi 8 (build 20513097). The same workaround will likely work on other ESXi versions, too.

Enable SSH on ESXi server

Unfortunately the additional user cannot be created (as needed) in the ESXi user interface (as far as I know). Therefore we must be able to access the ESXi server via SSH. If you're not sure how, see here how to enable SSH on ESXi server.

Create additional local user on ESXi server

Once logged into the ESXi server(s), you can create a new local/system user directly on the server. Run the following command, to create an additional local user:

[root@localhost:~] /usr/lib/vmware/busybox/bin/busybox adduser -s /bin/false -G root -h / monitoring
Changing password for monitoring

You can now choose the new password.

A valid password should be a mix of upper and lower case letters,
digits, and other characters.  You can use a 7 character long
password with characters from at least 3 of these 4 classes.
An upper case letter that begins the password and a digit that
ends it do not count towards the number of character classes used.

Alternatively, if no one else can see your terminal now, you can
pick this as your password: "Loosen6Neon=Trust".

Enter new password: **********
Re-type new password: **********
passwd: password updated successfully

In the example above we've created the user "monitoring", added it to the group "root" (necessary) and disabled shell access (/bin/false).

We can now get a list of local (system) accounts on this ESXi server:

[root@localhost:~] esxcli system account list
User ID     Description                                  Shell access
----------  -------------------------------------------  ------------
root        Administrator                                        true
dcui        DCUI User                                            true
vpxuser     VMware VirtualCenter administration account          true
monitoring  Linux User,,,                                       false

The new monitoring user is now listed in the output and we can confirm that shell access is disabled.

Using check_esxi_hardware with non root user

Right after this, the new monitoring user can be used to query the CIM server via the check_esxi_hardware monitoring plugin:

 $ ./check_esxi_hardware.py -H IP.of.esxi.server -U monitoring -P "very.secret"
OK - Server: QEMU Standard PC (Q35 + ICH9, 2009) s/n: None System BIOS: 1.12.0-1 2014-04-01

Note that I have used a virtualized ESXi server running as a KVM virtual machine in this example.

But isn't using root group another security risk?

As mentioned we have ditched the root user for CIM access and created a new local user "monitoring" for this purpose. This new user is in the "root" group however. Without being a member of the "root" group, the access to the CIM server is denied and you would get an authentication error:

$ ./check_esxi_hardware.py -H IP.of.esxi.server -U monitoring -P "very.secret"
UNKNOWN: Authentication Error

But as the new monitoring user was created without shell access (set to /bin/false), the risks are minimized. SSH logins (if SSH is enabled) is not possible for this monitoring user and also access to the ESXi user interface is prevented. An error is shown when trying to log in:

Permission to perform this operation was denied.

Even if someone gets hands on the monitoring credentials, not much can be done to hurt the ESXi server (not via SSH nor by using the vSphere UI anyway). The security risk is therefore greatly minimized, compared to using the root user for monitoring.


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.