When Cygwin OpenSSHD spawns a new session on Windows, it runs everything under a UNIX-like environment. It strips out all of the standard Windows environment variables (under the guise of "security": https://cygwin.com/ml/cygwin/2006-11/msg00394.html). This means that conventional variables such as APPDATA, are not available when Cygwin OpenSSHD is the SSH server on Windows. These are pretty much requires to run any sort of Windows application in a reasonable way.
In addition under Cygwin OpenSSHD, even though things are set up to pretend to be the logged in user, in reality you're actually still running as the service user. This basically means that the moment you try to do anything with cryptography on Windows, everything explodes because it can't actually access the user's private keys (for decrypting passwords stored on disk, etc.)
On the other hand, Cygwin OpenSSHD is the only server that we can automatically install and configure, and is also the only server that correctly separates standard output and error streams (FreeSSHD merges both streams into standard output). So realistically, we do need Windows agents in Harbormaster to be running OpenSSHD.
This basically means we need to do two things:
* Configure the OpenSSHD service to run as the correct user. Users could set this up themselves with great difficulty, but it practically needs auto-configuration like D10214 to get it right. I have a later version of this revision that seems to configure everything correctly (and it's quite a bit longer), but I haven't had enough time to test it yet.
* When invoking Powershell on the remote host, we need to run the command under a new Powershell session, which will correctly "login" as the current user and restore all the correct environment variables and Windows nonsense. This will means things like cryptography work again, as well as various other user and permission related things (as well as anything that relies on standard environment variables). I'll be sending through a diff shortly for this.