X11 tunnel over ssh and then rsh

Roberto Nunnari roberto.nunnari at supsi.ch
Fri Aug 22 10:11:01 UTC 2008

Roberto Nunnari wrote:
> Hello Nikos.
> Thank you for your reply.
> See my comments below.
> Nikos Vassiliadis wrote:
>> On Thursday 21 August 2008 09:54:29 Roberto Nunnari wrote:
>>> Anybody on this, please?
>>> Roberto Nunnari wrote:
>>>> Hello list.
>>>> I have this scenario
>>>> 1) host A with X server
>>>> 2) host B with ssh server but without X server
>>>> 3) host C with rsh server and X client programs but without X server
>>>> (on host C there's also an ssh server, but in our case, users
>>>> have to use rsh)
>> Why rsh? Isn't ssh a drop-in replacement for rsh?
> The reason for using rsh instead of ssh is that
> it's a computing cluster. Host B is the master node
> and access point to the cluster, and host C is any
> one of the computing nodes. The cluster resources are
> managed by the Sun Grid Engine (SGE) and so users
> obtain the computing resources using the SGE interface.
> SGE under the cover uses rsh. I could search and see if it would
> possible to configure SGE so that it uses ssh instead of rsh,
> but then, you should take in accounting the cpu overhead of
> using ssh (encryption/decryption), so unnecessarily using cpu
> time, as the cluster is all in a private network.
>>>> now, I need to connect from host A to host B with:
>>>> A$ ssh -Y B (-Y or -X, to create a X tunnel)
>>>> and then from host B to host C with:
>>>> B$ rsh C
>>>> and on host C I need to run an X client like:
>>>> C$ xterm
>>>> Now, I would like the users not to have to set the
>>>> DISPLAY env var on host C, as they tend to forget
>>>> and also some user's X server don't accept plain
>>>> X connections..
>>>> Is there a way that I could configure host B to somehow
>>>> expose to host C the X tunnel to host A?
>> Automatically? No.
>> You can however use ssh to create generic TCP tunnels, using
>> -R and -L. But this is much more complicated than remembering
>> a DISPLAY variable.

Wait! I found a possible workaround.. it seams that setting
X11UseLocalhost = no
on sshd_config tell sshd to bind the X11 forwarding server
to the wildcard address..

> Right. Also, it requires users to specify a port on host B,
> and then the chosen port could already be taken, so returning
> an error..
> Too much hassle..
>>>> From host B I have access to the users' homes on host C and I could
>>>> place there some script to set the DISPLAY env var on user
>>>> login.
>>>> B$ echo $DISPLAY
>>>> on host B gives back something like localhost:16.0,
>>>> but if on host C I enter:
>>>> C$ export DISPLAY=B:16.0
>>>> C$ xterm
>>>> it doesn't work.. probably host C doesn't expose a
>>>> network socket but maybe a unix socket for the X tunnel..
>> This is probably because the listener (which proxies X11 to
>> host A) is bound to localhost( and not B(
>> You can overcome this, using manual forwarding(-R & -L).
>> HOST_A# ssh -R '*:6010:' HOST_B  # create a listener
>>     on HOST_B listening on all interfaces and TCP port 6010
>>     and tunnel everything from there to HOST_A's 6000
> This is a possible solution, but as stated above, it requires the
> user to specify the port number (6010 in the example above)..
> Also, it requires GatewayPorts = yes in sshd_config..
> Humm.. it's a pity that ssh -Y or -X will only listen on the
> loopback interface, but for sure there are good reasons it
> is done that way.
> Thank you again and best regards.
> Robi
>> Then every host which can connect to HOST_B can connect to HOST_A
>> X11 server. Using generic TCP port forwarding through ssh to forward
>> X11 has an other minus. You have to handle yourself the X11 
>> authorization(xauth, XAUTHORITY and friends)
>> You can of course use a second ssh session from HOST_B to HOST_C
>> to expose HOST_B's to HOST_C's
>> So, connecting from HOST_C to will be tunneled
>> to HOST_B's, which will be tunneled to HOST_A's
>> were your X11 display lives.
>> It's rather complicated, though...
>> _______________________________________________
>> freebsd-questions at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to 
>> "freebsd-questions-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe at freebsd.org"

More information about the freebsd-questions mailing list