xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 6 years ago

#542 closed defect (invalid)

xpra attach ssh times out and causes ssh key exchange to pause or time out

Reported by: Zebee Owned by: Zebee
Priority: major Milestone: 0.12
Component: client Version: 0.11.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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.

Attachments (3)

paddy:102.log (58.5 KB) - added by Zebee 6 years ago.
log of xpra start -d all :102 on paddy
shuttle.xpra (79.6 KB) - added by Zebee 6 years ago.
result of xpra attach -d all ssh:paddy:102 (via script command)
shuttle.xpra.verbose (4.3 KB) - added by Zebee 6 years ago.
xpra attach --shh="ssh -v" ssh:paddy:102

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by Zebee

Attachment: paddy:102.log added

log of xpra start -d all :102 on paddy

Changed 6 years ago by Zebee

Attachment: shuttle.xpra added

result of xpra attach -d all ssh:paddy:102 (via script command)

comment:1 Changed 6 years ago by Zebee

shuttle was the box upgraded from F18 to F19. Paddy has always been F19.

comment:2 Changed 6 years ago by Antoine Martin

Component: coreclient
Description: modified (diff)
Milestone: 0.12
Owner: changed from Antoine Martin to Zebee
Version: v0.11.x

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 6 years ago by Zebee

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

Changed 6 years ago by Zebee

Attachment: shuttle.xpra.verbose added

xpra attach --shh="ssh -v" ssh:paddy:102

comment:4 Changed 6 years ago by Antoine Martin

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.

comment:5 Changed 6 years ago by Zebee

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 6 years ago by Antoine Martin

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

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:7 Changed 6 years ago by Zebee

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:8 Changed 6 years ago by Antoine Martin

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

comment:9 Changed 6 years ago by Antoine Martin

Resolution: invalid
Status: newclosed

As stated above, this is very very unlikely to be a bug in xpra.

Closing as invalid, feel free to reopen if not.

Note: See TracTickets for help on using tickets.