[Techtalk] ssh and X

Almut Behrens almut-behrens at gmx.net
Fri Feb 24 11:07:51 EST 2006


On Thu, Feb 23, 2006 at 11:07:57AM +0000, Caroline Johnston wrote:
> Hi chix,
> 
> I'm trying to connect to my work computer from home, which I would
> normally do by ssh -X ing to the ssh server that's accessible from outside
> and then ssh -X ing to my box. This time, when I connected there was a
> message from the sysadmin saying ssh tunnels weren't allowed. Any ideas
> how I should be accessing the display of my work box from home?

You should always be able to tunnel the X protocol (or anything else)
via the regular stdin/stdout that _any_ ssh connection provides.
As usual, there are several ways to do this; using netcat[1] would be
one of them.  IOW, instead of having ssh attach stdin/stdout to your
tty (i.e. by default sending stdout to the terminal and reading stdin
from your keyboard), you'd have the following setup:

                 local                        remote

                      stdin             stdin        
           socket      --->              --->              listening
  X server <---> netcat    ssh connection     netcat <---> socket for
                       <---              <---              X clients
                      stdout            stdout             to connect


Of course, this would mean that you can't use this dedicated ssh
connection for anything else.  To issue commands interactively on the
remote side, you'd have to open up a second (normal) connection...

The required command would look something like that

$ nc -e 'ssh remotehost nc -l -p 6015' localhost 6010

This runs a local netcat connecting to the X server's socket (port 6010),
which then executes the ssh command, making its stdin/stdout the just
created socket.  The ssh in turn executes another netcat on the remote
side, in listening mode (port 6015) -- this is where X clients connect.

The specific port numbers may vary, but as you probably know, X display
:0 corresponds to port 6000, :1 to 6001 etc., so you'll figure what to
put there... :)

Unfortunately, there are several issues with this:

* For one, you'd have to set up passphrase-less logins for your ssh
connection.  This is because you can't type anything, as stdin/stdout
are being used for something else.  Not a big issue, though (I suppose
you're familiar with how to do this).

* Next problem is that most modern distros are starting the X server
with option '-nolisten tcp', which means it won't any longer listen on
tcp port 6000+ -- as it has been doing for decades before (this is a
security feature). So, you'd either have to reconfigure this, or - if
you'd rather not touch this setting - simply run a 'ssh -X localhost'. 
In contrast to netcat, ssh can connect to the X server's local (unix
domain) socket, setting up a normal tcp socket on the other end, which
you can then use.  ssh will by default setup the display localhost:10
== port 6010, unless this port is already in use. [2]

* Yet another thing you now have to take care of yourself is the X
authentication.  Normally, ssh would do this for you, but as your
workplace's admin has decided to disable any tunneling... well, you
have to call xauth yourself.  Doing it manually would involve the
following two steps:

On the local side

$ xauth list $DISPLAY

The output will include something like
'MIT-MAGIC-COOKIE-1  d554bf86118cc5273c8060bb9e8f9197', which you'd
have to cut-n-paste onto the related command that you run on the remote
side

$ xauth add :15 <paste the cookie here>

Display :15 would be what you need, if you've specified -p 6015 for the
remote netcat, as shown above -- well, you get the idea.
Of course, there are also ways to automate this...

Also, don't forget to set your DISPLAY to :15 (on the remote side), so
X clients will know where you want them to connect...

* Finally, netcat (in listening mode) doesn't fork when accepting a
socket connection (as most other daemons would do). The net effect of
this is that the entire tunnel is shut down every time the X client
disconnects.  Depending on how your application is utilizing its X
connections, this can be a bit of a show stopper in this whole
scenario...[3]  I don't know of any nice and easy workaround for this 
(of course, there are things you can do, but they're all rather
involved...).

Normally, I'd be more verbose here, but at the moment I'm overloaded
with other things, so please excuse if this is not as elaborate as it
would be, if I had the time...

Good luck anyway,
Almut

[1] it's called either 'nc' or 'netcat', depending on your distro or
unix flavor.  In case it's not already installed on your system(s), you
can get the GNU implementation from  http://netcat.sourceforge.net/

[2] in case of doubt, verify with 'netstat -tan | grep :60..'

[3] this is particularly annoying, if you're forwarding HTTP, where
the connection is typically being closed after the page has been
served.  Even with HTTP-keepalive on, the connection is usually being
dropped after a while...


More information about the Techtalk mailing list