Re: X11 tunnel over ssh and then rsh
Roberto Nunnari wrote: > 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.. You will still have to forward the X11 authentication to the client machine with xauth(1) or xhost(1), I think. Using xhost(1) is much easier, but it's insecure. On the other hand you're using rsh and a public network socket to connect to, so everything you do is insecure anyway. I hope you're going to make your users aware of that. 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 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11 tunnel over ssh and then rsh
On Friday 22 August 2008 13:10:29 Roberto Nunnari wrote: > >> 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.. Aha that seems to do the job. Oddly enough OpenSSH supports selffootshooting :) Didn't expect it to... Cheers, Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11 tunnel over ssh and then rsh
On Friday 22 August 2008 12:58:24 Roberto Nunnari wrote: > 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. I guess -X achieves a particular goal, that is being able to login to a remote box, run X11 apps and make them use your local X11 display. Everything else is beyond its scope... You can however use your favorite NAT to translate requests for, let's say: 192.168.0.1:6000 to 127.0.0.1:6000 and have the 127.0.0.1 bound socket exposed to the network... Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11 tunnel over ssh and then rsh
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@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]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11 tunnel over ssh and then rsh
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]"
Re: X11 tunnel over ssh and then rsh
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:[EMAIL PROTECTED] tel: +41-58-561 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11 tunnel over ssh and then rsh
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? > > > > 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. > > 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 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]"
Re: X11 tunnel over ssh and then rsh
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 . -- Tim Peters ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11 tunnel over ssh and then rsh
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) 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.. Any help/hint greatly appreciated. Best regards. Robi ___ 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]"
X11 tunnel over ssh and then rsh
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) 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.. Any help/hint greatly appreciated. Best regards. Robi ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
