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