Xpra trac archive

Xpra: Ticket #1892: ms windows clients require ssh users to have bash as login shell

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".


Sat, 30 Jun 2018 07:00:21 GMT - Antoine Martin: owner, description changed; milestone set

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:

Sat, 30 Jun 2018 07:28:02 GMT - 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

Sat, 30 Jun 2018 09:04:32 GMT - 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)

Sat, 30 Jun 2018 09:38:17 GMT - 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.

Mon, 02 Jul 2018 07:58:21 GMT - 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)

Mon, 02 Jul 2018 21:16:26 GMT - 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.

Tue, 03 Jul 2018 04:14:12 GMT - 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?

Fri, 06 Jul 2018 05:16:47 GMT - 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.

Fri, 06 Jul 2018 05:55:44 GMT - 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)

Fri, 06 Jul 2018 07:07:05 GMT - 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.

Mon, 16 Jul 2018 17:49:06 GMT - 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:

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

Mon, 16 Jul 2018 19:40:25 GMT - 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.

Mon, 16 Jul 2018 23:18:01 GMT - 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.

Tue, 17 Jul 2018 09:16:27 GMT - Antoine Martin: owner, status changed

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:

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)

Tue, 17 Jul 2018 09:45:25 GMT - 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).

Tue, 21 Aug 2018 12:25:25 GMT - Antoine Martin: status, summary changed; resolution set

I've changed the ticket summary since this has nothing to do with PATH or which plink is used. If someone can submit a shell syntax that is more compatible than the one we have, I could merge that in 2.3.

I'm going to close this as "fixed", though you will need to use version 2.4 or later to get the new ssh code (#1646). It would be nice if someone could confirm that the problem has gone away using those 2.4 beta builds: https://xpra.org/beta/windows

Wed, 22 Aug 2018 12:28:36 GMT - Ben Jackson:

I have just installed https://xpra.org/beta/windows/Xpra-Client-x86_64_Setup.exe 

C:\Program Files\Xpra>xpra_cmd --version
xpra v2.4-r19583

I get the exact same behaviour. I can see from the debug log that it is still running plink.exe. Is that expected ? I feel like that revision number is too low. Was that the wrong thing to install?

From the debug log: 

