I see what you have done:
1. xhost
2. edited /etc/ssh/sshd_config edited /etc/ssh/ssh_config
3. $DISPLAY
However, You still have to do what follows.
4. gdmsetup(execute it under root)->security option-> uncheck "Always disallow tcp connection..."
5. system tools(or settings?)->security level->trusted device->check "eth0(your net device)"

Good Luck!!!

Sorry I've been away so long. Things have been crazy the last couple of weeks!

coldautumn: Thanks for the tip. However, I already have my system set up this way (I double checked using your instructions, just in case.) Remote X applications are working for me using a TCP connection to the local X server. I want this to work over ssh, though. It seems to me that one should not have to set up Gnome to accept incoming TCP connections, or make a device "trusted" for the firewall, because the ssh method is supposed to tunnel the connection to a local X connection. In other words, I don't think Gnome should even know that a remote X connection has been made, because the local ssh process will make it look like a local X connection.

I think I've convinced myself that tunneling X over an ssh connection is not a possibility with Fedora. I've seen many others ask this question on the net, but haven't seen any answers.

Thanks all for you help!

Steve

Actually, tunneling X over SSH is very possible. If I can get it working, anyone can.

I actually think this is the root of the problem. My understanding is that X forwarding through SSH absolutely requires that X be running on the remote. The local screen is just providing the window managment, it is the remote that is actually doing the X work. Think of it like a web server and a web browser. All the browser is doing is displaying the HTML. It is the web server that is determining which HTML should be displayed.

I think you are confusing two things here, X and Gnome. You don't need Gnome, or any other X environment, to be running or configured, but you do have to have the X server running. In my case I changed the /etc/inittab file on my server so that the computer boots to runlevel 4, which starts X (I think most distros besides Slackware use runlevel 5 for this). I don't have any window managers or desktops environments running, in fact I'm not even logged into the machine (As an aside, if anyone knows how to start X and still be able to boot to runlevel 3, I'd be very interested in knowing how). Then I set up an ssh session using the -X flag. With this setup, I can run X apps either on my Linux laptop or from a Windows computer running Cygwin.


<edit>
As a complete off topic remark, does anyone have any idea why this thread is in Wireless? Its probably no big deal, but we may get some better answers if this were in Networking or Linux-General.
</edit>

OK, I've been doing a bit more reading and it turns out a lot of my previous post is hooey. The headless server does NOT have to have X running, but it does to need to have X installed. Apparently some X libraries are needed on the remote for this to work.

So what I do is fire up aterm, enter the command export DISPLAY=localhost:0.0 and then ssh to the remote using the -X flag (ssh -X hangdog@192.168.1.50).

On the remote, this is the relevant section of my sshd_config file:


What I'm finding is that X application performance is, well, funky. Simple ones like xclock work fine. Something more complex like rox doesn't work at all on my Slackware laptop but does on Cygwin under Windows. Endeavour2 runs, but crashes at the drop of a hat. Open Office seems reasonably happy.

Dear.
Well, I am sorry I didn't help.

Actually, I was faced with the same problem in FC3. After I did what I suggested you, I successcully solved it. And now I am working in FC3 (in my laptop) and can open Xwindows(such as xterm, ggv, gs, and so on) through ssh that connects my remote host. I don't know why it doesnot work on your system FC2.

In my PC, I use freebsd, and I also encountered the same problem. I edited the file "startx", and plus a # before "listen_tcp="-nolisten tcp", and it works very well now. So I think the 4th point is very important. But in my FC3, only after I figured out the 5th point, things can go well. So maybe you can check again.If it still not work, since I believe that the problem is caused by firewall and connection protocol, just make sure you can work out all the settings. Good luck.

Anyway. hope you can solve it . By the way, nothing is impossible and impossible is nothing.

Hello all,

I'm sorry if I gave the impression that all your posts were not helpful. Indeed, they have been very helpful in eliminating possible causes of my problem and ensuring I did not overlook something simple.

Hangdog42 and coldautumn: If you are setting the $DISPLAY variable by hand, and if you had to open ports in your firewall, I think you are probably not actually tunneling X over ssh. Let me explain: I currently am able to run X apps from my remote server on my local display. I ssh over to the remote server, set the $DISPLAY variable to reflect my local display, and start the X app. Just because I ssh'd over to the remote server does not mean the X display is tunneling over ssh. In fact, my local X server is listening on a port for incoming connection requests, and uses the X protocol (not ssh). It uses xhost to determine whether the incoming request should be allowed access to the local display.

