I am trying to set a console / Tech Support Mode / SSH idle-session timeout and, so far, have had no luck.
From within vCenter, I have gone to ESX Host -> Configuration -> Advanced Settings -> UserVars -> UserVars.ESXiShellTimeout and set this to a value of "5". I then rebooted the ESXi host and confirmed that the timeout value 'stuck' with the host - which it did.
Next, I connected to the host with Putty via SSH, and I also logged in directly via the console to TSM.
The configuration screen describes the timeout value as being in seconds. I've waited for both five seconds and five minutes - and my shell & TSM sessions have not been disconnected. I also tried a simple "export TMOUT=5" from the console, without success.
Does anyone have any advice?
Your help is much appreciated.
Thank you for the advice. I was under the impression restarting the ESXi 5 host would also restart the management network.
I just finished restarting the Management Agents via the 'admin' (F2) screen from the console. This does not seem to have worked.
Let me qualify my question with the fact that I'm running ESXi 5 in Workstation 8 and that I am not an experienced VMWare administrator.
when you F2 to login, you'll arrow down to "Troubleshooting Options" Then to "Restart Managment Agents" This is different then "Restart Managment Network". I"m not saying it will work, but that would be the first thing I would try. It appears you have the settings configured properly.
Thanks again for the info. The first time around, I did restart the Management Network, as opposed to the Management Agents.
However, restarting the Management Agents has still not helped.
At this point, I'm going to reset the host to default settings and reconfigure the timeout through vCenter as I did the first time. Maybe something I did along the way is interfering with this setting.
Thanks again. When I have time, I'll post results.
The following was unsuccessful:
1) Using 'F2' options from the ESXi 5 console, I performed a 'Reset System Configuration' and rebooted the host
2) Using 'F2' options from the console, I enabled ESXi Console and ESXi Shell from the Troubleshooting Options menu.
3) Using vSphere, I configured Advanced Settings -> UserVars -> ESXiShellTimeout to a value of '20' - which, according to the GUI, is in seconds.
4) Using 'F2' options from the console, I restarted the Management Agents from the Troubleshooting Options menu
5) Logged in to ESXi directly via console, waited 20 seconds (and 20 minutes), without session being disconnected.
6) Logged in to ESXi via Putty/SSH, waited 20 seconds (and 20 minutes), without session being disconnected.
😎 Verified via vSphere that the timeout setting I set in Step 3 was still set to '20'
Were you ever successful in having ssh timeout? I performed many of the same steps as you and could never have ssh timeout... Not only irritating in the fact it does not work is that some documentation, VMware's own, states to set it in minutes where as the actual advanced settings interface clearly states seconds.
Can anyone confirm this setting actually functions properly? Thanks.
Although I didn't validate the following, this may be the source of your frustration.
This is the VMware documented result of setting the UserVars.ESXiShellInteractiveTimeOut:
"If you are logged in when the timeout period elapses, your session will persist. However, after you log out or your session is terminated, users are not allowed to log in"
Note the first sentence...the session is persistent (no timeout) when open. This statement as well as the second sentence implies that the session connection must be terminated for the ESXiShellInteractiveTimeOut to be effective.
As such, if your attempting to close an inactive session, the following is recommended by VMware:
You can set a timeout for idle vSphere Client sessions. This allows you to close sessions automatically, which reduces the potential for unauthorized users to access vCenter Server.
What to do next
Often this is controlled by the SSH server itself not the shell. You can also be controlled by the client...
There is always more than one way to handle a security control.
Edward L. Haletky aka Texiwill
VMware Communities User Moderator, VMware vExpert 2009-2017
Virtualization and Cloud Security Analyst: TVP Strategy
Blue Gears Blog: vSphere Upgrade Saga