vSphere Security: Advanced SSH Configurations

Written by

Published on 22/10/2013 - Read in about 5 min (1016 words)

Published under Networking and VMware #certificates #ESX and ESXi #esxi #firewall #pki #Security #Security #ssh #VMWare

This article is now 9 years old! It is highly likely that this information is out of date and the author will have completely forgotten about it. Please take care when following any guidance to ensure you have up-to-date recommendations.

There are different schools of thought as to whether you should have SSH enabled on your hosts. VMware recommend it is disabled. With SSH disabled there is no possibility of attack, so that’s the “most secure” option. Of course in the real world there’s a balance between “most secure” and “usability” (e.g. the most secure host is powered off and physically isolated from the network, but you can’t run any workloads Winking smile ). My preferred route is to have it enabled but locked down.

Note: VMware use the term “ESXi Shell”, most of us would term it “SSH” – the two are used interchangeably in this article although there is a slight difference. You can have the ESXi Shell enabled but SSH disabled – this means you can access the shell via the DCUI. For the sake of this article assume ESXi Shell and SSH are the same.

Enable or disable SSH

This is by far the most blogged about topic on SSH with ESXi - I’ll refer you to the documentation rather than repeat!

Using ESXi Shell in ESXi 5.x

Disable the “SSH for the host has been enabled” warning

VMware don’t want you to leave SSH enabled, so by default vSphere will alert you to the fact that it is. If your design decision is to enable SSH but you don’t want the warning, set the advanced setting “SuppressShellWarning” to a value of 1.

To configure via PowerCLI:

Get-VMHost esxi01.definit.local | Get-AdvancedSetting -Name 'UserVars.SuppressShellWarning’ | Set-AdvancedSetting -Value "1" -Confirm:$false

Restrict SSH access by IP address

Using the ESXi firewall it’s possible to restrict access to SSH (and other services) based on the IP address of the client. You can enter IP addresses in the following formats: 192.168.0.0/24, 192.168.1.2, 2001::1/64, or fd3e:29a6:0a81:e478::/64. From Manage tab on a host you can open the Security Profile page and edit the firewall. Select the SSH Server rule and modify the allowed connections:

To configure this via PowerCLI you need to use the Get-EsxCli command:

$EsxCli = Get-EsxCli –VMhost esx01.definit.local
$EsxCli.network.firewall.ruleset.allowedip.list(“sshServer”) # Returns the current AllowedIPAddresses
$EsxCli.network.firewall.ruleset.set($false, $true, "sshServer") # Sets “AllowedAll” to $false, “Enabled” to $true on rule set “sshServer”
$EsxCli.network.firewall.ruleset.allowedip.add("192.168.1.20", "sshServer") # Adds “192.168.1.20” to the AllowedIPAddresses ruleset – if you have multiple IPs to add you can repeat this line
$EsxCli.network.firewall.refresh() # Reloads the firewall rules

SSH Timeouts

From ESXi 5.1 up there you can configure two timeout settings for the ESXi Shell (SSH). The first “ESXiShellTimeOut” controls the service, and is useful if you enable SSH temporarily, but then forget to disable it (because we’re all busy, right?) The second setting, “ESXiShellInteractiveTimeOut” sets the session timeout for SSH – so if you leave your SSH client logged in and the timeout is set it will end your session and disconnect you. By default, both of these settings have a value of “0” which disables the timeout. The value is in seconds.

To set these by PowerCLI use the Set-AdvancedSetting cmdlet – in the below example I set the ESXiShellInteractiveTimeout to 5 minutes on the host esx01:

Get-VMHost esxi01.definit.local | Get-AdvancedSetting -Name 'UserVars.ESXiShellInteractiveTimeout' | Set-AdvancedSetting -Value "300" -Confirm:$false

Use public/private keys to authenticate SSH

It’s possible to use a public/private key pair to authenticate SSH connections to an ESXi host and allow password-less connections. Just because it’s possible, doesn’t mean you should! Bear in mind that if your private key is compromised then an attacker can gain full root access to a host without needing a password.

I used PuTTYGen to generate an SSH-2 RSA public/private key pair without a passphrase and save the public and private keys. I now have two files, id_rsa.pub (the public key) and id_rsa.ppk (the private key). You need to edit the id_rsa.pub file to remove the first two lines, the last line, and remove any line breaks. You also need to insert “ssh-rsa “ at the beginning (credit to Walkernews.net for this)

It’s easier to show you the file goes from this format:

To this:

Alternatively, you could also use the the ssh-keygen command located at /usr/lib/vmware/openssh/bin to generate a key pair. The disadvantage there is that the private key is on the server, so you should be careful there, ensure you remove the private key from that host and store it safely.

I then used WinSCP to copy id_rsa.pub to the /tmp folder on the host, then use PuTTY to SSH to the host and copy the public key to the authorized_keys file using the cat command:

cat /tmp/id_rsa.pub >> /etc/ssh/keys-root/authorized_keys

Note: the /keys-root/ folder could be any other user ID on the host, so if you had a user “sam” then you would use /keys-sam/

If you create the private key with a password, then you will get prompted for the password when you connect. This could be used to create more secure connections to the host (i.e. you need the username, private key and the password to connect rather than just a username and password), but would create quite an administrative burden.

My SSH Settings

How you configure your hosts for SSH is entirely down to you and your security policy – these are the settings that I use based off of my security policy and accepted risks (I in no way provide guarantee or warrantee for these settings! Do your research – I accept no liability!)

These settings can all be manually set, built into host profiles, or you could use a PowerCLI script to configure them if licensing doesn’t allow.

Enable SSH – the ease of access when troubleshooting or repairing a host.
Disable the Shell warning – you’ve made a design decision to enable SSH, document it and disable the alert.
Restrict access by IP – lock it down to your management workstations, vCenter Server etc.
Configure session timeout – I configure ESXiShellInteractiveTimeout to 300 seconds (5 minutes)

A slightly more secure configuration would be:

Disable SSH, only enable when required
Restrict access by IP – lock it down to your management workstations, vCenter Server etc.
Configure Session and Service timeout - ESXiShellTimeout to 14400 (4 hours) and ESXiShellInteractiveTimeout to 300 seconds (5 minutes)