6 ways to enable SSH on an ESXi host

Option 1: enable Remote Tech Support (SSH) via the DCUI

Enabling Remote Tech Support (SSH) is ideal production systems, because you can enable it and leave it turned on for an x amount of time, and after the time out SSH is being disabled automatically, so the system is secure again. One small drawback is that you need to have either a physical console access or a iLO, DRAC or some other remote console access.

If you’re running vSphere 4.1 you can also enable this via the vSphere Client, see option two for more details.

Once you have direct console access to the DCUI of the ESXi server you’re able to enable Remote Tech Support (SSH) on the ESXi host, but first you need to login with the right credentials, in most cases this will be the root account.

You will find the Remote Tech Support option under the Troubleshooting Options.

Select Enable Remote Tech Support (SSH) to enable the SSH service, be patient because it will take some time to enable it, if you press Enter twice you will disable Remote Tech Support :-) .

After a few second Remote Tech Support should be enabled, if not press the Enter key one more time until you see a screen as shown above. Sometimes it can be hard to enable it through the DCUI especially when using iLO, but maybe that’s because I’m not patient enough :-).

To enable a timeout on which the SSH service is turned on, select Modify Tech Support Timeout, and hit Enter to continue, this option is not required, it can be useful to provide someone access to the ESXi host for just a few minutes/hours. I recommend you to always set this time out on production systems, because you can’t forget to turn if off again.

Enter any value between 0 (zero) and (one day) 1440 minutes (where zero is to disable it, and 1440 is the maximum) to enable the SSH  time out, press Enter to activate it.

To test if it’s working, you can use Putty to connect to the ESXi host.

Once you’re enabled the Remote Tech Support feature you will receive a message within the vSphere Client (both if your directly connected to a ESXi host or through the vCenter Server) indicating that Remote Tech Support Mode is enabled. Personally I like this notification, because it will remind you that SSH is still enabled, so you can’t forget to turn it off :-) .

When the timeout expires, you see it is not possible to create a new SSH session to the ESXi hosts (Note: only if you’re entered an timeout value in the Timeout for Tech Support Mode Text, or if you manually disable it). However this timeout does not apply for connections that are still active, so it’s still possible that someone still have access to the ESXi host even while Remote Tech Support is already disabled, so keep that in mind.

Option 2: enable Remote Tech Support (SSH) via the vSphere Client

As mentioned before, with the introduction of vSphere 4.1 you will be able to enable the Remote Tech Support through the vSphere Client, either directly connected to the ESXi host or through the vCenter Server. Bellow I will only describe how to enable it if you’re connected through the vCenter Server. If your doing this by connecting the vSphere Client directly to the ESXi hosts, you can also use these steps because it’s not that different.

If you’re using vSphere 4.1, I recommend using this way to enable SSH for a production ESXi host, because it’s easy to do and it can be done without the need of a direct console connection.

The first step off cource is to open the vSphere Client and logon to you’re vCenter Server, if your not already done that:-).

Once you logged in, select the ESXi host on which you want to enable SSH, and click on theConfiguration tab, in the Software screen click on Security Profile. In the Services field click on Properties.

Select the service: Remote Tech Support (SSH) and click on Options.

Click on Start to enable the Remote Tech Support (SSH) service, you can leave the Start-up Policy as it is.

Verify that the Remote Tech Support (SSH) service is running and click on OK.

Once you have enabled the Remote Tech Support Mode you will receive a message on the ESXi host, that the service is enabled.

One (small) drawback of this method is, that it isn’t possible to use a timeout on the SSH service directly within the Services screen, to enable the timeout you need to go toSoftware/Advanced Settings.

Select: UserVars and enter the required timeout value in the UserVars.TSMTimeOut (note: the timeout is in seconds, in my example I have configured a timeout of 30 minutes –> 1800 seconds) click on OK to enable the timeout feature.

Option 3: enable the SSH service through the Busybox

This is a more old school way of turning on the SSH service, if I remembercorrectly this procedure is still more or less the same since VMware ESXi 3, but correct me if I’m wrong here.

Unfortunately to get this working you need to have a direct console access or via iLO, DRAC to open the console on the ESXi host.

One other (big) drawback is that you won’t know if the SSH service is enabled or not, unlike the two other ways there’s no warning message in vCenter that will let you know if SSH is enabled, so in my opinion this is not a great way to turn on SSH on production ESXi hosts, but could be useful for example in Labs where you want to have quick access to the ESXi host.

