X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=DW0HlZjrb/pErUJ5
	iOXmUol+5Amq7MS2XEwejImwnqocGFKjkY4zKLk9mI2Sh5sbrwTUFS0jEnNnXJpa
	zEzKnWz0khGM2H2Nmp3Oykaz4idgyJgqdRRFuZhBIC/61ecvb6SE/0Emi4V8WXVG
	XH6TSzzzrOWV0gYwL9XoRXb02hE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=oFZ8n3M2VEuwUqZdb7/+gn
	MniD0=; b=LraCP9IWFQkKWkAF/Wk3q1zrLZq14YgaOoVymQNSsy+9iPM8Eizuy3
	DC/dS73LdEGx3z6A8+l+uUQ7vTeBMTaIjEIa0K2a7Dk2z2sEgc/6emayEV9QZUZe
	ZbOcOXEOFGtffDSS25yhODbCvEDlrgNOdGbh+kr4X10dwAY+YUajs=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
X-HELO: out2-smtp.messagingengine.com
Message-ID: <551950A4.2040502@dronecode.org.uk>
Date: Mon, 30 Mar 2015 14:33:24 +0100
From: Jon TURNEY <jon DOT turney AT dronecode DOT org DOT uk>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Andrew DeFaria <Andrew AT DeFaria DOT com>, cygwin AT cygwin DOT com
Subject: Re: X11Forward and xauth problems
References: <mepu7q$9dr$1 AT ger DOT gmane DOT org> <55108046 DOT 1070206 AT dronecode DOT org DOT uk> <meq0g3$hob$1 AT ger DOT gmane DOT org> <55115B29 DOT 8000904 AT dronecode DOT org DOT uk> <meurth$g26$1 AT ger DOT gmane DOT org> <55145A0D DOT 4010406 AT dronecode DOT org DOT uk> <mf1vti$utq$1 AT ger DOT gmane DOT org>
In-Reply-To: <mf1vti$utq$1@ger.gmane.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 26/03/2015 22:06, Andrew DeFaria wrote:
> On 3/26/2015 12:12 PM, Jon TURNEY wrote:
>> On 25/03/2015 17:40, Andrew DeFaria wrote:
>>> Prediction: This problem probably will end up having something to do
>>> with the permissions and file system that ~/.Xauthority resides on,
>>> which is, I believe, a NetApp. This file system is the file system for
>>> the Linux Home directories (Windows "home" directories are somewhere
>>> else). In an attempt to have a transparently workable environment I set
>>> my Cygwin home directory to access the same directory my Linux servers
>>> use for the home directory - this NetApp. If you need more information
>>> about that then let me know and perhaps tell me how I can get that.
>>
>> This seems very plausible.
>>
>> If I am understanding you correctly, ~/.Xauthority is the same file on
>> the NetApp at both ends.  I think perhaps that is somehow the cause of
>> the problem.
>
> Yes.
>>
>> The sequence of actions is something like:
>>
>> - startx(|win) generates a random cookie and stores it in
>> ~/.serverauth.<pid> and uses that file as the server -auth option
>> - it also uses 'xauth add' to put that cookie into ~/.Xauthority for the
>> display (e.g. :0)
>
> I'm not using startx - I just do C:\Cygwin\bin\XWin.exe -multiwindow
> -listen tcp

Sorry, I don't think you had mentioned that before.

It's even simpler then:

- ssh looks for a cookie for $DISPLAY (e.g. :0) in ~/.Xauthority using 
'xauth list',  discovers there isn't one so makes one up and sends it to 
the far end (this what "Warning: No xauth data; using fake 
authentication data for X11 forwarding." is telling you)
- sshd tries to store that cookie using xauth for the proxy display (e.g 
:10)

>> Reading the source of xauth [1], it does try to lock the ~/.Xauthority
>> file for up to 20 seconds before giving up, which perhaps corresponds to
>> the delay you see?
>
> Sounds plausible. Is that configurable?

Unfortunately, no.

Possibly you could set XAuthLocation in ssh(|d)_config to a wrapper 
script which uses 'xauth -i' to ignore locks.

Does 20 seconds actually match the length of the delay you see?

>> However, the "unable to link authority file .Xauthority, use
>> .Xauthority-n" message indicates that the working file .Xauthority-n
>> cannot renamed as .Xauthority (xauth tries both to hard-link it as
>> .Xauthority, and to rename it)
>
> After I ssh -X to this system I do see ~/.Xauthority and
> ~/.Xauthority-n. They are the same size but differ binarily. I can do mv
> ~/.Xauthority-n ~/.Xauthority without issue. Why can't sshd do that?
>
> Once I rename the file X clients work! From that machine...

> So the plot thickens... Why was mv denied permission when I can easily
> do it once I get a prompt?

It kind of looks like perhaps there is some kind of delay in releasing 
the file lock?

You might like to try running something like 'xauth -f ~/foo add :99 . 
`mcookie`' at both ends in rapid succession and see if that works or 
fails in the same way?

> Any idea why setting ForwardX11 yes and ForwardX11Trusted don't seem to
> work? I thought it was that setting ForwardX11 yes is equivalent to
> specifying -X and setting ForwardX11Trusted yes is equivalent to
> specifying -Y but they are not behaving that way!
>
> Adefaria-lt:echo "ForwardX11 yes" > ~/.ssh/config
> Adefaria-lt:ssh cm-db-ldev01 "echo DISPLAY = \'\$DISPLAY\'"
> Warning: untrusted X11 forwarding setup failed: xauth key data not
> generated
> Warning: No xauth data; using fake authentication data for X11 forwarding.
> X11 forwarding request failed on channel 0

This seems to be a separate question, but the first thing I would check 
is if is X11Forwarding permitted by the sshd_config on cm-db-ldev01?

> I find all of this behavior erratic and unreliable.

Indeed.  But I think that the erratic and unreliable thing is the 
networked file system, not ssh.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple