Date: Thu, 21 Aug 2008 10:20:25 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-questions@FreeBSD.ORG, roberto.nunnari@supsi.ch Subject: Re: X11 tunnel over ssh and then rsh Message-ID: <200808210820.m7L8KP4Z087373@lurza.secnetix.de> In-Reply-To: <48AADA2A.10803@supsi.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808210820.m7L8KP4Z087373>