Page MenuHomePhabricator

[drydock/core] Use WinRM instead of SSH for Windows hosts
AbandonedPublic

Authored by hach-que on Sep 15 2014, 2:33 PM.

Details

Reviewers
epriestley
Group Reviewers
Blessed Reviewers
Maniphest Tasks
T2015: Implement Drydock
Summary

Ref T2015. This uses the winrm binary executable from https://github.com/masterzen/winrm in order to remotely execute commands on Windows hosts. This means you no longer need to set up an SSH server on Windows, and from some initial observations, it appears to be a lot more consistent and stable at running commands.

Test Plan

Set up a preallocated Windows host and ran a Harbormaster build against it. Saw things generally behave as expected.

Diff Detail

Repository
rP Phabricator
Branch
arcpatch-D10495
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 8153
Build 9313: arc lint + arc unit

Event Timeline

hach-que retitled this revision from to Use WinRM instead of SSH for Windows hosts.
hach-que updated this object.
hach-que edited the test plan for this revision. (Show Details)
hach-que added a reviewer: epriestley.
hach-que edited edge metadata.

Remove support for Windows from the SSH interface

Add setup check for winrm binary if Drydock is installed

As I'd prefer to have everything use ssh, I assume one will be able to continue to use ssh to control windows hosts by not declaring them to be windows hosts (but rather unix hosts)? (assuming this differential goes in)

This revision is, for the most part, superceded by D10547. However that diff is primarily meant as a way for myself to transition away from SSH without doing a big bang approach. For various reasons, I doubt @epriestley will want to support SSH on Windows.

There are basically two options when it comes to SSH servers on Windows:

  • FreeSSHD
  • Cygwin OpenSSHD

The former merges standard output and standard error streams, making it not an option for various uses.

The latter is incredibly complex to set up and configure correctly. Basically to run processes under OpenSSHD and have the correct behaviour you need to:

  • For the initial setup, either run this script or perform the equivalent steps manually. This configuration must be exactly correct, or commands will behave strangely in subtle and unexpected ways.
  • For each command run, you have to restore the correct Windows environment variables by spawning a new PowerShell session, as is done in this interface. This is because OpenSSHD clears out all of the standard Windows environment variables such as %APPDATA%. They do this because when they authenticate a user over SSH, the remote command doesn't actually run as that user; it instead runs as the user the OpenSSHD configured service is, and sets the environment variables to pretend to run under the target user (this is the Windows equivalent of SSH'ing in as bob, and having your command actually run as root with the UID environment variable overridden to "1000").

Now while the SSH connection over Windows has been rigorously tested in a production environment, it's not very maintainable. In contrast, the method that uses the winrm binary is far, far simpler, and doesn't require any of the above nonsense in order to get working.

The downside to WinRM is that there's absolutely no encryption; if you run it over the internet, everything is transmitted in plain text. However, most setups are expected to be running build agents in EC2, along side their Phabricator install, in which case the network traffic is expected to be on the internal VPC network and not via the public internet.

SSH on Windows code is now removed by D13340 and D13341

hach-que retitled this revision from Use WinRM instead of SSH for Windows hosts to [drydock/core] Use WinRM instead of SSH for Windows hosts.Jul 1 2015, 4:47 AM

@epriestley This still needs review. Is there any way of getting this upstreamed?

I don't plan to bring this upstream until we're ready to support Windows on Drydock, which is likely far away.

What's blocking upstream support for Windows on Drydock? (other than this diff which adds it)

You're the only install with an interest in it that I'm aware of.

Bringing Windows support upstream means that testing many future changes properly becomes more than twice as difficult. I don't want to bear this maintenance cost unless the feature is providing substantial value to numerous installs. I believe it would not today.

There are at least two installs that benefit from Windows support - my own personal install that I use for open source software, and the workplace where I've done contract work. I know in the latter case, some teams there have started migrating to Jenkins and various other tools because of the poor upstream support we've had in Harbormaster / Drydock for their use cases. As much as the company overall would prefer to use Phacility (they prefer using a SaSS over internally maintained software), it's not a feasible option while there are major blockers such as this.

I'm keeping this patched locally; if any other installs want Windows support in Harbormaster, they'll need to pester @epriestley about it.

Fwiw, it looks like Windows may at some point provide native sshd support judging from http://blogs.msdn.com/b/powershell/archive/2015/10/19/openssh-for-windows-update.aspx

Oh hey, it's open source; I wasn't expecting that. I also wasn't expecting the setup to be apparently this simple: https://github.com/PowerShell/Win32-OpenSSH/wiki/Deploy-Win32-OpenSSH