The following vSphere warning is observed on an ESXi host when a user logs in to it via SSH/ESXShell and runs supershell command in a sandboxed shell:
# esx.audit.supershell.access
"Supershell session has been started by a user."
For more information about VOB messages, please visit Using the VMkernel Observations for Creating Alarms.
SSH and ESXi Shell today run in superDom by default. With vSphere 8.0 release, this will stay the same, but there is an option to enable shell sandbox using the following steps:
When enabled, any subsequent shell spawned through SSH (and local ESXi shell) will have reduced privileges. Most operations on shell will stop working.
The only recommended use-case of sandboxed shell is to run the following commands:
Any other command is not advisable to run.
To run other commands on the sandboxed shell run the command "supershell".
This would elevate the privileges of the current shell and all commands would start working.
When supershell is accessed in a sandboxed shell, a vob (vob.user.supershell.access) and a corresponding event (esx.audit.supershell.access) is generated (throttled to limit to one every 5 minutes) .
To disable SSH sandboxing follow the below steps:
Do not enable SSH on the hosts unless there is a troubleshooting use-case. While accessing hosts via SSH or ESXi Shell where shell sandbox is enabled, supershell should not be used unless absolutely necessary. If elevating the privilege of the shell entirely is not needed (in sandboxed shell) and there is a need to run only a specific command with supershell, use the following syntax:
supershell -c "<cmd>"
For instance: supershell -c "localcli system secpolicy domain list"
For more information on supershell flags, check using "supershell --help" or "supershell -h".