X11 tunnel over ssh and then rsh

[Oliver Fromme]

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

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Python tricks" is a tough one, cuz the language is so clean. E.g.,
C makes an art of confusing pointers with arrays and strings, which
leads to lotsa neat pointer tricks; APL mistakes everything for an
array, leading to neat one-liners; and Perl confuses everything
period, making each line a joyous adventure <wink>.
        -- Tim Peters