This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: X11Forward and xauth problems
- From: Jon TURNEY <jon dot turney at dronecode dot org dot uk>
- To: Andrew DeFaria <Andrew at DeFaria dot com>, cygwin at cygwin dot com
- Date: Mon, 30 Mar 2015 14:33:24 +0100
- Subject: Re: X11Forward and xauth problems
- Authentication-results: sourceware.org; auth=none
- 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>
- Reply-to: cygwin at cygwin dot com
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