After ALOT of horsing around with this issue and trying to understand how all of this works, I finally zeroed in on my own problem which was, after all, documented somewhere. The issue is that the DISPLAY parameter CANNOT be set in any login shells on the remote X-client, EVEN IF IT IS THE SAME VALUE.
If someone could actually explain this that would be great, because I've been trying to understand how this works for some time. My guess at it is this: Once the SSH tunnel is established, changing the DISPLAY environment via login script or interactively tries to bypass the tunnel and go its own way, even if the DISPLAY value is the same IP:displaynumber.screennumber as the one being used. To prove my point, ssh automatically sets DISPLAY to localhost:10.0 on the remote X-client, EVEN IF IT IS OVER THE NETWORK. This plays a bit of havoc with one's sensibilities, because localhost is normally the machine the interactive session is actually on. But because it is an SSH tunnel, the interactive session "remembers" that it is on your X-server's machine and NOT on your X-Client machine. So, the DISPLAY parameter that is actually IN your X-Client's environment is not REAL because of the tunnel, and setting it to the same value interactively actually DOES change it to the REAL localhost of your X-Client, thus destroying your connection to the tunnel. The big kicker for me is that I use PuTTY, and in the SSH-X11 section of PuTTY there are TWO entries. One is a check box for X11 Forwarding and the other is an X11 display location parameter. I had to REMOVE the "localhost:0" entry I had in the location parameter. I also tried "localhost:10" and that failed also. By deleting the entry altogether, the tunnel now works with PuTTY. The other related factoid is that all of this still comes over on port 6000. The fact that localhost:10 is used is neither here nor there as far as the port is concerned because the tunnel is already established before you logon. Anyone who plays with firewall logs will know that if you toy with the display number interactively on the remote server, it generally causes the remote machine to spit out on port 6000+displaynumber. This is NOT the case if you don't mess with the DISPLAY environment. KUDOS to the guys from MicroImages, because their X-server works without these difficulties, meaning it uses the DISPLAY parameter set on the X-Client to connect. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