2018-08-22 13:18:45,243 add_process(<subprocess.Popen object at 0x00000000056a63d0>, ssh, ['plink', '-ssh', '-agent', '-l', 'benj', '-T', 'ukwok-pc1385-vpc7', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :1009;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :1009;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :1009;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :1009;else echo "no run-xpra command found"; exit 1; fi'], True, False) pid=34240

Wed, 22 Aug 2018 12:36:07 GMT - Antoine Martin:

xpra v2.4-r19583

No, that's too old. There aren't any newer "client-only" builds, so just download a "regular" Xpra-x86_64 exe.

Thu, 23 Aug 2018 09:55:22 GMT - Ben Jackson:

Now running: 

C:\Program Files\Xpra>xpra_cmd  --version
xpra v2.4-r20131

I get the same result. 

C:\Program Files\Xpra>Xpra_cmd.exe attach ssh://benj@ukwok-pc1385-vpc7/1009
2018-08-23 10:53:47,131 Xpra gtk2 client version 2.4-r20131 64-bit
2018-08-23 10:53:47,136  running on Microsoft Windows 7
2018-08-23 10:53:47,281 Warning: failed to import opencv:
2018-08-23 10:53:47,282  No module named cv2
2018-08-23 10:53:47,282  webcam forwarding is disabled
2018-08-23 10:53:48,869 GStreamer version 1.14.2 for Python 2.7.15 64-bit
2018-08-23 10:53:49,340  keyboard settings: layout=gb
2018-08-23 10:53:49,342  desktop size is 3000x1920 with 1 screen:
2018-08-23 10:53:49,342   Default (793x508 mm - DPI: 96x96)
2018-08-23 10:53:49,343     DISPLAY1 1920x1200 at 0x381 (677x423 mm - DPI: 72x72
) workarea: 1920x1200
2018-08-23 10:53:49,343     DISPLAY2 1080x1920 at 1920x0 (381x677 mm - DPI: 72x7
2) workarea: 1080x1920
2018-08-23 10:53:50,895 Error: failed to receive anything, not an xpra server?
2018-08-23 10:53:50,895   could also be the wrong protocol, username, password o
r port
2018-08-23 10:53:50,895   or the session was not found
2018-08-23 10:53:50,896 Connection lost

From the debug log (gist: https://gist.github.com/puremourning/975216d3c79ff1864a7339ff9fe09e41) 

2018-08-23 10:48:16,405 add_process(<subprocess.Popen object at 0x0000000004d0ae90>, ssh, ['plink', '-ssh', '-agent', '-l', 'benj', '-T', 'ukwok-pc1385-vpc7', '#run-xpra _proxy :1009;\nxpra initenv;if [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :1009;elif [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :1009;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :1009;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :1009;else echo "no run-xpra command found"; exit 1; fi'], True, False) pid=15080

Thu, 23 Aug 2018 10:30:30 GMT - Antoine Martin:

That's odd, I'll take a look. In the meantime, you can force it to use the paramiko backend with --ssh=paramiko. The most useful debug switch will be -d ssh.

Thu, 23 Aug 2018 11:43:36 GMT - Antoine Martin:

Oh, here's why: ssh=paramiko is the default on all platforms, except on mswindows. (we've kept ssh=plink -ssh -agent on mswindows to minimize changes - as it already provides a GUI for passwords and keys) That's unfortunate since this bug also only affects mswindows clients... Until the default is changed, try with --ssh=paramiko (and r20174 or later to fix a refactoring blooper)

Thu, 23 Aug 2018 12:10:15 GMT - Ben Jackson:

Thanks, Antoine.

Haven't yet got 20174, but I am getting the following which looks unrelated: 

xpra initialization error:
 connection failed: coercing to Unicode: need string or buffer, NoneType found

C:\Program Files\Xpra>xpra_cmd --version
xpra v2.4-r20131

Full output: 

C:\Program Files\Xpra>Xpra_cmd.exe --debug=ssh --ssh=paramiko attach ssh://benj@
ukwok-pc1385-vpc7/1009
2018-08-23 13:09:46,442 Xpra gtk2 client version 2.4-r20131 64-bit
2018-08-23 13:09:46,447  running on Microsoft Windows 7
2018-08-23 13:09:46,587 Warning: failed to import opencv:
2018-08-23 13:09:46,587  No module named cv2
2018-08-23 13:09:46,588  webcam forwarding is disabled
2018-08-23 13:09:48,084 GStreamer version 1.14.2 for Python 2.7.15 64-bit
2018-08-23 13:09:48,851 SSH transport <paramiko.Transport at 0x54b7e90L (unconne
cted)>
2018-08-23 13:09:48,853 Connected (version 2.0, client OpenSSH_7.4)
2018-08-23 13:09:49,045 remote_server_key=MD5:b5:db:82:c5:27:1d:b1:44:dd:e8:94:c
8:6c:08:57:dc
2018-08-23 13:09:49,046 host keys=<paramiko.hostkeys.HostKeys object at 0x000000
00054a3f10>
2018-08-23 13:09:49,046 Warning: unknown SSH host
The authenticity of host 'ukwok-pc1385-vpc7' can't be established.
ed25519 key fingerprint is
MD5:b5:db:82:c5:27:1d:b1:44:dd:e8:94:c8:6c:08:57:dc
Are you sure you want to continue connecting (yes/NO)? yes
2018-08-23 13:09:58,962 adding ed25519 key for host 'ukwok-pc1385-vpc7' to 'None
'
xpra initialization error:
 connection failed: coercing to Unicode: need string or buffer, NoneType found

Thu, 23 Aug 2018 12:23:18 GMT - Ben Jackson:

OK I worked around that by creating the known_hosts file in the path reported by python os.path.expanduser( '~/.ssh/known_hosts' )

The result of that is the following: 

2018-08-23 13:22:11,250 Xpra gtk2 client version 2.4-r20131 64-bit
2018-08-23 13:22:11,256  running on Microsoft Windows 7
2018-08-23 13:22:11,398 Warning: failed to import opencv:
2018-08-23 13:22:11,398  No module named cv2
2018-08-23 13:22:11,399  webcam forwarding is disabled
2018-08-23 13:22:13,150 GStreamer version 1.14.2 for Python 2.7.15 64-bit
2018-08-23 13:22:13,937 SSH transport <paramiko.Transport at 0x527ca90L (unconnected)>
2018-08-23 13:22:13,939 Connected (version 2.0, client OpenSSH_7.4)
2018-08-23 13:22:14,131 remote_server_key=MD5:b5:db:82:c5:27:1d:b1:44:dd:e8:94:c8:6c:08:57:dc
2018-08-23 13:22:14,133 HostKeys.load(~/.ssh/known_hosts) successful
2018-08-23 13:22:14,133 host keys=<paramiko.hostkeys.HostKeys object at 0x000000000526bb10>
2018-08-23 13:22:14,133 ed25519 host key 'MD5:b5:db:82:c5:27:1d:b1:44:dd:e8:94:c8:6c:08:57:dc' OK for host 'ukwok-pc1385-vpc7'
2018-08-23 13:22:14,133 starting authentication
2018-08-23 13:22:14,133 trying none authentication
2018-08-23 13:22:14,197 auth_none()
Traceback (most recent call last):
  File "./xpra/net/ssh.py", line 340, in auth_none
  File "C:/msys64/mingw64/lib/python2.7/site-packages/paramiko-2.4.1-py2.7.egg/paramiko/transport.py", line 1318, in auth_none
  File "C:/msys64/mingw64/lib/python2.7/site-packages/paramiko-2.4.1-py2.7.egg/paramiko/auth_handler.py", line 226, in wait_for_response
BadAuthenticationType: ('Bad authentication type', [u'publickey', u'gssapi-keyex', u'gssapi-with-mic', u'password']) (allowed_types=[u'publickey', u'gssapi-keyex', u'gssapi-with-mic', u'password'])
2018-08-23 13:22:14,211 agent keys: (<paramiko.agent.AgentKey object at 0x00000000087a5fd0>,)
2018-08-23 13:22:14,212 trying ssh-agent key 'MD5:f5:b1:90:a6:4d:9a:d2:d5:c1:89:e0:e7:6c:1d:e4:3f'
2018-08-23 13:22:14,295 Authentication (publickey) successful!
2018-08-23 13:22:14,312 authenticated using agent and key 'MD5:f5:b1:90:a6:4d:9a:d2:d5:c1:89:e0:e7:6c:1d:e4:3f'
2018-08-23 13:22:14,312 will try to run xpra from: ['$XDG_RUNTIME_DIR/xpra/run-xpra', '~/.xpra/run-xpra', 'xpra', '/usr/local/bin/xpra']
2018-08-23 13:22:14,615 exec_command('type $XDG_RUNTIME_DIR/xpra/run-xpra')
2018-08-23 13:22:14,622 exit status is not ready yet, sleeping
2018-08-23 13:22:14,632 exit status is not ready yet, sleeping
2018-08-23 13:22:14,642 exit status is not ready yet, sleeping
2018-08-23 13:22:14,652 exit status is not ready yet, sleeping
2018-08-23 13:22:14,662 exit status is not ready yet, sleeping
2018-08-23 13:22:14,672 exit status is not ready yet, sleeping
2018-08-23 13:22:14,682 exit status is not ready yet, sleeping
2018-08-23 13:22:14,692 exit status is not ready yet, sleeping
2018-08-23 13:22:14,702 exit status is not ready yet, sleeping
2018-08-23 13:22:14,712 exit status is not ready yet, sleeping
2018-08-23 13:22:14,722 exit status is not ready yet, sleeping
2018-08-23 13:22:14,732 exit status is not ready yet, sleeping
2018-08-23 13:22:14,742 exit status is not ready yet, sleeping
2018-08-23 13:22:14,752 exit status is not ready yet, sleeping
2018-08-23 13:22:14,762 exit status is not ready yet, sleeping
2018-08-23 13:22:14,772 exit status is not ready yet, sleeping
2018-08-23 13:22:14,782 exit status is not ready yet, sleeping
2018-08-23 13:22:14,792 exit status is not ready yet, sleeping
2018-08-23 13:22:14,802 exit status is not ready yet, sleeping
2018-08-23 13:22:14,812 exec_command('type $XDG_RUNTIME_DIR/xpra/run-xpra')=1
2018-08-23 13:22:14,875 exec_command('type ~/.xpra/run-xpra')
2018-08-23 13:22:14,881 exit status is not ready yet, sleeping
2018-08-23 13:22:14,891 exit status is not ready yet, sleeping
2018-08-23 13:22:14,901 exit status is not ready yet, sleeping
2018-08-23 13:22:14,911 exit status is not ready yet, sleeping
2018-08-23 13:22:14,921 exit status is not ready yet, sleeping
2018-08-23 13:22:14,931 exit status is not ready yet, sleeping
2018-08-23 13:22:14,941 exit status is not ready yet, sleeping
2018-08-23 13:22:14,951 exit status is not ready yet, sleeping
2018-08-23 13:22:14,961 exit status is not ready yet, sleeping
2018-08-23 13:22:14,971 exit status is not ready yet, sleeping
2018-08-23 13:22:14,981 exit status is not ready yet, sleeping
2018-08-23 13:22:14,991 exit status is not ready yet, sleeping
2018-08-23 13:22:15,001 exit status is not ready yet, sleeping
2018-08-23 13:22:15,011 exit status is not ready yet, sleeping
2018-08-23 13:22:15,021 exit status is not ready yet, sleeping
2018-08-23 13:22:15,031 exit status is not ready yet, sleeping
2018-08-23 13:22:15,041 exit status is not ready yet, sleeping
2018-08-23 13:22:15,052 exec_command('type ~/.xpra/run-xpra')=1
2018-08-23 13:22:15,115 exec_command('type xpra')
2018-08-23 13:22:15,121 exit status is not ready yet, sleeping
2018-08-23 13:22:15,131 exit status is not ready yet, sleeping
2018-08-23 13:22:15,141 exit status is not ready yet, sleeping
2018-08-23 13:22:15,151 exit status is not ready yet, sleeping
2018-08-23 13:22:15,161 exit status is not ready yet, sleeping
2018-08-23 13:22:15,171 exit status is not ready yet, sleeping
2018-08-23 13:22:15,181 exit status is not ready yet, sleeping
2018-08-23 13:22:15,191 exit status is not ready yet, sleeping
2018-08-23 13:22:15,201 exit status is not ready yet, sleeping
2018-08-23 13:22:15,211 exit status is not ready yet, sleeping
2018-08-23 13:22:15,221 exit status is not ready yet, sleeping
2018-08-23 13:22:15,231 exit status is not ready yet, sleeping
2018-08-23 13:22:15,241 exit status is not ready yet, sleeping
2018-08-23 13:22:15,251 exit status is not ready yet, sleeping
2018-08-23 13:22:15,261 exit status is not ready yet, sleeping
2018-08-23 13:22:15,271 exit status is not ready yet, sleeping
2018-08-23 13:22:15,281 exit status is not ready yet, sleeping
2018-08-23 13:22:15,291 exec_command('type xpra')=1
2018-08-23 13:22:15,354 exec_command('type /usr/local/bin/xpra')
2018-08-23 13:22:15,360 exit status is not ready yet, sleeping
2018-08-23 13:22:15,370 exit status is not ready yet, sleeping
2018-08-23 13:22:15,380 exit status is not ready yet, sleeping
2018-08-23 13:22:15,390 exit status is not ready yet, sleeping
2018-08-23 13:22:15,400 exit status is not ready yet, sleeping
2018-08-23 13:22:15,410 exit status is not ready yet, sleeping
2018-08-23 13:22:15,420 exit status is not ready yet, sleeping
2018-08-23 13:22:15,430 exit status is not ready yet, sleeping
2018-08-23 13:22:15,440 exit status is not ready yet, sleeping
2018-08-23 13:22:15,450 exit status is not ready yet, sleeping
2018-08-23 13:22:15,460 exit status is not ready yet, sleeping
2018-08-23 13:22:15,470 exit status is not ready yet, sleeping
2018-08-23 13:22:15,480 exit status is not ready yet, sleeping
2018-08-23 13:22:15,490 exit status is not ready yet, sleeping
2018-08-23 13:22:15,500 exit status is not ready yet, sleeping
2018-08-23 13:22:15,510 exit status is not ready yet, sleeping
2018-08-23 13:22:15,520 exit status is not ready yet, sleeping
2018-08-23 13:22:15,530 exit status is not ready yet, sleeping
2018-08-23 13:22:15,540 exec_command('type /usr/local/bin/xpra')=1
xpra initialization error:
 connection failed: all SSH remote proxy commands have failed
Press Enter to close

Thu, 23 Aug 2018 14:29:11 GMT - Antoine Martin:

OK I worked around that by creating the known_hosts file in the path reported by python os.path.expanduser( '~/.ssh/known_hosts' )

Oh, good catch! I've clearly not tested paramiko with mswindows clients enough. r20178 will create the known_hosts file if it doesn't exist, as well as the parent ssh directory (note: that is now changed to just ssh instead of .ssh on mswindows), taking care of setting correct file permissions. New mswindows beta uploaded.

connection failed: all SSH remote proxy commands have failed

That's weird, it tries to detect the xpra command to run using: 

type $XDG_RUNTIME_DIR/xpra/run-xpra
type ~/.xpra/run-xpra
type xpra
type /usr/local/bin/xpra

Surely one of those commands should succeed and return 0? (they all return 1 in your log sample) Can you try it from a plain ssh login? I've tried it with csh and tcsh, type somecommand does run and set the exit code as expected, then the client connects.

Thu, 23 Aug 2018 15:36:05 GMT - Ben Jackson:

Thanks so much for checking!

well, it's pretty clear what the problem is: 

ukwok-pc1385-vpc7(benj) users/benj>type $XDG_RUNTIME_DIR/
type: Command not found.
ukwok-pc1385-vpc7(benj) users/benj>echo $shell
/usr/bin/csh
ukwok-pc1385-vpc7(benj) users/benj>tcsh
...
ukwok-pc1385-vpc7(benj) users/benj>type test
type: Command not found.
ukwok-pc1385-vpc7(benj) users/benj>echo $shell
/bin/tcsh

I think type is a bash builtin. At least, when i type 'man type' I get the bash manpage. 

ukwok-pc1385-vpc7(benj) users/benj>sh -c 'type .'
. is a shell builtin
ukwok-pc1385-vpc7(benj) users/benj>sh -c 'type test'
test is a shell builtin
ukwok-pc1385-vpc7(benj) users/benj>sh -c 'type xpra'
xpra is /bin/xpra

ukwok-pc1385-vpc7(benj) users/benj>csh --version
tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec

This is RHEL 7 I am running on for reference.

Normally, I would use which for this, like suggested here: https://unix.stackexchange.com/questions/303121/what-is-the-equivalent-of-type-used-in-bash-and-sh-in-csh

I'll see if I can stick an alias in for type to which... 

ukwok-pc1385-vpc7(benj) users/benj>alias type which
ukwok-pc1385-vpc7(benj) users/benj>type xpra
/bin/xpra
ukwok-pc1385-vpc7(benj) users/benj>echo %?
echo: No match.
ukwok-pc1385-vpc7(benj) users/benj>type xpra
/bin/xpra
ukwok-pc1385-vpc7(benj) users/benj>echo $?
0

And that works. Huzzah! Thanks so much!

Thu, 23 Aug 2018 16:12:52 GMT - Antoine Martin: status changed; resolution deleted

I think type is a bash builtin. At least, when i type 'man type' I get the bash manpage.

As per that link, it works for others with csh and tcsh - not sure how, but since it doesn't with centos7, we'll need a fix no matter what (re-opening ticket)... which looks like a straightforward replacement for type. We'll have to support both options in the new ssh server backend (#1920).

Fri, 24 Aug 2018 05:40:12 GMT - Lukas Haase:

I just wanted to chime in and confirm that this seems to be my original issue as well!

Thanks Ben & Antoine for debugging this!

I also have non-bash set as default shell (tcsh).

With the latest Debug build (2.4-r20180) I can now reproduce exactly what Ben wrote:

With the latest 2.4-r20180, on the command line with paramiko and adding 

alias type which

into my ~/.cshrc

it finally works. However:

1.) It does not work with Xpra-Launcher.exe and an xpra file: 

username=user
encoding=rgb
ssh_port=22
speed=0
min-speed=0
host=server
min-quality=30
mode=ssh
ssh=paramiko
opengl=no
password=
quality=0
port=1984
autoconnect=True
speaker=off

2.) It would still much rather use an external ssh because I have the following line in my xpra file: 

