Reproducing the cygwin X problems

[Phil Betts]

Mike Ayers wrote:

> > From: cygwin-xfree-owner at cygwin.com
> > [mailto:cygwin-xfree-owner at cygwin.com] On Behalf Of Phil Betts
                               ^^
http://cygwin.com/acronyms/#PCYMTNQREAIYR

> > It might have worked, but it was wrong.  Do not set the DISPLAY
> > environment variable.  It is set by ssh -Y to something similar to
> > "localhost:10.0" - the actual value depends on whether there are
> other
> > forwarded X connections to that box.
> 
> 	I do not usually set it.  I only did so in the sample to satisfy
> FAQ 6.1.

What part of this (from FAQ 6.1):

  $ DISPLAY=localhost:0.0
  $ export DISPLAY
  $ ssh -Y remotehost

says set the DISPLAY to the IP address of the server after starting ssh?
Please re-read the FAQ carefully.

It works like this.  You run "ssh -Y remotehost".  ssh makes a connection
to $DISPLAY on your local machine (probably ":0").  On the remotehost
side, the sshd daemon starts a proxy X server (localhost:10.0 say), and
sets $DISPLAY to match.  When you start an X application on remotehost,
it connects to the proxy server, which forwards all requests to the local
host over the ssh tunnel.  The ssh process then passes on the requests to
the local X server.

> 
>> BEFORE running ssh, you need to ensure that $DISPLAY is set correctly
>> for local connections (probably ":0").
> 
> 	127.0.0.1:0, set by the system.  I ordinarily do not check it, as
> I've never needed to set it when things worked.
> 
>> By specifying your own value for $DISPLAY inside the ssh session, you
>> are ensuring that all X traffic bypasses the ssh tunnel and
>> sets up its own (insecure and not encrypted) connection.  This new
>> connection must
>> then go through the normal authentication process and it will appear
>> to the X server as a remote connection, whereas the ssh connection
>> looks like a local connection to the server.
> 
> 	FAQ needs updating, and my problem remains.

No, the FAQ is correct.  If you had followed it, and still couldn't
connect, then your problem had changed.  Your original problem was
(probably) because you hadn't given permission for remote connections
from mikeayers-linux-2.  Since ssh -Y connects as a local program, there
are no permission problems (assuming you can run a local xterm).

First, make sure your X server is running, and your $DISPLAY is set
correctly.  Now enter the following commands _exactly_:

echo $DISPLAY
ssh -Y mayers@mikeayers-linux-2
echo $DISPLAY
xterm

If that doesn't work, paste the results in a reply, along with the output
of the xhost command (no parameters) run locally.

Note that I sometimes have problems connecting to older Linux boxes,
where the first ssh connection fails to set up the proxy.  In that case,
a second attempt (whilst the first is still connected) succeeds.  For
example, the first connection sets up a non-working proxy of
localhost:10.0.  Starting a new session sets up a working proxy of
localhost:11.0.  You might want to try that trick, but if that works,
the problem is on the Linux end.

Phil
-- 

This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.