X11Forward and xauth problems
Jon TURNEY
jon.turney@dronecode.org.uk
Thu Mar 26 20:39:00 GMT 2015
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.
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)
- ssh reads that cookie out of ~/.Xauthority using 'xauth list' and
sends it to the far end
- 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?
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)
Of course, sshd doesn't understand it's helpful advice to use a
different filename, so things don't work out so well. :)
Given that it works the first time, when there is no existing
~/.Xauthority, perhaps the NetApp doesn't permit this file to be renamed
over an existing file, for some reason?
You can tell startx to use a different file by using the XAUTHORITY env
var, so setting that to something like ~/.Xauthority-$HOSTNAME might be
a workaround. (Some googling on 'Xauthority hostname nfs' might be
informative)
Or editing startx and changing enable_xauth to 0 might also be a workaround.
> As you can see with my current ~/.Xauthority file things don't work. But
> if I remove them, the ~/.Xauthority* files one is created at the next
> login and everything works fine. Log out and back in however and it
> breaks again.
>>>> If you want this to work, you will now (since X server 1.17) need to
>>>> start the server with the option '-listen tcp'.
>>>
>>> Restarted Xwin with -multimonitor and -listen tcp. Now I get:
>>
>> Sorry for any ambiguity, but you have misunderstood what I wrote.
>>
>> If you want explicitly setting DISPLAY and allowing access using xhost
>> to work, you must start the server with the option '-listen tcp'.
>
> Sorry I misunderstood. This works for me and is a work around. But I
> wish I could get that xauth thing working correctly.
Good.
[1] http://cgit.freedesktop.org/xorg/app/xauth
--
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
More information about the Cygwin
mailing list