<http://cygwin.com/acronyms/#PPIOSPE>. I set my Reply-To: for a reason -- please make sure your mailer respects it. Thanks.
Also, <http://cygwin.com/acronyms/#TOFU> reformatted. More below. On Mon, 6 Nov 2006, Bob Zagarello wrote: > -----Original Message----- > From: Igor Peshansky [mailto:[EMAIL PROTECTED] > Sent: Monday, November 06, 2006 8:00 PM > To: BZAG > Cc: [EMAIL PROTECTED] <http://cygwin.com/acronyms/#PCYMTNQREAIYR>. Thanks. > Subject: Re: Cygwin/X Authentication Config Issue > > > On Mon, 6 Nov 2006, BZAG wrote: > > > > > 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. > > > > That is not true. If the value of DISPLAY is literally the same as what > > ssh sets it to, things work just fine. > > > > > 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. > > > > Nope. When ssh tunnels X requests, it actually sets up a real X display. > > So, if your DISPLAY is set to something:10.0, you'll find something > > listening on port 6010. > > > > > To prove my point, ssh automatically sets DISPLAY to localhost:10.0 on > > > the remote X-client, EVEN IF IT IS OVER THE NETWORK. > > > > Of course. Since the ssh daemon sets up the X display on the machine > > you're connecting to, it wants all requests to go to the particular port > > on localhost, and will take care of forwarding the requests. If you set > > DISPLAY to the machine you're connecting from, ssh would have no way of > > intercepting the requests, and the X packets would go unsecured directly > > to your machine (and will fail to connect unless you allow it via xhost). > > > > > This plays a bit of havoc with one's sensibilities, because localhost is > > > normally the machine the interactive session is actually on. > > > > localhost is whatever machine the process is running on. In this case, > > it's the machine you've connected to via ssh. > > > > > 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. > > > > The interactive session actually runs on the X client machine. This is a > > normal role reversal in the X world -- the machine that shows the windows > > is the server, and the machine running the applications that display the > > windows is the client (which is the exact opposite of the ssh > > server/client roles). > > > > > 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 DISPLAY parameter is real, but you have to be careful to set it to > > EXACTLY the same value as what ssh would have set it to. Note that ssh > > sometimes selects the first available display value on the remote machine, > > which may not be 10. To make things worse, there are *two* DISPLAY values > > to consider: one you set on the local machine before running ssh, and the > > other that ssh sets automatically in the shell on the remote machine. > > > > > 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. > > > > The X11 display location here is most likely the former (i.e., the DISPLAY > > that the X server is exposing locally). I can't be sure, as I don't use > > PuTTY. > > > > > I had to REMOVE the "localhost:0" entry I had in the location parameter. > > > > This means that you probably don't run the X server on display 0. DISPLAY > > settings are very sensitive to the literal values, so you may actually > > need to set it to "localhost:0.0" or something similar. > > > > > I also tried "localhost:10" and that failed also. > > > > Of course. People normally don't run X on display 10. > > > > > By deleting the entry altogether, the tunnel now works with PuTTY. > > > > This may be because PuTTY defaults to "localhost:0.0", or it may be > > because DISPLAY is set in the environment before PuTTY starts... > > > > > The other related factoid is that all of this still comes over on port > > > 6000. > > > > On a local machine, yes. > > > > > 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. > > > > Try doing a "netstat -a" on the remote machine -- you'll see something > > listening on port 6010 there. Locally, port 6010 is not used, since your > > local X server is using port 6000. > > > > > 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. > > > > Huh? It may just be that MicroImages treats "localhost:0" as equivalent > > to "localhost:0.0"... > > > > Hope this clarifies things for you, > > Well, all I can say is that it didn't work when I set the display param. Again, it matters *where* you set DISPLAY and what you set it to. If you're talking about PuTTY's DISPLAY param, it needs to be set to whatever display the local X server is running on (which is usually "localhost:0.0" for Cygwin/X -- note the ".0"). On the remote machine, it needs to be set *exactly* to what ssh originally set it to -- but there is nothing magic about the value. > Once I took it out of my login script and stopped trying to change it, > it worked. There is a possibility of setting or not setting the screen > number to zero, and perhaps this was an issue. Exactly. Some X servers are more sensitive to this than others, Cygwin/X being one of the more sensitive ones. > Also, there is absolutely no record of port 60xx packets in the windows > firewall log (it's actually Sygate) once the display param was not used > - it all got pumped through the ssh tunnel - and I had been seeing them > when it *wasn't* working. Perhaps the firewall does not log packets to open ports... Or something else was in play. But ssh is not a magic program -- it uses the X protocol for capturing packets to forward, just like any other X server. > Note my last reply in that thread. The only other issue was > localhost:10. Display number 10 was the param being used and set by the > tunnel for this particular remote host or session, which is what I > didn't muck with to get it working. > > Thanks for the comments ! I will spend some time teasing this one out > based on them. There are a few documents on the net explaining in detail how ssh X forwarding works. Enjoy. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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/
