Remote X using ssh on FC2

stevewillis · 11-15-2004, 03:18 PM

Hello,

I have two computers, both running Fedora Core 2. I will call these computers 'local' and 'remote'. My desktop computer is local, which runs the X server. A headless file server is remote.

I want to run a few graphical applications on remote, and display their GUI on local. I want to avoid xhost and the X protocol, and use the ssh tunneling method discussed in several other posts on this forum. I've had no luck getting this working. Here are the steps I have taken:

I edited /etc/ssh/sshd_config on remote to include the following, and restarted sshd:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

I edited /etc/ssh/ssh_config on local to include the following:

ForwardAgent yes
ForwardX11 yes

I ssh to an account on remote like this:

ssh -X some_user@remote

It appears that the DISPLAY variable is not being set by ssh. Trying to start a graphical program on remote results in:

Gtk-WARNING **: cannot open display:

And this command on remote results in a blank line:

echo $DISPLAY

Any thoughts on how I can get this working?

Thanks!

Steve

secesh · 11-15-2004, 03:29 PM

i've never done it that way... this is how i pass X apps...

1) startx on client
2) pull terminal up, and run: xhost <ip>
where <ip> is the ip of the PC you will be connecting to
3) get a terminal on the remote host -- through ssh or otherwise
4) run: startx -display <ip>:0.0
where <ip> is the PC you are trying to redirect X to

...and a quick search got me this link with a little more:
http://cosi.clarkson.edu/knowledge/faq/xforwarding.html

--the above will send an x-terminal to the desired display, from which x-applications can be launched [locally].

stevewillis · 11-15-2004, 03:35 PM

Thanks for your reply, but please note that I am trying to avoid the old, less-secure xhost method of using a remote display. Many people on these forums seem to be recommending using ssh as a secure way to share a graphical application. I'd like to get that working, if possible.

Thanks again!

Steve

laminar1 · 11-15-2004, 08:35 PM

Try changing the X11UseLocalhost to 'no'. Then restart sshd on remote and try to run xclock or something from local as a test. For Debian that's

Code:

/etc/init.d/ssh restart

BTW, here's the def of that function from man sshd_config. (There's also man ssh_config--both are very useful.)

X11UseLocalhost
Specifies whether sshd should bind the X11 forwarding server to the loopback address or to
the wildcard address. By default, sshd binds the forwarding server to the loopback address
and sets the hostname part of the DISPLAY environment variable to ``localhost''. [snip]

Good luck.

stevewillis · 11-15-2004, 11:23 PM

Thanks for the advice! Unfortunately, it appears that sshd is still not setting the DISPLAY variable on remote. Any other thoughts on what might be wrong?

Steve

secesh · 11-16-2004, 08:25 AM

if you've got the server right, and it has been reloaded...

and you are in fact using the -X option,

i've toyed with this since my previous post, and my only other advice is to inspect any scripts which might run at logon (both system and user scripts) and see that they are NOT overwriting the display variable...

though i've only started looking into this, my understanding is that $DISPLAY should never been overwritten by the user (or system) when attempting to get ssh to x-forward, because the consensus is that this is dark magic performed by ssh to setup stuff properly...

(though basic testing here has resulted with display variables including 'localhost' -- which worked locally, but not remotely!)

i also saw mention to using the -vvv option when running ssh to try and get some debug info, though this did not (from what i saw) return anything useful for this problem.

so, ummm... good luck...

stevewillis · 11-16-2004, 12:43 PM

Aha! secesh, Thank you for the suggestion to use the -vvv flags for extra verbosity (how silly of me not to try that first...I was looking for some sort of log file.) The problem was that remote is a headless box that I did a minimal install on. The extra verbose output indicated that was no xauth program on remote, which I corrected with this:

Code:

yum -y install xorg-x11-xauth

Sadly, it's still not quite working. Now the DISPLAY variable is being set correctly. However, when I try to start a graphical application on remote, I get this error:

Code:

X11 connection rejected because of wrong authentication.
The application 'xclock' lost its connection to the display REMOTE:10.0;
most likely the X server was shut down or you killed/destroyed
the application.

