Cannot Shadow Windows Host from Linux Client using SSH #4173

Shaav · 2024-03-22T21:01:30Z

Shaav
Mar 22, 2024

I have a Windows 11 laptop and I am trying to set up desktop shadowing on it to be accessed via a Linux client. Both are using v5.0.7.

On Windows I am starting the shadow server in powershell manually with:
& 'C:\Program Files\Xpra\Xpra_cmd.exe' shadow --bind-ssh=0.0.0.0:14500,auth=none --mdns=0

Everything seems fine: "xpra is ready".

I try to connect to the host with
xpra shadow ssh://user@ip:14500
(with -d ssh and/or --ssh="ssh -vvv" for details).

The ssh connection is successful; however, the command that xpra sends via ssh to start the proxy shadow server fails with "unsupported ssh command":

2024-03-22 15:37:03,203 Connected (version 2.0, client OpenSSH_8.2p1)
2024-03-22 15:37:03,281 Auth granted (none).
2024-03-22 15:37:03,344 Warning: unsupported ssh command:
2024-03-22 15:37:03,344 ['sh', '-c', 'if command -v "xpra" > /dev/null 2>&1; then xpra _proxy_shadow_start "--ssh=ssh -vv" "--debug=ssh" "--env=#silence some AT-SPI and atk-bridge warnings:" "--env=NO_AT_BRIDGE=1" "--env=XPRA_CLIPBOARD_IMAGE_STAMP=0";elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy_shadow_start "--ssh=ssh -vv" "--debug=ssh" "--env=#silence some AT-SPI and atk-bridge warnings:" "--env=NO_AT_BRIDGE=1" "--env=XPRA_CLIPBOARD_IMAGE_STAMP=0";elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy_shadow_start "--ssh=ssh -vv" "--debug=ssh" "--env=#silence some AT-SPI and atk-bridge warnings:" "--env=NO_AT_BRIDGE=1" "--env=XPRA_CLIPBOARD_IMAGE_STAMP=0";elif [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy_shadow_start "--ssh=ssh -vv" "--debug=ssh" "--env=#silence some AT-SPI and atk-bridge warnings:" "--env=NO_AT_BRIDGE=1" "--env=XPRA_CLIPBOARD_IMAGE_STAMP=0";elif [ -x Xpra_cmd.exe ]; then Xpra_cmd.exe _proxy_shadow_start "--ssh=ssh -vv" "--debug=ssh" "--env=#silence some AT-SPI and atk-bridge warnings:" "--env=NO_AT_BRIDGE=1" "--env=XPRA_CLIPBOARD_IMAGE_STAMP=0";else echo "no run-xpra command found"; exit 1; fi']

Any thoughts on why this is happening?

Update
Some additional bits of information that may or may not be relevant:

I have set up the Windows native ssh server—but my understanding is that --bind-ssh uses the xpra-packaged server listening on the specified port and the native one should be ignored.
On the windows ssh server I set the default shell to be powershell
Seeing that "Xpra_cmd.exe" in the command, I thought maybe there was a path problem finding it, so I made sure it was in the global path, but that did not make a difference.

the [ -x Xpra_cmd.exe ] suggests to me that it's expecting to be ssh-ing directly to c:\Program Files\Xpra? Maybe that has been messed up by having the windows ssh server set up?

Update
I tried connecting with:
xpra shadow ssh://user@ip --ssh=paramiko

which it seemed to like better but server-side:

2024-03-22 16:40:15,458 Connected (version 2.0, client paramiko_2.6.0)
2024-03-22 16:40:20,007 Auth granted (none).
2024-03-22 16:40:20,224 Warning: received a '_proxy_shadow_start' session request
2024-03-22 16:40:20,224 this feature is not enabled with the builtin ssh server
2024-03-22 16:40:20,224 Socket exception: An existing connection was forcibly closed by the remote host (10054)
2024-03-22 16:40:20,224 Warning: SSH channel setup failed

