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.

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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to