Once you have access to the console, press ALT + F1 to access the console (Busybox), and login with the root credentials.

If you receive a message like the one above here, you need to enable Local Tech Support, standard this is turned off so you need to turn it on before you can access the console of the Busybox.

Press ALT + F2 to get back to the ESXi DCUI console (the yellow-grey screen) and login and select Troubleshooting Options.

Select in the menu Enable Local Tech Support and hit Enter to enable this function, this could take some time before the service is enabled, so be patient otherwise you disable the function:-) .

Now you have enabled Local Tech Support, lets get back to the console of the Busybox by pressing ALT + F1 keys.

Login with the root account.

Edit the inetd.conf file located in /etc/inetd.conf, in this example I use the VI editor.

Once the file is opened in the VI editor, press the Insert key to edit the inetd.conf file.

Depending on if you’re use IPv4 or IPv6 you need to edit the correct line, for IPv4 you need to edit the #ssh line and remove the # to enable the ssh service in the configuration file. Press on Esc and exit with the command :wq.

The SSH service will only start until the inetd reads it’s changed configuration file, this can be done by rebooting the ESXi host, or even better by restarting the inetd process. To do so we first need to have the process id of inetd, this can be done by execute the following command;ps | grep inetd you will receive a number which is the process id of inetd, in my case the process id is 4860.

To kill the inetd process, execute the command; kill -hup 4860 (where 4860 is the process id of inetd).

If everything is working fine you should be able to access the ESXi host via SSH, like in the example above I accessed the ESXi host via Putty and I’m able to login with the root account. Don’t forget to disable it once your work has been done :-) .

Option 4: Enable SSH through PowerCLI

Big thanks to Alan Renouf over at virtu-al.net and Arne Fokkema over at ict-freak.nl for pointing me at a great blog post written by Alan Renouf himself. As Alan mentioned in his blog, it is possible to enable ESXi hosts services via the PowerCLI, here’s how you can do it.

You can show the running services by execute the command: Get-VMHostService as shown here above.

To enable it you can execute this line of code:

Get-VMHost | Foreach { Start-VMHostService -HostService ($_ | Get-VMHostService | Where { $_.Key -eq “TSM-SSH”} ) }

As you can see here above the service is now started.

Option 5: Enable SSH with help of a Perl script

Also a big thanks to William Lam over at VirtuallyGhetto.com, he has written a very cool perl script to enable services, on one or multiple ESXi hosts which can be run from the vSphere CLI or the vMA.

As mentioned here above this script can be run from the vMA or the vSphere CLI, in this example I run it locally from my notebook through the vSphere CLI, but it works the same on the vMA.

Start the vSphere CLI and browse to the folder which contains the hostServiceManagement.pl script (the script can be found here) and execute the following command to get a over view of the services:

hostServiceManagement.pl –server [hostname] –operation query

To enable the Remote Tech Support (SSH) service we need to use the TSM-SSH service, which is not running at the moment.

To enable the Remote Tech Support service you need to execute the following command:

hostServiceManagement.pl –server [hostname] –operation start –service TSM-SH

Run the query command and you will see that the service is started correctly, I recommend you to read William’s blog post about this because you can also do this on multiple ESXi hosts, which can be very handy in large environments.

Option 6: Enable SSH within the kickstart script

William Lam also pointed me at a another way to turn on SSH during the installation, by adding a command line to the kickstart script.

This could be useful if you want to configure or check some items on the host just before you take it in production, but remember disable it once it’s running production load.

You just need to add the following two lines to the kickstart script:

vim-cmd hostsvc/enable_remote_tsm  (this will change the startup policy to “start and stop with the host”, if you don’t add this line and the host will reboot you won’t have SSH access anymore)

vim-cmd hostsvc/start_remote_tsm     (this will start the service)

One last note, I see an ESXi host more like an appliance, so I don’t want to have any unnecessary ports to be open on the host itself, because each open port is a potential security risk. That’s why I recommend not to enable SSH on a production ESXi hosts, just for security reasons. In a lab environment where security is not always a big issue you can enable SSH to get quick access to the host, or to check or test things out.

Personally I’m moving more and more over to the vMA (vsphere Management Assistant) which is a nice little appliance that’s capable of doing everything that you could do on the ESXi console and even more. The vMA is somewhat like a ”distributed” service console (dSC – Distributed Service Console, I wonder when VMware will use that term :-) ) from which, you can access any ESXi host and execute tons of commands just like your accessing an ESX(i) hosts.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s