X11 tunnel over ssh and then rsh

[Roberto Nunnari]

Hi Oliver.

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.

Thanks for the suggestion. I'll try that right away.

Robi


Oliver Fromme wrote:
> Roberto Nunnari wrote:
>  > 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)
>  > 
>  > 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? 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..
> 
> There are several problems.  First, rsh does not support
> connection forwarding.  Second, for security reasons, the
> X forwarding feature of ssh binds only to localhost on
> the client side (B), so you can't use it from C.
> 
> The easiest solution would be to allow users to use ssh
> to connect to C (what's the reason for not allowing it?).
> Then you can use the X forwarding feature of ssh.
> 
> Other solutions require much more work.  For example, you
> can use ssh's generic connection forwarding feature which
> allows using a remote network socket (not just localhost).
> That is, on host A type something like this:
> 
> ssh -R 6001:localhost:6000 B
> 
> then on host B simply type "rsh C", and on host C you
> have to set the DISPLAY environment variable to "B:1.0".
> You also have to use xauth(1) or xhost(1) to allow X
> clients to access the server (ssh's X forwarding feature
> does that automatically, but when using the generic
> connection forwarding you have to do it yourself).
> 
> WARNING:  The X connection between hosts B and C will
> be unencrypted.  Everybody who has access to the network
> will be able to sniff the connection and be able to
> watch everything you do, including every character you
> type (passwords etc.), and even intercept, modify and
> take over the connection.  Furthermore, since the X
> connection socket on host B listens on the network
> (not just localhost), everybody can connect to it from
> other machines and access your X server, provided it
> can authenticate with it (which is trivial, especially
> if you use xhost(1)).
> 
> I'm curious, why can't you use ssh between hosts B and C?
> Using ssh would solve all of the problems at once.
> 
> Best regards
>    Oliver
> 


-- 
Roberto Nunnari
Servizi Informatici SUPSI-DTI
SUPSI-DTI - Via Cantonale - 6928 Manno - Switzerland
email: mailto:roberto.nunnari at supsi.ch
tel: +41-58-6666561