This solution has worked well for many years, but I'd really like to see the benefits of using ssh only that I outlined in a previous message.

As I understand it, if you have to open an extra port in your firewall (or mark a network interface "trusted"), you are NOT using X over ssh. If you set the $DISPLAY variable on the remote machine, you are NOT using ssh (ssh MUST do this on its own). If you have to modify gdm to accept incoming tcp connections, you are NOT using ssh. When this solution is working as advertised, ssh should handle "faking out" the local display for the remote X application. There is no xhost authentication needed, and your local X server should not be accepting tcp connections. All data should be sent over the ssh connection you opened, and your local ssh client displays it locally, so the X server never knows it is actually drawing the screen of a remote application.

If anyone has this working under Fedora, I'd be interested to compare notes on your setup. But here's the test: try closing all ports in your firewall other than the ssh port and see if it still works. If it doesn't, I'm willing to bet you are not actually tunneling X over ssh, but using the old xhost method!

Thanks again for all the help. I really appreciate all the suggestions. Keep 'em coming!

Steve

Oh, I forgot to mention, I now have X installed on the remote machine. It is not actually running an X server (it is headless), but all the RPMs are installed.

Steve

Hm. I'll have to do some double checking, but I'm 99% sure that my firewall isn't accepting anything on port 6000. The server I'm using is on 24/7, so I'm more than a little paranoid about what ports I'm opening. I've been using nmap to check and I'm pretty sure there is no X client listening anywhere on the remote machine. After I did some more reading, I telinited the remote computer to runlevel 3, confirmed that X was indeed shut down, set the DISPLAY variable, and then opened an ssh connection with the -X flag and then any X app I started in that ssh console would be displayed on the remote machine. I'll have to mess around with not setting DISPLAY and see if that makes a difference.

For what it is worth, I've found that the biggest variable seems to be the local environment. For reasons I really don't understand, my Slackware laptop has much more trouble with this than a Windows computer running Cygwin. Both the remote and the Linux laptop are updated Slackware 10 machines so the X environment should be identical, yet a program like rox, which runs just fine on both machines, refuses to run over the ssh connection. However, doing pretty much exactly the same thing on Windows and Cygwin allows me to run rox without a hitch.

Thanks for the advice Steve, I'll be doing some more checking to make sure I'm running this over ssh.

OK, I've done a few experiments and I'm 95% convinced that I'm running X over an ssh tunnel. I wrote a simple firewall on the remote machine that blocks everything coming in except port 22 and uses state matching to NEW, ESTABLISHED and RELATED packets out the outbound side.

I then SSH in without using the -X flag and cannot run any X applications. Instead I get an error that there is no DISPLAY. If I close that ssh session and start a new one only using the -X flag this time, it works. I can run X apps on the local machine. If I repeat the experiment only first setting DISPLAY=localhost:0.0, nothing changes, including the error message. I can only run X apps if I have used the -X flag with the ssh connection.

The reason I'm only 95% convinced is that no matter how I establish the ssh connection, I can't run X apps unless I allow NEW matches in the iptables OUTPUT chain. Simply opening port 22 in both directions doesn't do the trick. At the moment I'm chalking this up to my profoundly limited understanding of how ssh port forwarding and iptables interact, but if anyone has an explanation, I'd love to hear it.

What I don't get is why this wouldn't work on Fedora. Both X and openSSH are projects that Fedora uses, and presumably doesn't modify. In other words, you should be running the same software on Fedora that I'm running on Slackware, give or take a version. I'm also wondering if your firewall is causing trouble. My playing around with my firewall proved to me that I don't understand all the interactions that can occur and most of what I was doing prevented me from tunneling X, if that is what I'm doing.

Actually, I think you would want to block everything on the local machine except port 22, not the remote machine. What is happening when you use the non-ssh method for a remote X application is that the remote machine is connecting back to your local X server, based on the $DISPLAY variable.

