xpra icon
Bug tracker and wiki

Opened 4 months ago

Closed 4 months ago

#2711 closed enhancement (fixed)

support mswindows 10 openssh server to start shadow

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 4.0
Component: platforms Version: 3.0.x
Keywords: Cc:

Description

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.

Change History (4)

comment:1 Changed 4 months ago by Antoine Martin

Status: newassigned

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:

Last edited 4 months ago by Antoine Martin (previous) (diff)

comment:2 Changed 4 months ago by 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?)

comment:3 Changed 4 months ago by 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)

Last edited 4 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 4 months ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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")
Note: See TracTickets for help on using tickets.