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.

Partner with aster.cloud
for your next big idea.
Let us know here.

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.

 

### Sample output - Windows Server 2019 ###

PS C:\> systeminfo /FO csv | ConvertFrom-CSV | Select "OS Name","OS Version" | Format-List


OS Name    : Microsoft Windows Server 2019 Datacenter
OS Version : 10.0.17763 N/A Build 17763

PS C:\> Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'
Name  : OpenSSH.Client~~~~0.0.1.0
State : Installed

Name  : OpenSSH.Server~~~~0.0.1.0
State : NotPresent



### Sample output - Windows Server 2022 ###

PS C:\> systeminfo /FO csv | ConvertFrom-CSV | Select "OS Name","OS Version" | Format-List

OS Name    : Microsoft Windows Server 2022 Datacenter
OS Version : 10.0.20348 N/A Build 20348

PS C:\> Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

Name  : OpenSSH.Client~~~~0.0.1.0
State : Installed

Name  : OpenSSH.Server~~~~0.0.1.0
State : NotPresent

 

Read More  Application Observability Made Easier For Compute Engine

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

 

PS C:\> Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

 

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

 

PS C:\> Start-Service sshd
PS C:\> Set-Service -Name sshd -StartupType 'Automatic'

 

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.

 

#SSH into the Server and run the command to create the .ssh folder in Alice’s home directory
PS C:\> ssh administrator@win2019-ssh ‘mkdir C:\Users\Alice\.ssh’

#While logged in as an Administrator, use Secure Copy Protocol to copy Alice’s Public key into the authorized_keys file


#Copy from Windows Server
PS C:\> scp C:\alice.pub administrator@win2019-ssh:C:\Users\Alice\.ssh\authorized_keys

#Alternatively you can copy the key from Linux Server
~$ scp ./alice.pub administrator@win2019-ssh:C:/Users/Alice/.ssh/authorized_keys

 

Read More  Get Migrating In 2023: Join Our Upcoming Fireside Chat Featuring Forrester

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

 

PS C:\> ssh administrator@win2019-ssh 'icacls.exe "C:\Users\Alice\.ssh\authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"'

 

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

 

#Sample output using standard SSH

alice@cloudshell:~$ ssh alice@win2019-ssh

Microsoft Windows [Version 10.0.17763.2114]
(c) 2018 Microsoft Corporation. All rights reserved.


alice@WIN2019-SSH C:\Users\Alice>


#Sample output using gcloud compute ssh
#Alice’s Private Key (id_ecdsa) is being passed as a parameter

alice@cloudshell:~$ gcloud compute ssh alice@win2019-ssh --zone=us-central1-a --ssh-key-file="~/.ssh/id_ecdsa"

Microsoft Windows [Version 10.0.17763.2114]
(c) 2018 Microsoft Corporation. All rights reserved.

alice@WIN2019-SSH C:\Users\Alice>

 

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

 

#Before proceeding ensure that the Administrator’s Public Key has been added to the Administrator User Profile’s .ssh folder

PS C:\> $sshd_config = 'C:\ProgramData\ssh\sshd_config'
PS C:\> (Get-Content $sshd_config) -Replace '#PasswordAuthentication yes', 'PasswordAuthentication no' | Set-Content $sshd_config
PS C:\> Restart-Service sshd

 

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:

 

validate:
              interpreter: POWERSHELL
              script: |
                $service = Get-Service -Name 'sshd'
                if ($service.Status -eq 'Running') {exit 100} else {exit 101}

 

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.

Read More  Best Kept Security Secrets: How Cloud EKM Can Help Resolve The Cloud Trust Paradox

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:

 

enforce:
              interpreter: POWERSHELL
              script: |
                Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
                Set-Service -Name sshd -StartupType 'Automatic'
                Start-Service sshd
                exit 100

 

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

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

 

osPolicies:
  - id: win-ensure-openssh-policy
    mode: ENFORCEMENT
    resourceGroups:
      - resources:
          id: ensure-ssh
          exec:
            validate:
              interpreter: POWERSHELL
              script: |
                $service = Get-Service -Name 'sshd'
                if ($service.Status -eq 'Running') {exit 100} else {exit 101}
            enforce:
              interpreter: POWERSHELL
              script: |
                Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
                Set-Service -Name sshd -StartupType 'Automatic'
                Start-Service sshd
                exit 100
instanceFilter:
  osShortNames:
    - windows
  inclusionLabels:
    - labels:
        ssh: installed
rollout:
  disruptionBudget:
    fixed: 10
  minWaitDuration: 300s

 

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:

 

gcloud compute os-config os-policy-assignments create ensure-ssh-policy \
   --location=<compute engine zone name> \
   --file=<policy file.yaml> \
   --async

 

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.

 

 

By: Alex Moore (Technology Practice Lead, Infrastructure Modernization) and Akaash Rampersad (Customer Engineer, Infrastructure Modernization)
Source: Google Cloud Blog

For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!
Our humans need coffee too! Your support is highly appreciated, thank you!

Related Topics
You May Also Like