Ok, I think this is a great idea, but I can't get it to work.

I have a Linux box at home, and one at work, both running Fedora 5. I gave myself full access in and out of my networks on both boxes. So I don't think firewalls are an issue.

But ... I try the following:

Work CPU:
$ xhost +xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx being my home computer)
$ ssh -X xxx.xxx.xxx.xxx

Home CPU (via SSH session):
$ export HISTORY=yyy.yyy.yyy.yyy:0.0
$ gedit
cannot open display: (null)
Run 'gedit --help' to see a full list of available command line options.

or

$gedit --display=yyy.yyy.yyy.yyy:0.0
cannot open display: yyy.yyy.yyy.yyy:0.0
Run 'gedit --help' to see a full list of available command line options.

What's supposed to happen is the gedit window should display on my work computer. What am I missing?

UPDATE:
On my home CPU: I have verified that the 'X11Forwarding Yes' line in the /etc/ssh/sshd_config file is uncommented.
On my work CPU: I tried the ssh -Y option instead of -X.
Neither of these have worked.

Sorry, I had another question ...

Assuming I get this working, what would be the ramifications of starting 'exec gnome-session &' within my SSH session, rather than just an application? Would I then have my home GNOME desktop displayed on my work CPU, allowing me to work as if using something like VNC?

Investigate "FreeNX" and "NoMachine NX client". Both are free. Simple to setup, and MUCH MUCH faster than X forwarding. MUCH faster!!! There have been several threads on this topic in these forums.

I appreciate your suggestion. I'm still in the uphill learning phase of Linux, and in Linux style, I'd like to learn about what I'm doing wrong. Therefore I'd like to get this solution to work properly, then I will play with other options. Can you help me there?

* Do not do xhost or export anything or set display to anything; that defeats the purpose of X forwarding
* What is the output of "echo $DISPLAY" in your work computer before you SSH?
* What is the output of "echo $DISPLAY" on your home computer when you use SSH with X forwarding?
* Did you change the X11Forwarding directive recently? and if so, did you restart the SSH server afterwards?

I understand that you would like to get this to work, but VNC is so much faster and easier to set up that it might be more funt to try first. I use TightVNC from work to home, tunneled through a ssh client called PuTTY (I am on it now at work). It is easy to set up from MS Windows or Linux.

Start the vnc server on the host machine with "vncserver". Open vncviewer on the client machine (google for the command or read the TightVNC website; I forget the stuff that goes after "vncviewer"). Give the viewer the IP or domain name of the server. It will ask for a password and it will come up with a window from the server on the client. You have to edit the vnc configuration file to open different window managers. If you cannot get it running come back and we can do some more detailed instructions.

Good luck.

C

All of the instructions I've received say to reset the DISPLAY, and to set xhost permissions to allow X forwarding from the server.
'echo $DISPLAY' on the work CPU returns ':0.0'
'echo $DISPLAY' on the home CPU returns 'localhost:10.0'
I did not reset the X11Forwarding. It was already set. I have, however, restarted the home CPU a couple of times recently.

Until recently I have been using VNC, but that stopped working. I do know it's not a problem on the clients themselves, as they work with other computers on the same networks. My work firewall and home firewalls are set to allow all traffic between the 2 hosts. But there is a firewall between us (at a university campus), and I'm thinking they may have blocked VNC because it's insecure. This is why I'm looking for other methods.

I am willing to try different solutions. I just want to know the what's, how's and why's of my options. I also tend to lean on the minimalist side. The less software that needs to be involved, the better.

Hrmmm ...

I got it working, which is good (info below). Spooon, you were right about xhost and DISPLAY. I didn't need to change those. It appears that SSH takes care of that for me, as you said. Thanks for that tip.

What I did:
Logged in via ssh: 'ssh -X me@xxx.xxx.xxx.xxx'
Verified that correct display was set on the server: 'echo $DISPLAY' in the SSH window gave me 'localhost:10.0'
Executed my X apps: 'gedit', 'xterm' or 'firefox'.

I did find that using this form of tunnelling for this purpose is slow. But in the absence of alternatives, should do in a pinch.

One more hurdle learned and conquored! Thank you for your help guys!

you can get VNC working -- I've done it through a severely restrictive network. VNC was no-go. Port 80 was open, but VNC traffic was dropped. Port 22 was closed (SSH default), so I ran SSH on 80 -- no go, encrypted traffic is also dropped. So, I ran SSH on port 443 (https), which worked!

Then I forwarded ports:
where the 5901:localhost:5901 tells it "When I access port 5901 on this local machine, forward those packets to port 5901 on the remote machine." This assumes your VNC server to be running on display:1. Simply add your display number to 5900 to get your port number, and sub it in. Then tell vnc to access localhost:1 (or whichever display you're using.) Type 'man vncviewer' and look at how to adjust the encodings, because on my current machine, if you try to access localhost, it assumes you want a raw encoding... very slow over a network.