delorie.com/archives/browse.cgi | search |
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> |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |