X11 tunnel over ssh and then rsh

[Roberto Nunnari]

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(127.0.0.1) and not B(12.23.34.45).
>> You can overcome this, using manual forwarding(-R & -L).
>>
>> HOST_A# ssh -R '*:6010:127.0.0.1:6000' 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 127.0.0.1 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 127.0.0.1:6010 to HOST_C's 127.0.0.1:6010.
>> So, connecting from HOST_C to 127.0.0.1:6010 will be tunneled
>> to HOST_B's 127.0.0.1:6010, which will be tunneled to HOST_A's
>> 127.0.0.1:6000 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"