Applies to: VMware ESXi 9.x / 8.x / 7.x / 6.7 / 6.5 / 6.0 / 5.5 / 5.1 / 5.0 / 4.1
ESXi Shell, previously called Tech Support Mode (TSM), provides local command-line access to an ESXi host. It is mainly intended for break-fix situations where normal management tools are not available or are not enough.
The original version of this article was written for ESXi 4.1, where the message “Tech Support Mode has been disabled by the Administrator” appeared when local TSM was disabled. The same basic concept still exists in current ESXi releases, but the feature is now called ESXi Shell.
In This Article
- 1. ESXi Shell vs SSH
- 2. Enable ESXi Shell from DCUI
- 3. Access the Local ESXi Shell
- 4. Enable ESXi Shell from the Host Client
- 5. Configure ESXi Shell Timeouts
- 6. Original ESXi 4.1 Behavior
- 7. Key Takeaways
1. ESXi Shell vs SSH
ESXi provides two separate shell access methods:
- ESXi Shell provides local shell access from the physical console or a remote hardware console such as iLO or iDRAC.
- SSH provides remote shell access over the network. SSH uses TCP port 22 by default.
Enabling ESXi Shell does not automatically enable SSH. They are separate services and should be enabled only when required.
2. Enable ESXi Shell from DCUI
Broadcom documents the following procedure for current ESXi versions:
- Open the Direct Console User Interface (DCUI).
- Press F2 and authenticate.
- Select Troubleshooting Options.
- Select Enable ESXi Shell.
- Press Enter to enable the service.
SSH can be enabled separately from the same Troubleshooting Options menu when remote shell access is required.
3. Access the Local ESXi Shell
After ESXi Shell is enabled:
- Press Alt+F1 to switch from the DCUI to the local shell login screen.
- Sign in with an account that has the required privileges.
- Press Alt+F2 to return to the DCUI.
If Alt+F1 opens a blank screen or no shell prompt appears, first verify that ESXi Shell is actually enabled under Troubleshooting Options.
4. Enable ESXi Shell from the Host Client
If the ESXi Host Client is available, the service can also be started without using the physical console:
- Connect directly to the ESXi host with a browser.
- Open Manage.
- Select the Services tab.
- Select the TSM service.
- Select Actions > Start.
The service name may still appear as TSM in the Host Client even though the feature is referred to as ESXi Shell in current documentation.
5. Configure ESXi Shell Timeouts
Leaving shell access enabled longer than necessary increases the management surface of the host. ESXi provides timeout settings to limit shell availability and idle sessions.
- UserVars.ESXiShellTimeOut controls how long shell access remains available before it is automatically disabled. The value is stored in seconds.
- UserVars.ESXiShellInteractiveTimeOut controls the idle time before an interactive shell session is automatically logged out. A value of 0 disables the timeout.
The DCUI also provides Modify ESXi Shell and SSH timeouts under Troubleshooting Options. For troubleshooting work, enable shell access only for the required period and disable it again when the task is complete.
6. Original ESXi 4.1 Behavior
The original article documented ESXi 4.1. When Local Tech Support Mode was not running, pressing Alt+F1 displayed the following message:

In ESXi 4.1, the corresponding service was presented as Local Tech Support. In current ESXi versions, use the Enable ESXi Shell option described above rather than following the old vSphere Client screens.
7. Key Takeaways
- Tech Support Mode is now called ESXi Shell.
- Use F2 > Troubleshooting Options > Enable ESXi Shell from the DCUI.
- Use Alt+F1 to access the local shell and Alt+F2 to return to the DCUI.
- ESXi Shell and SSH are separate services.
- Shell access should normally be temporary and limited to troubleshooting or break-fix work.
References
- Broadcom Knowledge Base – Using ESXi Shell in ESXi
- Broadcom Knowledge Base – DCUI access using ALT+F keys in VMware vSphere ESXi

Cloud and infrastructure professional with nearly two decades of experience in enterprise IT environments, spanning public cloud, private cloud, and hybrid architectures.