Control: tag -1 confirmed
Control: reassign -1 x2goserver
Control: retitle -1 x2gomountdirs/sshfs hangs indefinitely if
client-side sshd is down
Hi,
I have spent the last 1.5 days with hunting down the cause for #405.
The phenomenon is:
o client-side is Linux (or maybe Mac OS X) o sshd ist not running on the client machine o the session profile has printing or client-side folder sharing enabled
If X2Go Client launches a remote session it does the following things:
o set up a reverse port forwarding tunnel that allows <server-side-localhost>:<fsPort> -> <client-side-localhost>:<sshd-Port> o if sshd is not running, the above will still work... o then x2gomountdirs is evoked... o ... which attempts to run sshfs against <server-side-localhost>:<fsPort> o however, in X2Go Client this triggers an I/O error because the client-side sshd is not listening / not running
I studied the X2Go Client code (sshmasterconnection.cpp and
sshprocess.cpp) very deeply and added several new debug messages +
improved the debugging output of existing messages.
In X2Go Client, the mounting of a client-side folder uses two SSH
channel inside this reverse port forwarding tunnel:
o one SSH channel for the tunnel itself o one SSH channel per x2gomountdirs command call evoked on the server
Furthermore, X2Go Client can detect if failures occur in x2gomountdirs
this way:
o something strange happens while executing the command (SSH
disconnects etc.)
o the stdOut of the evoked command (x2gomountdirs) is empty while
stdErr is not
So, (and I did not know this), all X2Go Server side commands
(/usr/bin/x2go*) should properly write to stderr if things go wrong
and leave stdOut untouched at the same time.
The problem now is: if x2gomountdirs is not detected as "failing"
(which it is not), the sshfs pubkey required for client-side folder
sharing is not removed from the .ssh/authorized_keys file.
Furthermore, X2Go Client detects the I/O errors on the sshfs tunnel
channel, but cannot relate to that to the x2gomountdirs command evoked
via the SSH command channel.
My first attempts targetted getting X2Go Client to tidy up the
authorized_keys file whenever a tunnel failure occurs. X2Go Client
should be able to detect this, but this would require a partial
redesign of the complete reverse port forwarding mechanism. I
disrecommend doing this for the current X2Go Client implementation,
but we should keep it in the back of our heads for a later redesign.
It took about 8h to come to this conclusion.
My second approach (and I will commit soon is this):
o evoke sshfs command with "timeout 30 sshfs <options>"
o print error messages to STDERR (not to STDOUT)
o and make sure we unregister the mount point if sshfs fails (with
fusermount -u)
Wit this approach, X2Go Client tries to call x2gomountdirs,
x2gomountdirs fails after 30 seconds with error messages printed to
STDERR. This gets caught by X2Go Client and then the
post-startX2goMount code is triggered which removes the used pubkey
from ~/.ssh/authorized_keys.
Commit will come in a minute...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...