support mswindows 10 openssh server to start shadow

[Antoine Martin]

After installing the openssh server for windows 10 through the "additional features", one must go through extra hoops to actually make it work (...)
​Security protection of various files in Win32 OpenSSH gives you a hint (use icacls), the real fix for me was found here: ​Windows SSH: Permissions for 'private-key' are too open:

:: # Remove Inheritance ::
Cmd /c Icacls %Key% /c /t /Inheritance:d

See also: ​Troubleshooting Steps.

---

Once that's working properly, I can start a shadow server on the Winlogon secure desktop using ​psexec:

windows 10 test@DESKTOP-Q4IVN7P C:\Users\Windows 10 Test>psexec -x -s  "C:\\Program Files\\Xpra\\xpra.exe" "shadow" "--bind-tcp=0.0.0.0:10000"

Problem with this is that the shadow server stops working (blank screen) as soon as we login. But this may still help with #1527.

If the user is logged in, then we need:

psexec -i 1 "C:\\Program Files\\...

(after using quser to locate the session id)
It sort of works: the xpra process is started and we can connect to it (xpra stop, xpra info etc), but the screen dimensions are bogus so we can't xpra attach to it.
When using xpra_cmd.exe or clicking on About in the shadow systray, the cmd.exe and about windows are all black so clearly something is still missing to access the GUI session properly.

[Antoine Martin]

Minor fixes: r26018, r26019, r26021, r26022.

The solution to the black window is just to add -s (system privileges), as suggested here: ​PsExec runs remote GUI as black screen - Windows7. Maybe the same solution can be applied to #1527.

Some problems with using psexec:

• no source, no redestribution possible, but ​paexec can do both! (source: ​https://github.com/poweradminllc/PAExec)
• ​PsExec and the Nasty Things It Can Do: Antivirus Detection - This used to not be as much of an issue, but now that most virus scanning applications do some level of system and memory monitoring most of them will catch PsExec being used on the system they are monitoring. - I can confirm adding READ_CONTROL as well as WINSTA_ALL_ACCESS to the access permissions for the window station has resolved it.
• ​Lateral Movement with PSExec: psexec used to spread across networks

[Antoine Martin]

Almost works as of r26171 + r26172.

Still TODO:

• the proxy command only works if the shadow server already exists (at least from an msys2 shell) - something to do with file descriptors perhaps?
• generate an ssh command that will work with both posix shells and win32 dos (see ​Single script to run in both Windows batch and Linux Bash?) - without breaking our builtin ssh server command detection..

Installation paths issues: maybe generate a "run-xpra" script in %APPDATA%?
(that way we don't have to assume xpra is installed in C:\Program Files\Xpra)
This can also take care of invoking the paexec wrapper.
(but needs to be done as a post-install step to ensure it is always present?)

[Antoine Martin]

Updates:

• r26177: refactoring of proxy startup code
• r26176 + r26178: close fdproxy process more reliably
• r26179 store installation path in registry
• r26180 run Xpra.exe via paexec (paramiko backend only)

It almost works using:

xpra shadow "ssh://user:password@IP/" --remote-xpra=xpra.exe -d ssh --bind-tcp=0.0.0.0:10000

the shadow server starts and we can connect to it via TCP.
But the fdproxy errors out because stdin and stdout are not connected. (we run Xpra.exe which is a GUI process).
Running Xpra_cmd.exe does not help: the CMD window shows up, but the stdin and stdout pipes are silent..

(paexec is not bundled in by default since this does not work fully yet)

[Antoine Martin]

Finally working as of r26182 + r26183.
ie:

xpra shadow "ssh://user:password@IP/" -d ssh
(..)
Authentication (password) successful!
(..)
run_test_command('which $XDG_RUNTIME_DIR/xpra/run-xpra')
(..)
using 'C:\\Program Files\\Xpra\\Xpra_cmd.exe'
channel exec_command("C:\\Program Files\\Xpra\\Xpra_cmd.exe" "_proxy_shadow_start" "--password=password" "--debug=ssh")