xpra icon
Bug tracker and wiki

Opened 3 weeks ago

Last modified 4 days ago

#1892 assigned defect

Xpra uses plink from path first instead from program directory

Reported by: Lukas Haase Owned by: Antoine Martin
Priority: major Milestone: 2.4
Component: client Version: 2.3.x
Keywords: Cc:

Description (last modified by Antoine Martin)

This bug report is based on the findings from #1853.

Previously, xpra in Windows used plink.exe that is shipped with Xpra and is in the same directory as Xpra_cmd.exe.

With the newest version (in my case 2.3.2-r19729), it seems that this is not the case and the plink.exe is used that is found in the path.

In my case, this is plink from TortoiseSVN which is broken for normal usage (it returns immidiately after calling).

This is strange behavior because it even appears when I call Xpra_cmd.exe from within the same directory (c:\Program Files\Xpra).

When I use xpra files, I can circumvent this bug by explicitly setting the path:

ssh=c:\\Program Files\\Xpra\\plink.exe -noagent -T

However, when I use the GUI, after some time I get the error:

TortoisePlink Fatal Error: Network error: Connection timed out

again hinting that the wrong plink.exe is being used.

Another important remark: Xpra is started from the start menu link which has C:\Program Files\Xpra set as "Start in".

Change History (15)

comment:1 Changed 3 weeks ago by Antoine Martin

Description: modified (diff)
Milestone: 2.4
Owner: changed from Antoine Martin to Lukas Haase

In my case, this is plink from TortoiseSVN which is broken for normal usage (it returns immideately after calling).

That's odd, because the plink.exe we ship comes from tortoisesvn!
(they patch it with a GUI, which the upstream plink lacks)

Please try the latest beta builds I have uploaded:

  • r19779: missing env settings - probably not essential since this had been broken for a while, maybe this could even be removed
  • r19780: make sure our installation path comes first, so the shell should be finding our copy of plink.exe ahead of any other found on the %PATH%

comment:2 Changed 3 weeks ago by Lukas Haase

It might be that this is fixed with Xpra-x86_64_Setup_2.4-r19780.exe; however, I am facing another issue now:

When I use the GUI I get "SSH connection failure".
However, from my SSH key agent I can see that a public key is requested (that means, contrary to previously, plink does not return immideately).

When I call xpra_cmd.exe from within c:\program files\xpra I get:

Xpra_cmd.exe attach ssh/user@server/1984 -d all
[...]
Traceback (most recent call last):
  File "./xpra/scripts/main.py", line 76, in main
  File "./xpra/scripts/main.py", line 374, in run_mode
  File "./xpra/scripts/main.py", line 1343, in run_client
  File "./xpra/scripts/main.py", line 1465, in get_client_app
  File "./xpra/scripts/main.py", line 1371, in connect
  File "./xpra/scripts/main.py", line 839, in connect_or_fail
InitException: connection failed: environment can only contain strings
xpra initialization error:
 connection failed: environment can only contain strings
Last edited 3 weeks ago by Lukas Haase (previous) (diff)

comment:3 Changed 3 weeks ago by Antoine Martin

When I use the GUI I get "SSH connection failure".

Sorry about that, I didn't test this fix and pushed it out too quickly.

