New Shell Timeout Settings
There’s a couple of areas where ESXi has had refinements introduced – the main ones being security. It used to be the case that to get “console shell” access on an ESXi host you would need root rights to use the “SU” command. The “elevation” of rights was troublesome in a number of ways. For example if you had significant number of ESXi admin that needed console rights for troubleshooting for example the root account password would have to be shared amongst the team. That would lead to situation where the root password was hardly (if ever) changed, and the same on all the ESXi hosts say in a cluster. Once the ESXi admin had logged in as themselves and SU to root – the audit trails in the log files would show that escalation – but of course, once everyone is “root” it was difficult to create an audit trail that could pinpoint who had done what and when. With ESXi 5.1 any ESXi Admin has full shell access without any need to resort to the SU command, and at a stroke this improves the audit trail on any host.
Similar at the SSH layer there are new timeout controls associated with sessions established with clients like the famous PuTTy. These timeouts act like the ones we frequently have with unattended workstations – where a user logins and then walks away from their terminal. So any SSH session which enters a period of inactivity (like you going off for lunch for instance) will trigger timeout value, and once exceed will end the SSH session. That will end the possibility of someone gaining access by someone foolishly leaving his or her machine unattended.
The setting that controls is this is called “ESXiShellInteractiveTimeOut” where 0 disables the feature, and a number in seconds enables it. It’s not be confused with the timeout value that would turn of SSH/DCUI access by stopping these services.
Windows 8; SNMPv3; CPU Support
There are cluster of enhancements and changes – firstly ESXi 5.1 support Windows 8 as client and server.
It also ships with support for SNMPv3 and it has been tested against the latest generation of AMD PileDriver and Intel IvyBridge/SandyBridge CPUs.