6 ways to enable SSH on an ESXi host

Posted on 18/01/2011 by Remon Lam No Comments

UPDATE: Big thanks to Eric Sloof, Arne Fokkema, Alan Renouf and William Lam.
They have pointed my at three additional ways to turn on SSH, I have added them
to this post to make it even more complete, thanks guys!!!
Yeah I know, there are many blog post out there that describe how to enable SSH on an ESXi
host, so why write another one? Well actually I have two reasons for it, first there are several
ways to enable SSH and secondly I want to talk about the consequences when you
enable SSH, because I think it need some more attention than just show you how to enable
it.
So I decided to dig a little bit further in this matter, and provide you with some extra
information, and hopefully some guidance to leave SSH turned on or off, but we will get back
on that subject later in this post.
Like most of you already know its possible to access an ESX (classic) host through SSH with
help of Putty or some other kind of SSH application, and login to the Service Console.
But with the introduction of VMware ESXi this have changed a little bit, because the ESXi
host wont have a Service Console, theres no way to login with SSH, or is it? Lucky for us
ESXi still have a so called Busybox (a very small Service Console but very limited
in functionality) so with some tweaks it is still possible to use SSH for accessing an ESXis
host, but remember its not the full blown Service Console like ESX have.
Since the release of vSphere 4.1 it is possible to enable SSH aka Remote Tech Support via
the vSphere Client to make it a lot easier to enable SSH, more about his in option two.

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 youre 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 youre 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 thats because Im 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 cant 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 its working, you can use Putty to connect to the ESXi host.

Once youre 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 cant 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 youre 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 its 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 youre
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 its not that different.
If youre using vSphere 4.1, I recommend using this way to enable SSH for a production ESXi
host, because its 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 youre 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
the Configuration 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 isnt possible to use a timeout on the SSH
service directly within the Services screen, to enable the timeout you need to go
to Software/Advanced Settings.

Select: UserVars and enter the required timeout value in

theUserVars.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 Im 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 wont know if the SSH service is enabled or not, unlike
the two other ways theres 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 theinetd.conf file.

Depending on if youre 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 its 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 Im able to login with the root
account. Dont 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, heres how you can do it.

You can show the running services by execute the command:

above.

Get-VMHostService as

shown here

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 Williams 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 its 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

dont add this line and the host will reboot you wont 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 dont want to have
any unnecessary ports to be open on the host itself, because each open port is a potential
security risk. Thats 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 Im moving more and more over to the vMA (vsphere Management Assistant)
which is a nice little appliance thats 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.