Note that is says it lost its connection to REMOTE, and not LOCAL, which seems odd to me. I though ssh was supposed to set the DISPLAY to LOCAL, the machine I am ssh'ing from that is actually running an X server.

Here is the extra-verbose output:

Code:

debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 1036
debug1: fd 7 setting O_NONBLOCK
debug2: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug1: X11 rejected 1 i0/o0
debug1: channel 1: read failed
debug1: channel 1: close_read
debug1: channel 1: input open -> drain
debug1: channel 1: ibuf empty
debug1: channel 1: send eof
debug1: channel 1: input drain -> closed
debug1: channel 1: write failed
debug1: channel 1: close_write
debug1: channel 1: output open -> closed
debug1: X11 closed 1 i3/o3
debug1: channel 1: send close
debug1: channel 1: rcvd close
debug1: channel 1: is dead
debug1: channel 1: garbage collecting
debug1: channel_free: channel 1: x11, nchannels 2
debug3: channel_free: status: The following connections are open:\015
                                                                       #0 client-session (t4 r0 i0/0 o0/0 fd 4/5)\015
                                       #1 x11 (t7 r3 i3/0 o3/0 fd 7/7)\015
                                                                           
debug3: channel_close_fds: channel 1: r 7 w 7 e -1
The application 'xclock' lost its connection to the display REMOTE:11.0;
most likely the X server was shut down or you killed/destroyed
the application.

Any thoughts? Thanks!

Steve

secesh · 11-16-2004, 02:00 PM

you got me, boss... i just started with x/ssh forwarding...

it's going to be a couple days before i can trace this...

laminar1 · 11-16-2004, 03:15 PM

In addition to xauth, try using rsa keys to get proper authorization. Check man ssh-keygen for a synopsis. There are also many howtos on key authentication out there.

Basically, run the keygen on both machines, and copy [using cat] the public key to the correct file on each machine. Then make sure ssh_config AND sshd_config have 'PubkeyAuthentication yes'.

For better security, set 'Protocol 2' (not the default 2,1) in both config files. In sshd_config, change PermitRootLogin to 'no'. These changes will not affect your current issue one way or the other.

stevewillis · 11-16-2004, 05:07 PM

Thanks for the suggestion. I was, in fact, already using rsa keys. I didn't mention it, because it is definitely not related to my problem--I created a virgin test account on both machines and tried this both with and without rsa keys. It made no difference.

I should also mention that I wouldn't consider myself a newbie...I've been using Linux since Redhat 5, and ususally have no problem figuring this sort of thing out. I've been stumped on this one for a few days, though, and am hoping that someone with more experience with this particular issue will have some insight. Specifically, I'd be interested to know if anyone else using Fedora Core 2 has successfully used ssh for a remote X session. I know the Fedora project recently moved to X.org for the X server, and wonder if there is more to do to set this up on Fedora than other distros. Also, I noticed that I had to edit my gdm config file to turn tcp listening on to get remote X to work the old fashioned way (with xhost). I'd really like to learn how to do it with ssh, though. The ease of firewall configuration for an ssh tunnel really appeals to me over letting the insecure X protocol run with another dedicated open port.

Thanks for all the great tips. Please, keep 'em coming!

Steve

laminar1 · 11-17-2004, 06:57 AM

Well, you are making some progress. Climbing the error tree, as I say.

Check your X server to make sure it's listening for remote session requests. By default in Debian, for instance, X is set to nolisten. Not sure about FC2. I dug this up for you:

Notice that some X servers (from XFree86) can be configured not to listen on the usual TCP port with the -nolisten tcp argument. Notably the default configuration of Debian GNU/Linux is to disable the X server listening on the TCP port. If you wish to use remote X on a Debian system, you should re-enable this by altering the way the X server is started. Look at /etc/X11/xinit/xserverrc for a start.

Here's a good link: www.faqs.org/docs/Linux-mini/Remote-X-Apps.html

Check your documentation for the X.org-specific setup.

stevewillis · 11-17-2004, 10:31 AM

* * *

NOTE TO ALL: I really appreciate everyone's help. Just so I don't waste anyone's time, please note that (1) I can already use the regular method for remote X applications via xhost, and that works just fine for me, and (2) I am trying to set up remote X applications using the ssh method as an alternative to having the X server listen to its own tcp port. I do not require general advice on remote X applications, but specific help on the errors I am seeing with my ssh setup.

