#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 (5)
comment:1 Changed 12 months ago by
Status: | new → assigned |
---|
comment:2 Changed 12 months ago by
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 12 months ago by
Updates:
- r26177: refactoring of proxy startup code
- r26176 + r26178: close fdproxy process more reliably
- r26179 store installation path in registry
- r26180 run
Xpra.exe
viapaexec
(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)
comment:4 Changed 12 months ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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")
comment:5 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2711
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: