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".
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:
%PATH%
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
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)
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.
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)
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.
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?
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.
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)
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.
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
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.
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.
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)
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).
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
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
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.
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
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
.
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)
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
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
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.
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!
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).
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.
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.
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?
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\
.
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
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 ?
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.
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)
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:
cd Program Files cd Xpra set XPRA_SSH_DEBUG=1 set XPRA_LAUNCHER_DEBUG=1 Xpra-Launcher-Debug.exe
(and post the output - beware: it may log authentication details, ie: passwords)
I am aware of the tray icon issue, will fix tomorrow.
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)
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)
Just tried the latest beta. Worked great.
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
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)
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.
Thanks again! Going to grab the latest build and test that.
Feel free to re-open if you still have problems.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1892