I have a remote box paddy, I access via OpenVPN (See below for info about boxes and network)
xpra via ssh from home box shuttle to remote box paddy times out after upgrading shuttle to Fedora 19.
start on remote box paddy:
[zebee@paddy ~]$ xpra start -d all :102 --start-child emacs
(debug log attached)
attach on paddy with
[zebee@paddy ~]$ xpra attach :102
and the emacs window shows up as expected.
detach by control-c.
go to home box shuttle.
do
[zebee@shuttle ~]$ xpra attach ssh:paddy:102
and it times out.
2014-03-20 16:46:23,818 ':0.0' 1920x1080 (508x285 mm) workarea: 1920x1045 at 0x0 2014-03-20 16:46:23,818 'HDMI2' 1920x1080 at 0x0 (575x323 mm) 2014-03-20 16:46:43,827 connection timed out 2014-03-20 16:46:43,928 Connection lost [zebee@shuttle ~]$
(script file of doing that attach with -d all attached)
Note that if I haven't run xpra on shuttle for a while, then ssh to paddy is quick, no hangs no waits.
But if I do run xpra then ssh will pause for some time at
debug1: sending SSH2_MSG_KEX_ECDH_INIT
before continuing with
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA 17:12:73:c2:b7:d6:78:cf:b3:63:79:ff:f7:df:3d:37
this behaviour of ssh is reliable and repeatable: connect without pause until I run xpra, then it hangs at the host key exchange and will keep hanging for some time. (Exact time not sure of yet, haven't done enough testing)
ssh to paddy from another box on the home network is not affected.
xpra has not done a successful connection since I upgraded to Fedora 19 last month. Was OK before that.
============
network:
shuttle: Fedora 19 using xpra-0.11.6-1.fc19.x86_64
vpin: Raspberry PI running a OpenVPN to paddy where vpin's VPN IP is 172.16.121.1, connects via 172.16.121.2 as the gateway, and sees paddy as 172.16.121.9
paddy: Fedora 19 using xpra-0.11.6-1.fc19.x86_64
both paddy and shuttle are using KDE as a window manager.
log of xpra start -d all :102 on paddy
result of xpra attach -d all ssh:paddy:102 (via script command)
shuttle was the box upgraded from F18 to F19. Paddy has always been F19.
and it times out
Please post the slow connection output with:
xpra attach --ssh="ssh -v" ...
To get the same level of debug information as you posted for plain ssh.
But if I do run xpra then ssh will pause for some time at...
This could also be related to connection sharing, see #203 and #380.
If so, see ssh options: ControlPath
, ControlMaster
and ControlPersist
. Try turning off connection sharing explicitly and see if that helps.
here's the script output for using ssh -v.
note that I got it wrong in the original, the hang in ssh is at
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
rather than before that.
I've marked the hang in the attached script output for -v.
I set .ssh/config
to:
ForwardAgent yes ForwardX11 yes ControlMaster no ControlPath none ControlPersist n
but no change in behaviour. ssh OK till run xpra and then ssh hanging.
xpra attach --shh="ssh -v" ssh:paddy:102
Please see: Why is SSHD hanging at “Server accepts key”.
Changing the KexAlgorithms
may well solve your problems, especially if a vastly underpowered raspberry-pi is involved. Some of the key exchange algorithms are CPU intensive. Though this could only affect other ssh sessions if the Control*****
options are active.
I thought of reverse DNS but as this hang only happens when xpra is involved and clears up later, I can't see that's it. (I added everything to host files just in case...)
figured the last one listed in the defaults was the least expensive so set
KexAlgorithms diffie-hellman-group1-sha1
using -v in the attach command and it sailed through the key exchange bit.
but it still times out!
debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/zebee/.ssh/id_np_rsa 2014-03-20 18:02:17,708 root size is 1920x1080 with 1 screen(s): 2014-03-20 18:02:17,708 ':0.0' 1920x1080 (508x285 mm) workarea: 1920x1045 at 0x0 2014-03-20 18:02:17,708 'HDMI2' 1920x1080 at 0x0 (575x323 mm) debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: Authentication succeeded (publickey). Authenticated to paddy ([172.16.21.9]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Requesting authentication agent forwarding. debug1: Sending environment. debug1: Sending env XMODIFIERS = @im=none debug1: Sending env LANG = en_US.UTF-8 debug1: Sending env LANGUAGE = debug1: Sending command: .xpra/run-xpra _proxy :102 2014-03-20 18:02:27,957 server requested disconnect: login timeout 2014-03-20 18:02:28,058 Connection lost [zebee@shuttle ~]$ debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1
and then after that attach command timed out, I tried a straight ssh to see if that was going to hang... and it did.
but the time between "ssh will pause at key exchange" and "ssh goes through OK" seems to have got a lot shorter.
however... I am wondering if xpra is just the victim of being something I want to run. Because I had a couple of quick ssh trips to paddy, then it hung again, and I had not run xpra in the interim. (This is the first time I have noticed it happening when xpra was not in the mix)
So it is quite possible that there is a problem with the path it is taking and something is in the way, possibly in the Pi.
And this something is intermittent. More investigation needed.
I see:
server requested disconnect: login timeout
This can only happen if it takes more than 10 seconds to get the first packet after the ssh connection is established - which really ought to be enough.
You can increase this default by running the server with:
XPRA_SOCKET_TIMEOUT=60 xpra start ...
But a connection that can take this long to get a packet through is unlikely to give you a good experience..
In the log samples above, you also have some gssapi errors, unless you do use it, try setting:
GSSAPIAuthentication no
In your sshd_config
as the mac on the same network isn't affected it was clearly shuttle's problem.
I have been experimenting but results are inconsistent. For a while I thought it was that the xpra/ssh process did not die after timeout, and when I killed it, then my ssh stopped pausing.
But a couple of times that process was present and ssh was OK.
And right now that process isn't present and ssh is bad.
I've got a script running that does a check every 5 min to see what it does overnight.
Should the xpra/ssh process die after the timeout?
zebee 19244 1 0 19:52 ? 00:00:00 ssh -v -T paddy .xpra/run-xpra _proxy :102
I havent timed how long it takes to disappear but it seems to be a fair old while after it's transferred to pid 1.
From what you're saying, I really do think that this is not an xpra issue.
Also, if it was, someone would have reported it by now.
Unless something major shows up, I will close this ticket a invalid
.
Should the xpra/ssh process die after the timeout? (..) it seems to be a fair old while after it's transferred to pid 1
The ssh process used to stay alive after xpra terminated if it was used for connection sharing.
That's no longer the case by default as of r5862 (soon to be released v0.12), see ticket:203#comment:9
As stated above, this is very very unlikely to be a bug in xpra.
Closing as invalid, feel free to reopen if not.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/542