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.

@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.

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