ssh=c:\\Program Files\\Xpra\\plink.exe -noagent -T -i c:\\Users\\user\\AppData\\Roaming\\Xpra\\server.ppk

That means, I eplicitely disable querying the Agent and statically suppling an SSH key.

Fri, 24 Aug 2018 06:23:02 GMT - Antoine Martin: owner, status changed

With the latest Debug build (2.4-r20180) I can now reproduce exactly what Ben wrote: Issue with known_hosts

Can you post the full debug output for this problem? As per comment:24, r20178 should create files and directories as needed.

Issue with type and the same debug output alias type which

r20183 switches to which so this workaround should no longer be necessary. (r20184 also improves support for this in the builtin ssh server) New beta builds uploaded.

1.) It does not work with Xpra-Launcher.exe and an xpra file:

Will check. The GUI is meant to use dialogs to prompt for keys and passwords, that could be the problem.

2.) It would still much rather use an external ssh because I have the following line in my xpra file: (..)

That should still work, doesn't it? Setting ssh=somecommand will also override ssh=paramiko if we ever made this the default on mswindows.

Fri, 24 Aug 2018 10:49:35 GMT - Ben Jackson:

One problem I am seeing is that I can't seem to get Xpra client to use paramiko by default.

I have tried:

It still seems to fail and use plink.exe: 

