Thanks Armin. I am doing it with with an ssh config file that sets the X11 forwarding via a config file entry The fact that the display is correctly set as I ssh though the two machines tells us that the X11 is forwarded - I am not sure why the xterm does not pop up. Calin Armin Schöch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
PRODUCT: SuSE Linux (I386) 9.0 I have a problem opening an Xterm window on my Suse linux machine (SL) after I ssh (with X11 forwarding) to a remote machine (RM).
One other important issue: to reach to my remote machine I ssh twice:
1. Suse Linux to remote account management machine (RAM). 2. RAM to RM ( where I finally want the xterm to run)
- --> Have you tried to enable X11 forwarding explicitely with the "-X" option?
SL: ssh -X user@RAM RAM: ssh -X user@RM
I'm doing the same thing as you do and I can confirm that this setup is working with a SuSE system.
Good luck! Armin
- -- Am Hasenberg 26 office: Institut für Atmosphärenphysik D-18209 Bad Doberan Schloss-Straße 6 Tel. ++49-(0)38203/42137 D-18225 Kühlungsborn / GERMANY Email: schoech@iap-kborn.de Tel. +49-(0)38293-68-102 WWW: http://armins.cjb.net/ Fax. +49-(0)38293-68-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org
iD8DBQFAk07JG8Xv4GxznLoRApvUAJ9BzXZ65sfm5cJsXfIaNT/JaUdqPACggzux jtI6JsxdC0Iq+lNSYnKg87A= =CprR -----END PGP SIGNATURE-----
-----Original Message-----
From: Calin Duma
Thanks Armin. I am doing it with with an ssh config file that sets the X11 forwarding via a config file entry
The fact that the display is correctly set as I ssh though the two machines tells us that the X11 is forwarded - I am not sure why the xterm does not pop up.
Calin
Because you also need to allow remote "x" programs to display on your screen. This can be done with xhost + and then xhost - after you are through. Ken
Ken Schneider wrote:
-----Original Message----- From: Calin Duma
To: armins@gmx.net, suse-security@suse.com Date: Sat, 01 May 2004 11:31:37 -0400 Subject: Re: [suse-security] ssh and X11 help Thanks Armin. I am doing it with with an ssh config file that sets the X11 forwarding via a config file entry
The fact that the display is correctly set as I ssh though the two machines tells us that the X11 is forwarded - I am not sure why the xterm does not pop up.
Calin
Because you also need to allow remote "x" programs to display on your screen. This can be done with xhost + and then xhost - after you are through.
Ken, This is really bad advice, especially in a security list. The xhost command is for allowing remote systems access to your display. If you must use it, at the very least specify the host for which you are granting access: "xhost + IP_ADDRESS". An even better way to do this is with xauth, but it is a bit more complicated. Where xhost is system based, xauth is session based. The ssh X forwarding facility should work regardless of xhost. It uses xauth with magic-cookies. I would check to make sure xauth is in your path on both machines. If there are both stock SuSE installs, things should just work, although you might need to specify the -X option. I have has issues when connecting to various Solaris boxes.
Brandon Hines wrote:
Ken Schneider wrote:
-----Original Message----- From: Calin Duma
To: armins@gmx.net, suse-security@suse.com Date: Sat, 01 May 2004 11:31:37 -0400 Subject: Re: [suse-security] ssh and X11 help Thanks Armin. I am doing it with with an ssh config file that sets the X11 forwarding via a config file entry
The fact that the display is correctly set as I ssh though the two machines tells us that the X11 is forwarded - I am not sure why the xterm does not pop up.
Calin
Because you also need to allow remote "x" programs to display on your screen. This can be done with xhost + and then xhost - after you are through.
I tried the xhost+ for now and I have the same behavior. But I wouldn't want to leave it wide open any way - that is a high security risk.
Ken,
This is really bad advice, especially in a security list.
The xhost command is for allowing remote systems access to your display. If you must use it, at the very least specify the host for which you are granting access: "xhost + IP_ADDRESS". An even better way to do this is with xauth, but it is a bit more complicated. Where xhost is system based, xauth is session based.
The ssh X forwarding facility should work regardless of xhost. It uses xauth with magic-cookies. I would check to make sure xauth is in your path on both machines. If there are both stock SuSE installs, things should just work, although you might need to specify the -X option. I have has issues when connecting to various Solaris boxes.
The machine I am connecting to is a Solaris 5.8.box. The important part in the initial message that I posted is that I tried using a putty build on Suse and had the same problem. Using the same putty version on Windows with Exceed as the X server I was able to do it. That makes me believe that Brandon has the right ideea. I checked both machines (local and remote) and xauth is in the path - but I am pretty sure that the problem is with the Xauthority. What else should I look for ? Below is the message I am getting when I ssh to the remote machine. After the last line I am stuck until the connection times out: debug2: x11_get_proto /usr/openwin/bin/xauth list gatekeeper:15.0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: x11-req debug1: channel request 0: shell debug1: fd 3 setting TCP_NODELAY debug2: callback done debug1: channel 0: open confirm rwindow 10000 rmax 16384 No match Erase is Backspace Kill is Ctrl-K shaman{cduma}1: xterm debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from <ipaddresshere> 54755 debug2: fd 7 setting TCP_NODELAY debug2: fd 7 setting O_NONBLOCK debug2: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: client_input_channel_open: ctype x11 rchan 1 win 30000 max 1024 debug1: client_request_x11: request from 155.157.121.230 47588 debug1: fd 7 setting TCP_NODELAY debug1: fd 7 setting O_NONBLOCK debug2: fd 7 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 *** The two messages below appear because I resized the current windown on my suse machine. debug2: client_check_window_change: changed debug2: channel 0: request window-change
participants (3)
-
Brandon Hines
-
Calin Duma
-
Ken Schneider