totaam · 2024-03-23T02:58:16Z

totaam
Mar 23, 2024
Maintainer

xpra shadow ssh://user@ip:14500

You need to attach to this existing session, not try to start a new one:
xpra attach ssh://user@ip:14500

I tried connecting with:
xpra shadow ssh://user@ip --ssh=paramiko

paramiko should be the default.

1 reply

Shaav Mar 26, 2024
Author

Thanks for the reply!

I was struggling with the documentation about whether it was 'attach' or 'shadow'... wasn't clear to me and I did try attach but before I specified paramiko and it has the same problem—when connecting to the windows ssh server it tries to send a sh command that it doesn't know how to interpret.

paramiko should be the default

That may be, but without --ssh=paramiko, at least in this case, it is definitely connecting to the windows server. I'm guessing it just checks for something listening on 22 first?

attach with --ssh=paramiko seems to get further. It connects, says paramiko SSH agent forwarding enabled and then:
'2024-03-26 10:17:12,847 [chan run-xpra] EOF received (run-xpra)'
'2024-03-26 10:17:12,847 SSH EOF on stderr of run-xpra'
'2024-03-26 10:17:12,848 [chan run-xpra] EOF sent (run-xpra)'
'2024-03-26 10:17:12,849 Connection failed'

On the server side:
Error: ssh connection failed:
packet from <client_ip>:58640
received on 0.0.0.0:14500
invalid packet format, not an expra client?

totaam · 2024-03-27T05:10:40Z

totaam
Mar 27, 2024
Maintainer

I was struggling with the documentation about whether it was 'attach' or 'shadow'.

attach connects to an existing session.
shadow creates a new session.

--bind-ssh=0.0.0.0:14500,auth=none --mdns=0

I'm really not sure what the benefit is of using ssh transport without any authentication.
Try with --bind-tcp / attach tcp://host:port/ and see if that works.

Warning: unsupported ssh command

Looks like a bug. Xpra's builtin ssh server only accepts a very limited set of commands for emulating a real ssh server in order to handle xpra connections over ssh. It looks like it is failing to parse this particular one.

2 replies

Shaav Mar 27, 2024
Author

I'm really not sure what the benefit is of using ssh transport without any authentication.

Obviously that's to simplify testing.

Try with --bind-tcp / attach tcp://host:port/ and see if that works.

It does. Unfortunately, this will not be a device on my local network for long.

Anyway, I give up.

totaam Mar 28, 2024
Maintainer

I have set up the Windows native ssh server—but my understanding is that --bind-ssh uses the xpra-packaged server listening on the specified port and the native one should be ignored.

Correct.

On the windows ssh server I set the default shell to be powershell

This should not make any difference since xpra's builtin ssh server does not shell out - but I guess it is at least theoretically possible that it interferes somehow.

I'm guessing it just checks for something listening on 22 first?

No.

I tried connecting with:
xpra shadow ssh://user@ip --ssh=paramiko
which it seemed to like better but server-side:

ssh=paramiko has been the default for a while now. This is a strong clue that I had missed.

So I tried it, and it worked on the very first attempt.