2018-08-24 11:47:47,904 add_process(<subprocess.Popen object at 0x0000000004ba9350>, ssh, ['plink', '-ssh', '-agent', '-l', 'benj', '-T', 'ukwok-pc1385-vpc7', '#run-xpra _proxy :1009;\nxpra initenv;if [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :1009;elif [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :1009;elif which "xpra" > /dev/null 2>&1; then xpra _proxy :1009;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :1009;else echo "no run-xpra command found"; exit 1; fi'], True, False) pid=9908

However if i run from the command line with --ssh=paramiko it works great.

Am I doing something dumb?

Fri, 24 Aug 2018 12:01:38 GMT - Antoine Martin:

Am I doing something dumb?

Not really, this is badly documented. Try running: 

Path_info.exe

The last two paths you tried (starting with C:\Program Files\Xpra\etc\xpra\...) may not work since we actually use %PROGRAMDATA%/Xpra/ now. Maybe we should delete this old location completely, I'll look into it.

As for the the first one, this isn't where config files are stored on mswindows, try: %APPDATA%\Xpra\.

Fri, 24 Aug 2018 12:14:08 GMT - Antoine Martin:

I forgot to mention, there's an easier way to figure out what settings are used: 

xpra_cmd showconfig

And to take this even further: 

set XPRA_DEBUG_CONFIG_PROPERTIES=ssh
xpra_cmd showconfig

