Re: Cygwin/X Authentication Config Issue

[Igor Peshansky <pechtcha at cs dot nyu dot edu>]

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
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
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/