My guess is that you're not running a supported version on the client side.
Perhaps an outdated Debian or Ubuntu package? (those never ever work properly: https://github.com/Xpra-org/xpra/wiki/Distribution-Packages-Ubuntu )

For the record, this is what my MS Windows server shows when running with -d ssh - after authentication succeeds:

30,776 client authenticated, accepted channel=<paramiko.Channel 1 (open) window=2097152 -> <paramiko.Transport at 0xeba6de90 (cipher
 aes128-ctr, 128 bits) (active; 1 open channel(s))>>
30,777 check_channel_exec_request(<paramiko.Channel 1 (open) window=2097152 -> <paramiko.Transport at 0xeba6de90 (cipher aes128-ctr,
 128 bits) (active; 1 open channel(s))>>, b'REG QUERY "HKEY_LOCAL_MACHINE\\Software\\Xpra" /v InstallPath')
30,777 check_channel_exec_request: cmd=['REG', 'QUERY', 'HKEY_LOCAL_MACHINE\\Software\\Xpra', '/v', 'InstallPath']
30,778 proxy channel=None, timedout=False, exec_response=(0, 'InstallPath E:\\xpra\\dist\r\n', None)
30,778 [chan 1] EOF sent (1)
30,819 [chan 1] EOF received (1)
30,868 check_channel_request(session, 2)
30,868 [chan 2] Max packet in: 32768 bytes
30,869 [chan 2] Max packet out: 4096 bytes
30,869 Secsh channel 2 (session) opened.
30,869 client authenticated, accepted channel=<paramiko.Channel 2 (open) window=134217727 -> <paramiko.Transport at 0xeba6de90 (ciph
er aes128-ctr, 128 bits) (active; 1 open channel(s))>>
30,870 check_channel_forward_agent_request(<paramiko.Channel 2 (open) window=134217727 -> <paramiko.Transport at 0xeba6de90 (cipher
aes128-ctr, 128 bits) (active; 1 open channel(s))>>) SSH_AGENT_DISPATCH=False
30,921 check_channel_exec_request(<paramiko.Channel 2 (open) window=134217727 -> <paramiko.Transport at 0xeba6de90 (cipher aes128-ct
r, 128 bits) (active; 1 open channel(s))>>, b'":\\xpra\\dist\\Xpra_cmd.exe" "_proxy" "--env=SSH_AGENT_UUID=0f6b5789806b67c68a632d27e919f39ac756835aae
b60dbe1443784c696f27c1"')
30,922 check_channel_exec_request: cmd=[':\\xpra\\dist\\Xpra_cmd.exe', '_proxy', '--env=SSH_AGENT_UUID=0f6b5789806b67c68a632d27e919f
39ac756835aaeb60dbe1443784c696f27c1']
30,922 ssh xpra subcommand: _proxy
30,923 ssh 'xpra _proxy' subcommand: display_name='Main', agent=None
30,923 run_proxy(<paramiko.Channel 2 (open) window=134217727 -> <paramiko.Transport at 0xeba6de90 (cipher aes128-ctr, 128 bits) (act
ive; 1 open channel(s))>>) proxy-channel=None
30,923 New ssh connection received
30,924  from '192.168.0.10:52516'
30,924  on '0.0.0.0:14500'
30,964 Handshake complete; enabling connection
31,070 Python/GTK3 Linux Fedora 39 X11 client version 6.0
31,071  connected as 'Windows10'
31,071  OpenGL is enabled using glx backend with AMD Radeon RX 570 Series radeonsi, polaris10, LLVM 17.0.6, DRM 3.57, 6.7.9-200.fc39
.x8664

totaam · 2024-07-05T05:58:49Z

totaam
Jul 5, 2024
Maintainer

Not heard back, closing.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

xpra.org

Cannot Shadow Windows Host from Linux Client using SSH #4173

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 3 comments 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

xpra.org

Cannot Shadow Windows Host from Linux Client using SSH #4173

Uh oh!

Uh oh!

Shaav Mar 22, 2024

Replies: 3 comments · 3 replies

Uh oh!

Uh oh!

totaam Mar 23, 2024 Maintainer

Uh oh!

Shaav Mar 26, 2024 Author

Uh oh!

totaam Mar 27, 2024 Maintainer

Uh oh!

Shaav Mar 27, 2024 Author

Uh oh!

totaam Mar 28, 2024 Maintainer

Uh oh!

totaam Jul 5, 2024 Maintainer

Shaav
Mar 22, 2024

Replies: 3 comments 3 replies

totaam
Mar 23, 2024
Maintainer

Shaav Mar 26, 2024
Author

totaam
Mar 27, 2024
Maintainer

Shaav Mar 27, 2024
Author

totaam Mar 28, 2024
Maintainer

totaam
Jul 5, 2024
Maintainer