Fri, 24 Aug 2018 12:47:17 GMT - Ben Jackson:

Thanks a lot! It *was& dumb, because I already have a config file in %APPDATA%/Xpra/xpra.conf. So I should have known. Apologies.

Setting it in there works great from the command line (Xpra_cmd.exe), but when attempting connection from the GUI, I see it saying "Starting paramiko tunnel", but then the UI disappears and it doesn't connect.

I guess that's the same issue that Lukas was seeing ?

Sun, 26 Aug 2018 16:22:00 GMT - Antoine Martin:

I see it saying "Starting paramiko tunnel", but then the UI disappears and it doesn't connect. I guess that's the same issue that Lukas was seeing ?

Yes, and here are the numerous fixes required to get this component to behave:

Related improvements:

Some of these fixes will be backported. New beta builds uploaded, ssh should now work with the launcher (both with the paramiko backend and the old putty plink one), it does here.

Sun, 26 Aug 2018 19:02:22 GMT - Lukas Haase:

Cool, thank you!

With r20208 my xpra file works with "ssh=paramiko"! With my old SSH file: 

c:\\Program Files (x86)\\Xpra\\plink.exe -noagent -T -i c:\\Users\\user\\AppData\\Roaming\\Xpra\\server.ppk

I still get "Connection lost".

