RE: Cygwin/X Authentication Config Issue
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
Re: Cygwin/X Authentication Config Issue
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/
Re: Cygwin/X Authentication Config Issue
BZAG bzag0 at yahoo.com writes: 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. I spoke a bit too soon about the port. The tunnel controls the port completely, so port 6000 doesn't even show up in the firewall. This makes sense, too, because all of the packets are using the SSH tunnel which is controlled under its own port. The fact that a netstat -n on the remote machne shows port 6010 on the localhost address is only an established listening post and is not used. The real traffic is going through the sshd tunnel and port. And none of this is sing any of the standard mechanisms for port forwarding (I am not using them in PuTTY, for example), just in case anyone is wondering. I'm done I hope. -- 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/
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, Igor --
Re: Cygwin/X Authentication Config Issue
BZAG bzag0 at yahoo.com writes: Addendum: The X Server works locally using a local X Client xterm session. I only have issues when it has to go out to the network. -- 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/