It turns out that we already had a workaround for path issues (related info in #1173), but what happened was that we switched to mingw on win32 (#917) and those python builds now seem to get a little bit confused about path separators between unix "/" and windows style "\".
So r19783 patches that up, our path still comes first, but now it is actually correct. (new beta builds posted)

comment:4 Changed 3 weeks ago by Lukas Haase

Unfortunately no change.

However, maybe my first assumption was wrong and I was using the plink.exe from xpra.
I did not realize that it uses the plink.exe from Tortoise (I have TortoiseSVN and TortoiseGit installed on the system).

Anyway, the "environment can only contain strings" issue is fixed in r19788 but again, I get

C:\Program Files\Xpra>xpra_cmd attach ssh/user@server/1984
2018-06-30 02:35:03,165 Xpra gtk2 client version 2.4-r19788 64-bit
2018-06-30 02:35:03,170  running on Microsoft Windows 10
2018-06-30 02:35:04,071 Warning: failed to import opencv:
2018-06-30 02:35:04,073  DLL load failed: A dynamic link library (DLL) initialization routine failed.
2018-06-30 02:35:04,074  webcam forwarding is disabled
2018-06-30 02:35:04,315 GStreamer version 1.14.1 for Python 2.7.15 64-bit
2018-06-30 02:35:04,494 OpenGL_accelerate module loaded
2018-06-30 02:35:04,509 Using accelerated ArrayDatatype
2018-06-30 02:35:04,889 Warning: vendor 'Intel' is greylisted,
2018-06-30 02:35:04,891  you may want to turn off OpenGL if you encounter bugs
2018-06-30 02:35:04,945 OpenGL enabled with Intel(R) HD Graphics 4000
executing ssh command: "plink" "-ssh" "-agent" "-l" "user" "-T" "server" "xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :1984;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :1984;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :1984;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :1984;else echo "no run-xpra command found"; exit 1; fi"
2018-06-30 02:35:04,960  desktop size is 1366x768 with 1 screen:
2018-06-30 02:35:04,961   Default (361x203 mm - DPI: 96x96) workarea: 1366x738
2018-06-30 02:35:04,962     DISPLAY1 (277x156 mm - DPI: 125x125)
2018-06-30 02:35:04,973  keyboard settings: layout=us
2018-06-30 02:35:05,932 Error: failed to receive anything, not an xpra server?
2018-06-30 02:35:05,935   could also be the wrong protocol, username, password or port
2018-06-30 02:35:05,936   or the session was not found
2018-06-30 02:35:05,938 Connection lost

C:\Program Files\Xpra>

plink --version is reported as TortoisePlink Release 0.68. When I enter

plink -ssh -l user -T server

on the command line it just returns immediately without any message.
However, something seems to work in background -- I receive a message from my SSH agent that it was queried for the SSH key.
I don't know how to debug this.

Last edited 3 weeks ago by Antoine Martin (previous) (diff)

comment:5 Changed 3 weeks ago by Antoine Martin

When I enter
plink -ssh -l user -T server
on the command line it just returns immediately without any message.

That's expected, you're not running any commands on the server.
Try this instead:

plink -ssh -l user -T server ls

And if you see the ls output, then run try running this one (might be easier to type it into a proper ssh session from a terminal):

xpra initenv; \
if [ -x ~/.xpra/run-xpra ]; then \
    ~/.xpra/run-xpra _proxy :1984; \
elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then \
    $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :1984; \
elif type "xpra" > /dev/null 2>&1; then \
    xpra _proxy :1984; \
elif [ -x /usr/local/bin/xpra ]; then \
    /usr/local/bin/xpra _proxy :1984; \
else \
    echo "no run-xpra command found"; \
    exit 1; \
fi

This example is based on comment:4 and assumes that your session on :1984 exists.
If this command succeeds it will print nothing, and will show a protocol error if you send any characters to it. (ie: press enter and you should get an error and it will exit)

comment:6 Changed 3 weeks ago by Lukas Haase

Thanks for helping me debug this ...

Unfortunately not ... when I say it immideately returns it really immideately returns! Within a couple of ms. No way that SSH connections is built up. And I can see in my SSH agent that the key is requested after I'm back to the command line.

Even

plink -ssh -l user -T server "sleep 10"

returns immideately without message/warning/error.

comment:7 Changed 3 weeks ago by Antoine Martin

returns immideately without message/warning/error.

Then maybe it's something more fundamental with your ssh server?
Can you try keeping an eye on the server log as you login via ssh?
Can you login via ssh with putty.exe?
What is the server OS and version?

comment:8 Changed 2 weeks ago by Lukas Haase

Yes, I can connect with PuTTY, ssh, whatever. And also the usual plink.exe that I have in my path:

plink: Release 0.70
Build platform: 64-bit Windows
Compiler: clang 5.0.0 (http://llvm.org/git/clang.git dba970f4d143480b964f77b363ec23f22cea0390) (http://llvm.org/git/llvm.git 52ebe03cb0a728134e66d04f85281bc5a60d7091), emulating Visual Studio 2013 / MSVC++ 12.0 (_MSC_VER=1800)
Source commit: 3cd10509a51edf5a21cdc80aabf7e6a934522d47

plink -l user -T EE-ST uname -a
Linux server 2.6.32-696.30.1.el6.x86_64 #1 SMP Tue May 22 03:28:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

I can only stress again that the plink.exe in the xpra directory immideately (<1ms) returns after I enter the command. I just can't imagine that this is right. Again: It continues somewhat in background (it fetches the SSh key from my agent ... and if I have a password I get the "TortoisePlink?" "Password: " dialog. But since I have no other means to see any messages this ist impossible to debug.
Needless to say, it returns immideately for all arguments and all servers. I just xpra's plink is somewhat broken.

comment:9 Changed 2 weeks ago by Antoine Martin

Needless to say, it returns immediately for all arguments and all servers. I just xpra's plink is somewhat broken.

That's very odd: it works here and it is a straight copy from tortoise.
Can you try overwriting it with the one that does work from tortoiseplink? (you will need to rename it)

Last edited 2 weeks ago by Antoine Martin (previous) (diff)

comment:10 Changed 2 weeks ago by Antoine Martin

I've uploaded new beta builds with a newer copy of TortoisePlink.exe (grabbed from the latest installer they have) here: https://xpra.org/beta/windows.

comment:11 Changed 7 days ago by Ben Jackson

Hi as mentioned on the list, I'm seeing very similar behaviour.

However, i wonder if the "plink" issue is a red herring.

I have tried all of:

  • Latest TortoisePlink
  • Bundled plink.exe with Xpra 2.3
  • PuTTy's plink
  • PuTTY

And after a fashion, they all work.

I think the confusion with Tortoise plink (and thus the bundled plink.exe) is that the command output is not visible (likely because it runs in the Win32 subsystem?). Anyway, using bash.exe (bundled with git for windows), I get the expected output:

ben.jackson@UKWOK-PC1385 Xpra]$ ./plink -ssh ash@ukwok-pc1385-vpc7 echo hello
hello
Last edited 4 days ago by Antoine Martin (previous) (diff)

comment:12 Changed 7 days ago by Ben Jackson

Yep, I can confirm that the command line behaviour of plink is the same on a working system.

This evening I have set up a cantos 7.4 VM and a Windows 10 client connecting to xpra using ssh. This worked fine.

Confirmed that the behaviour of plink.exe shipped with 2.3 is the same on the (working) win10 system and the (non working) win7 system at work. i.e. that it doesn't print to stdout in cmd.exe, but does ask for password and/or obey the pageant ssh agent.

So I suspect the issue "Error: failed to receive anything, not an xpra server?" which we're both getting seems not specifically related to _that_ behaviour of plink.

comment:13 Changed 6 days ago by Ben Jackson

OK, I now understand why this isn't working for me.

The problem in my case is that the user on the remove host uses the 'csh' shell by default.

However, Xpra client code attempts to run a bash script on the remote host via ssh, but when using Plink does *not* run /bin/sh. From the code, it deliberately doesn't do this with PuTTY/plink:

https://www.xpra.org/trac/browser/xpra/trunk/src/xpra/scripts/main.py#L881

I confirmed this by creating a user with useradd -s /bin/csh .... and starting Xpra within that user's environment and connecting from Windows. The exact same failure is experienced. On the same host I create a user with /bin/sh as the shell, and it works.

So I guess the question is : does your remote user use csh (or anything other than a Bourne-shell compatible shell) ?

Antoine, would you like me to raise this as a separate ticket now that I've tracked it down? Unfortunately I haven't been able to verify a _fix_ yet because I'm struggling to get the build process working on windows.

comment:14 Changed 6 days ago by Antoine Martin

Owner: changed from Lukas Haase to Antoine Martin
Status: newassigned

The problem in my case is that the user on the remove host uses the 'csh' shell by default.

I think this qualifies under "anything that would make the setup unusual" from wiki/ReportingBugs.

Here are the changes that led us to this format for the remote SSH command line:

  • #1599: ssh start may run xpra command multiple times
  • #1129: Use XDG_RUNTIME_DIR
  • r13622: we require a posix shell, so make sure we execute one
  • #1000: remote xpra connection fails with fish shell
  • #1407: --ssh not working with new releases
  • r14779: #1407: workaround for putty

The best solution for all this may well be #1646, work on this ticket has started and new builds should appear with this feature soon.

Antoine, would you like me to raise this as a separate ticket now that I've tracked it down?

I think we can just keep using this existing ticket and maybe rename it once we have confirmed that the problem is caused by the login shell. It may be that we close this as 'wonfix' and rely on version >=2.4 and #1646 instead.

Unfortunately I haven't been able to verify a _fix_ yet because I'm struggling to get the build process working on windows.

browser/xpra/trunk/src/win32/MINGW_SETUP.sh and #1883 should help. (ping us there if you get stuck)

comment:15 Changed 6 days ago by Ben Jackson

I think this qualifies under "anything that would make the setup unusual" from wiki/ReportingBugs.

You're probably right. But TBH I didn't even consider that the default shell of the remote user was even vaguely relevant until I read the code :)

Thanks for the pointers. I'll see what I can do about the build and confirmation (unfortunately I can only do it at home).

Note: See TracTickets for help on using tickets.