On the side, with this version a huge amount of tray icons are created (and are not properly released), e.g.:

Many of them disappear once I hover over them with the mouse (an indication stat Shell_NotifyIcon(NIM_DELETE, ...) is not called).

Some of them stay while xpra process is running.

(I can open a separate ticket on that one for better tracking)

Sun, 26 Aug 2018 19:02:50 GMT - Lukas Haase: attachment set

Sun, 26 Aug 2018 19:14:19 GMT - Antoine Martin:

c:\\Program Files (x86)\\Xpra\\plink.exe -noagent -T -i c:\\Users\\user\\AppData\\Roaming\\Xpra\\server.ppk

Any particular reason why this is pointing to a 32-bit installation? Are you using 32-bit builds? Since the xpra installation path is added to %PATH%, you should be able to use this instead: ssh=plink.exe -noagent -R -i ...\\server.ppk (which has the advantage of being more portable)

I still get "Connection lost".

Can you try:

(and post the output - beware: it may log authentication details, ie: passwords)

I am aware of the tray icon issue, will fix tomorrow.

Mon, 27 Aug 2018 05:38:12 GMT - Antoine Martin:

Many of them disappear once I hover over them with the mouse (an indication stat Shell_NotifyIcon(NIM_DELETE, ...) is not called).

It was being called, but then we were creating a new one again before the main loop had a chance to run. r20214 fixes that. (r20213 also ensures that the tray menu options are in a consistent state: most should not be accessible until the client has successfully connected to the server)