This makes me think that you are correct--you are, in fact, tunneling X over ssh. At the very least, it indicates that ssh is correctly setting the $DISPLAY variable on the remote machine. I don't think you should set the $DISPLAY variable yourself for the remote machine...ssh uses an offset of 10 automatically, for a reason I can't remember right now.

Agreed, which is why this is so frustrating! I saw a lot of people asking this question that use Fedora, but couldn't find an answer. It seems to work magically for people running other distros. I don't want to imply that this is a Fedora problem, but that something beyond my comprehension is different about the Fedora configuration. I am definitely not having a firewall issue. I've disabled the firewalls on both machines (they are both safely behind a firewalled gateway on my local network.) Ultimately, I want to use this method for a remote server, but for now the firewall can be considered a non-issue as it relates to my problem.

laminar1 suggested using Knoppix a few posts back, and that seems like a really good idea now. I can use Knoppix to stand in for the local machine, then the remote, and see if anything changes by distribution. I'll download and burn a copy this weekend and post here if I learn anything useful.

Thanks for all your efforts on this!

Steve

Hello,

I've been watching this interesting discussion for some time. I don't have a solution or anything but I just wanted to say that I think it is quite possible that the connection from the remote to the local machine (the presumably tunneled X session) is actually at least RELATED to the ssh connection, if not part of the ESTABLISHED connection. And if this is the case, you might be running X "outside" of ssh...

Some loud thinking: I wonder what interface the local connection to the X server uses? Would it be possible to tell iptables to block everything NEW inbound coming over your local NIC (like eth0) to ports 6000-6011? (I believe these are the ports where NEW X connection requests to the X server are arriving, including sshd's X11DisplayOffset.) If this would work - which is dubious at best - can't one be reasonably sure that the X connection from the remote to the local machine goes through the ssh connection, through a port that is used in the ssh session, to the local machine, and then over the local interface (lo) to X? You may laugh, but not too loudly Of course this won't solve anything, but might test if you've got the tunneling working.

A few things that might help you settle this issue (since it seems good info on this is scarce on the web): (1) use lsof -i and netstat -natp to see what connections you have and what programs are using them. (2) Use a packet sniffer, I'd recommend ethereal, to see if the packets are encrypted. Err, actually I don't really know how much you can see, but it might give you some idea.

Cheers!

Yeah, this is exactly what has been bugging me but my limited knowledge of how networking really works gets in the way. I know that for a ssh client, the outbound connection can occur from any port, but is always directed at port 22. The ssh daemon is always listenting at port 22, but I don't know if that is the port it uses to return data to an ssh client. From the messing around I've been doing with my firewall, the answer seems to be no.

Thanks for the suggestions on how to monitor this. When I find some time, I'll have to experiment and see if I can figure out what is happening.

OK, I'm pretty much convinced ssh -X is doing the job. I ran ethereal on both computers, made an ssh -X connection and ran a couple of X apps. As far as I can see, the only traffic between the two computers is over ssh. All of the packets are either marked as ssh traffic or are TCP related to ssh (these are all marked as ACK).

Hello, Steve:

Thank you for posting your question. I solved my problem from reading your discussions on the issue. I don't know if you have resolved your problem but sure like to share my experience as a feedback to our linuxquestions.org community.

I have two linux servers running RH9.0. Both (local and remote) machines have direct access to the internet. It took me only two steps on each machine to make it work both ways. The local can be the remote and the remote can be the local.

1). vi /etc/ssh/sshd_config on both machines to include the following 3 lines:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

It was not necessary to edit /etc/ssh/ssh_config because the lines
Host *
ForwardX11 yes
were already there.

2). ssh -X user@remote
3). entered password
4). # echo $DISPLAY
localhost:10.0
5). ran xterm, xclock, etc. all went fine

Regards,

Chuanyu

Any further on this one guys ??

This seems such a random, ad-hoc problem.

I was ssh in to my machinces here and at work and always ran X apps without a problem. Now it seems to of stopped working for no apparent reason.

I get the error:

Reading this thread, I added the -X argument to ssh and now get this

So added the above mentioned entried into ssh_config, restarted sshd on both sides without an error but now trying to make a simple ssh connection i get


I have no idea how I lost my X forwarding ability in ssh.

Be curious as to what the users in this thread ended up doing