Getting started with OpenSSH on Windows Compute Engine instances

One of the best practices for managing your virtual machines in the cloud is to rely on smart automation for certain tasks. When done this way you can save cloud and IT teams a tremendous amount of time and toil, especially for tasks like VM state validation which we’ll talk about in this blog. Let’s back up a bit first, though. 

In autumn of 2018 Microsoft added OpenSSH support to Windows Server and Windows Desktop Operating Systems. OpenSSH, developed by The OpenBSD Project, provides secure connectivity to another computer using encrypted communication based on the Secure Shell (SSH) protocol. Prior to OpenSSH being supported in Windows, Users and Administrators of those operating systems were required to use Microsoft Remote Desktop Protocol or Powershell Remoting for remote access. 

OpenSSH Server support in Windows Server can be beneficial for Google Cloud customers; in addition to using standard SSH clients to remotely connect and administer a Windows Server, you can now also leverage the Google Cloud SDK via the gcloud command to integrate with the rest of the Google Cloud ecosystem to set up workflows and automation.

For example, let’s assume that you wanted to automate the recycling of an IIS Application Pool if the Web Server CPU usage was greater than 90%. This process can be automated in a variety of ways, one of which could be to create a Pub/Sub topic integrated with a Cloud Function to log in to the Server via SSH and execute the Restart-WebAppPool Powershell command. Alternatively, if there’s a predetermined time that you want to automate the execution of the Restart-WebAppPool command, you can also use Cloud Scheduler to use the SSH functionality in gcloud to log in and execute the Powershell command.

Getting started with OpenSSH Server on Windows Server

Windows Server 2019 and Windows Server 2022 Images on Google Cloud come with the OpenSSH Client installed and enabled by default and the OpenSSH Server disabled.

To enable the OpenSSH Server, run the following Powershell command from an elevated prompt:

After the installation is complete, run the following Powershell commands to start the OpenSSH Server service:

The next step is getting your SSH keys added so that you can login. If you don’t have an existing Public and Private keypair you can generate one using the ssh-keygen command. 

OpenSSH Server in Windows has two options for adding your Public key:

• authorized_keys file located in each Users’ home directory. This option requires the User account to be added to the Server and a $HOME directory created. 

• administrators_authorized_keys file located in the C:\ProgramData\ssh directory. This option provides a shared Administrative login facility but does not require a User profile.

In this example let’s assume that a user called Alice already exists on a Windows Server called win2019-ssh and has a User Profile created. We need to add Alice’s Public key (alice.pub) to Alice’s home directory and to achieve this; you’ll need to be logged on as an Administrator (either locally or remotely) to create the authorized_keys file in the User Profile.

After the authorized_keys file is created under Alice’s .ssh folder, run the following command as Administrator to set the appropriate permissions.

Alice can now log in to win2019-ssh using standard SSH or gcloud without having to input a password.

An optional but strongly recommended configuration is to disable password authentication for SSH connections to prevent brute force attacks.

Fleet-wide deployment

With the ability to manage your Compute Engine Windows instances over SSH with PowerShell, wouldn’t it be great if you could ensure your entire Windows fleet has it enabled? This is where Google Compute Engine VM Manager OS configuration management comes into play.  

We can write a policy for VM Manager to do all the hard work for us. There are two modes for a policy — the first is `Validation`.  This checks to see if the instance is in the desired state —  in our case, do we have the Windows sshd process running? We can do that with this policy fragment:

Here we are telling the OS policy agent to use PowerShell to run a simple script that does the following: if the VM is compliant, i.e., the sshd service is running, we return `100`, otherwise we return `101` to tell VM Manager that the VM is not compliant.

If we want to remediate servers, we can use the `Enforcement` mode; this carries out automation to remediate the policy — in our case, install the Open SSH server, set the service to start up automatically and start the service. We can do that with this policy fragment:

As before, we return `100` to indicate that everything was successful.

These two policy elements combine to form our overall OS policy:

You can see we are choosing the ‘Enforcement’ mode for the policy, we are filtering Compute Engine instances to be only those with a `windows` OS, via the `osShortNames` parameter, and (optionally) we are only going to apply this policy to instances that have the label `ssh` with the value `installed`; you can also have `exclusionLabels` if you want to do the reverse, or remove the label entries entirely if you want to apply the policy to your Windows systems.

You can then apply this policy to a zone with the following gcloud command:

Conclusion

Modern infrastructure management is all about automation. With the ability to enable SSH on Windows instances, you can combine automation tooling approaches across both Windows and Linux systems.

Combined with Compute Engine VM Manager OS Policy Management, you can also do it at scale across your entire fleet.

Learn more about VM Manager and check out other OS policy examples.