Tue, 28 Aug 2018 12:59:44 GMT - totaamwin32:

There were still some systray cleanup issues (race conditions), so r20223 takes a more drastic approach to resolve this. The systray icon is no longer shown with the launcher window, only when the client actually starts. (ie: when we try to connect)

Thu, 30 Aug 2018 14:47:31 GMT - Ben Jackson:

Just tried the latest beta. Worked great.

Thu, 30 Aug 2018 15:34:23 GMT - Ben Jackson:

Spoke too soon.

The latest build seem to have a problem with minimizing and restoring windows.

I use virtuawin on windows (a sort of desktop manager) which hides/restores windows. With the latest build they are not coming back after being hidden.

i see this in the log: 

C:\Program Files\Xpra>xpra_cmd attach ssh://benj@ukwok-pc1385-vpc7/1009
2018-08-30 16:32:53,431 Xpra gtk2 client version 2.4-r20230 64-bit
2018-08-30 16:32:53,437  running on Microsoft Windows 7
2018-08-30 16:32:53,589 Warning: failed to import opencv:
2018-08-30 16:32:53,589  No module named cv2
2018-08-30 16:32:53,590  webcam forwarding is disabled
2018-08-30 16:32:55,530 GStreamer version 1.14.2 for Python 2.7.15 64-bit
2018-08-30 16:32:56,485 Connected (version 2.0, client OpenSSH_7.4)
2018-08-30 16:32:56,820 Authentication (publickey) successful!
2018-08-30 16:32:57,426  keyboard settings: layout=us
2018-08-30 16:32:57,428  desktop size is 3000x1920 with 1 screen:
2018-08-30 16:32:57,428   Default (793x508 mm - DPI: 96x96)
2018-08-30 16:32:57,428     DISPLAY1 1920x1200 at 0x381 (677x423 mm - DPI: 72x72
) workarea: 1920x1200
2018-08-30 16:32:57,429     DISPLAY2 1080x1920 at 1920x0 (381x677 mm - DPI: 72x7
2) workarea: 1080x1920
2018-08-30 16:32:59,391 enabled remote logging
2018-08-30 16:32:59,394 Xpra X11 server version 2.3.2-r19729 64-bit
2018-08-30 16:32:59,395  running on Linux RedHatEnterpriseServer 7.4 Maipo
2018-08-30 16:33:00,121 Attached to ukwok-pc1385-vpc7:22 via ssh
2018-08-30 16:33:00,122  (press Control-C to detach)
2018-08-30 16:33:00,162 unknown string message: 0xc0a2L / 0x52 / 0x5ab
2018-08-30 16:33:00,163 unknown string message: 0xc0a2L / 0x50 / 0x0
2018-08-30 16:33:00,221 unknown string message: 0xc0a2L / 0x52 / 0x5ac
2018-08-30 16:33:00,223 unknown string message: 0xc0a2L / 0x50 / 0x0
C:\Program Files\Xpra/lib/xpra/clipboard/clipboard_base.py:775: GtkWarning: gdk_
property_change: assertion 'type != GDK_TARGET_STRING' failed
2018-08-30 16:33:13,366 failed to fixup window style
Traceback (most recent call last):
  File "./xpra/platform/win32/gui.py", line 415, in fixup_window_style
  File "./xpra/client/mixins/window_manager.py", line 866, in reinit_window
TypeError: make_new_window() takes exactly 13 arguments (11 given)
2018-08-30 16:33:22,362 unknown string message: 0xc0a2L / 0x50 / 0x0
2018-08-30 16:33:22,364 unknown string message: 0xc0a2L / 0x50 / 0x0

Thu, 30 Aug 2018 16:02:22 GMT - Antoine Martin:

The latest build seem to have a problem with minimizing and restoring windows. TypeError: make_new_window() takes exactly 13 arguments (11 given)

Sorry about that. This issue is unrelated and already fixed, see ticket:1941#comment:11. (untested as my mswindows VM doesn't have opengl) (new beta build uploaded - though some changes are still pending for #1941)

Thu, 30 Aug 2018 16:41:57 GMT - Antoine Martin:

untested as my mswindows VM doesn't have opengl

r20244 adds a "re-initialize windows" option in the system tray menu, so the fix is now tested and verified working.

Mon, 03 Sep 2018 10:18:17 GMT - Ben Jackson:

Thanks again! Going to grab the latest build and test that.

Tue, 25 Sep 2018 05:58:59 GMT - Antoine Martin: status changed; resolution set

Feel free to re-open if you still have problems.

Sat, 23 Jan 2021 05:36:34 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1892