public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Jon TURNEY <jon.turney@dronecode.org.uk>
To: Andrew DeFaria <Andrew@DeFaria.com>, cygwin@cygwin.com
Subject: Re: X11Forward and xauth problems
Date: Mon, 30 Mar 2015 13:40:00 -0000	[thread overview]
Message-ID: <551950A4.2040502@dronecode.org.uk> (raw)
In-Reply-To: <mf1vti$utq$1@ger.gmane.org>

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

      parent reply	other threads:[~2015-03-30 13:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-23 21:06 Andrew DeFaria
2015-03-23 21:26 ` Jon TURNEY
2015-03-23 22:03   ` Andrew DeFaria
2015-03-24 13:35     ` Jon TURNEY
2015-03-25 22:11       ` Andrew DeFaria
2015-03-26 20:39         ` Jon TURNEY
2015-03-26 22:17           ` Andrew DeFaria
2015-03-27  3:12             ` Andrew DeFaria
2015-03-30 13:40             ` Jon TURNEY [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=551950A4.2040502@dronecode.org.uk \
    --to=jon.turney@dronecode.org.uk \
    --cc=Andrew@DeFaria.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).