Sorry for any confusion!

* * *

laminar1,

Thanks for the reply and the link! I have read that mini-howto in the past. In fact, remote X applications work just fine for me using the method described in that document, which is the older method of using X's own protocol and the xhost program to accept incoming connections. This is how I have done things for many years.

Section 6.3 of the document you linked to gives a very brief and incomplete overview of what I am trying to accomplish now. Instead of having X listen for inbound tcp connections (insecure and complicated), I want to tunnel the X application's display through ssh, which will present it to X as though it were any other local application. I see that there are many recommendataions for the ssh method, and these are the benefits I see:

(1) Increased security - all X traffic is encrypted, and as far as I can tell, as secure as using ssh for text interaction (anyone have any information to the contrary?) This seems to be why people are recommending the ssh method on the forums.

(2) Easier network setup - right now, I have to keep a port open in any firewalls for the tcp port X uses to listen for connections to a display. Same for setting up NAT on this port. It would be nice to only worry about setting up ssh, and having remote X applications work magically!

(3) Easier application setup - this is a big one for me. Right now, to launch the remote X applications I use, I have a complicated bash script that ensures that host is added to the .Xauthority file (via xhost), connects to the remote machine (via ssh), sets its DISPLAY variable to my local host name, and starts the app. It sure would be nice to just call ssh with a single argument to start an application from the command line! Add passwordless rsa keys, and I could even create launchers on my Gnome desktop to start a remote app with a double-click. Neat!

Anyway, my progress is this: thanks to the help from secesh yesterday, I can now use ssh to log in to the remote server and see that the DISPLAY variable is being set on the remote side. That variable points to REMOTE itself, and is presumably that end of the ssh pipe (can anyone confirm this is correct?) It is my understanding that I do not need an actual X server running on the remote computer, and in fact X is not installed (does anyone understand this differently?) When I try to start a graphical application, I get the authentication error I detailed in my earlier message. Other people don't seem to have this problem, so I am wondering if there is quirkyness with my distro. (Fedora Core 2), or if I am missing something obvious to someone else who has set this up, or if I misunderstand how this is supposed to work in the first place!

Again, thanks for taking the time to reply. Any other thoughts are appreciated.

Steve

laminar1 · 11-17-2004, 09:30 PM

You're not running X on remote? Yikes, now you are terra incognito.

Your explanation of what you are trying to do was helpful.
My (limited) understanding, however, is that the X server on remote has the job of display output either to the local display or to a remote one. I don't think userland apps can forward their X-bound output to a remote machine independent of a local X server. Maybe someone can correct me.

Fortunately, it's easy to test: install X on remote and make sure it's listening for remote sessions, and then see if your remote X session then works over ssh. I realize that remote is a headless server, so you probably don't have a monitor on it. It might be a hassle, but consider it your solemn duty for the betterment of ...let me think...

stevewillis · 11-17-2004, 10:31 PM

laminar1,

Thanks for the tip. I'll try installing X on the remote server and let you know how it goes. I hope that X is not required on the remote server, as this is only one of a number of servers I'd like to use this way that are headless (no monitor) and do not have X installed.

I can say for sure that the xhost (non-ssh) method works fine without X installed on the remote server...it is working right now! Usually, you will need some of the X libraries installed on the remote server to satisfy dependencies for compiling graphical applicat ions, or for installing them from RPMs. I've never needed an actual X server running on the remote system before, though. The whole point of setting the remote DISPLAY variable to a local display is that it bypasses the remote X server.

I'll be out of town tomorrow (Thursday), but I'll try installing X and post my results on Friday. I sure hope it is something as stupid (on my part) as not having some package installed!

Thanks again!

Steve

laminar1 · 11-17-2004, 10:48 PM

I thought of another idea, maybe easier than installing X on remote:
Get a copy of Knoppix and boot REMOTE from the live CD. Knoppix runs X by default as you probably know. You will have to modify the ssh_config and sshd_config files and restart the ssh daemon in the usual Debian way. (The modified config files are stored in ramdisk). Then login from LOCAL via ssh and see if you can get an X app to work. This has worked for me in the past.