X11Forward and xauth problems

X11Forward and xauth problems

[Andrew DeFaria]

Normally I just turn on -X (or put X11Forward yes in ~/.ssh/config) but 
that usually results in a noticeable delay in logging in and the 
following error:

Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Cm-app-ldev01:

I've asked about this in the past and I think the answer was that the 
message was correct but you shouldn't worry about it. If it didn't slow 
me down I probably would just ignore it. But it slows me down. So I ssh 
instead without X11Forward turned on then, when I need to run an X 
client, I do export DISPLAY=adefaria-lt:0 and make sure that I did an 
xhost + there at least once. But now that's broken!

Adefaria-lt:xhost +
access control disabled, clients can connect from any host
Adefaria-lt:ssh cm-app-ldev01
Cm-app-ldev01:export DISPLAY=adefaria-lt:0
Cm-app-ldev01:xclock
Error: Can't open display: adefaria-lt:0
Cm-app-ldev01:

I still don't understand xauth but I've been playing with it and I can 
sometimes get it to work.

Adefaria-lt:rm ~/.Xauthority*
Adefaria-lt:ssh -X cm-app-ldev01 xclock
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  creating new authority file /home/adefaria/.Xauthority
Adefaria-lt:ssh -X cm-app-ldev01 xclock
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:12.0
Adefaria-lt:

The first ssh to cm-app-ldev01 to run xclock works fine. Do it again and 
it fails.

Ideal solution: ssh -X works with no warnings or musings about .Xauthority.

Workable solution(s): Either that ssh -X complains about .Xauthority but 
still reliably puts up X clients or I can use xhost + and export DISPLAY.
-- 
Andrew DeFaria
http://defaria.com


--
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

Re: X11Forward and xauth problems

[Jon TURNEY]

On 23/03/2015 20:48, Andrew DeFaria wrote:
> Normally I just turn on -X (or put X11Forward yes in ~/.ssh/config) but
> that usually results in a noticeable delay in logging in and the
> following error:
>
> Warning: untrusted X11 forwarding setup failed: xauth key data not
> generated
> Warning: No xauth data; using fake authentication data for X11 forwarding.

Firstly, if you don't want these warnings, use ssh -Y.

(By using ssh -X, you are asking for something which the X server can't 
give you, hence the warnings.  See 
http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trusted-untrusted-x11-forwarding 
for more details)

> /usr/bin/xauth:  unable to link authority file
> /home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
> Cm-app-ldev01:
>
> I've asked about this in the past and I think the answer was that the
> message was correct but you shouldn't worry about it. If it didn't slow

I'm sorry, I only have a vague memory of this discussion.

> me down I probably would just ignore it. But it slows me down. So I ssh
> instead without X11Forward turned on then, when I need to run an X
> client, I do export DISPLAY=adefaria-lt:0 and make sure that I did an
> xhost + there at least once. But now that's broken!
>
> Adefaria-lt:xhost +
> access control disabled, clients can connect from any host
> Adefaria-lt:ssh cm-app-ldev01
> Cm-app-ldev01:export DISPLAY=adefaria-lt:0
> Cm-app-ldev01:xclock
> Error: Can't open display: adefaria-lt:0
> Cm-app-ldev01:

If you want this to work, you will now (since X server 1.17) need to 
start the server with the option '-listen tcp'.

[1] https://cygwin.com/ml/cygwin-xfree-announce/2015-02/msg00026.html
[2] 
http://x.cygwin.com/docs/ug/using-remote-apps.html#using-remote-apps-telnet
[3] 
http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-remote-clients-cant-connect
[4] https://cygwin.com/ml/cygwin-xfree/2015-02/msg00051.html

-- 
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

Re: X11Forward and xauth problems

[Andrew DeFaria]

On 3/23/2015 2:06 PM, Jon TURNEY wrote:
> On 23/03/2015 20:48, Andrew DeFaria wrote:
>> Normally I just turn on -X (or put X11Forward yes in ~/.ssh/config) but
>> that usually results in a noticeable delay in logging in and the
>> following error:
>>
>> Warning: untrusted X11 forwarding setup failed: xauth key data not
>> generated
>> Warning: No xauth data; using fake authentication data for X11
>> forwarding.
>
> Firstly, if you don't want these warnings, use ssh -Y.
>
> (By using ssh -X, you are asking for something which the X server can't
> give you, hence the warnings.  See
> http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trusted-untrusted-x11-forwarding
> for more details)

Yeah but -Y gives me the same thing:

Adefaria-lt:ssh -Y cm-app-ldev01
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Cm-app-ldev01:

>
>> /usr/bin/xauth:  unable to link authority file
>> /home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
>> Cm-app-ldev01:
>>
>> I've asked about this in the past and I think the answer was that the
>> message was correct but you shouldn't worry about it. If it didn't slow
>
> I'm sorry, I only have a vague memory of this discussion.
>
>> me down I probably would just ignore it. But it slows me down. So I ssh
>> instead without X11Forward turned on then, when I need to run an X
>> client, I do export DISPLAY=adefaria-lt:0 and make sure that I did an
>> xhost + there at least once. But now that's broken!
>>
>> Adefaria-lt:xhost +
>> access control disabled, clients can connect from any host
>> Adefaria-lt:ssh cm-app-ldev01
>> Cm-app-ldev01:export DISPLAY=adefaria-lt:0
>> Cm-app-ldev01:xclock
>> Error: Can't open display: adefaria-lt:0
>> Cm-app-ldev01:
>
> 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:

Adefaria-lt:ssh -Y cm-app-ldev01
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Cm-app-ldev01:echo $DISPLAY
localhost:10.0
Cm-app-ldev01:xclock
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0
Cm-app-ldev01:


>
> [1] https://cygwin.com/ml/cygwin-xfree-announce/2015-02/msg00026.html
> [2]
> http://x.cygwin.com/docs/ug/using-remote-apps.html#using-remote-apps-telnet
> [3]
> http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-remote-clients-cant-connect
>
> [4] https://cygwin.com/ml/cygwin-xfree/2015-02/msg00051.html
>


-- 
Andrew DeFaria
http://defaria.com


--
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

Re: X11Forward and xauth problems

[Jon TURNEY]

On 23/03/2015 21:27, Andrew DeFaria wrote:
> On 3/23/2015 2:06 PM, Jon TURNEY wrote:
>> On 23/03/2015 20:48, Andrew DeFaria wrote:
>>> Normally I just turn on -X (or put X11Forward yes in ~/.ssh/config) but
>>> that usually results in a noticeable delay in logging in and the
>>> following error:
>>>
>>> Warning: untrusted X11 forwarding setup failed: xauth key data not
>>> generated
>>> Warning: No xauth data; using fake authentication data for X11
>>> forwarding.
>>
>> Firstly, if you don't want these warnings, use ssh -Y.
>>
>> (By using ssh -X, you are asking for something which the X server can't
>> give you, hence the warnings.  See
>> http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trusted-untrusted-x11-forwarding
>>
>> for more details)
>
> Yeah but -Y gives me the same thing:

This is similar, but it is not the same.

> Adefaria-lt:ssh -Y cm-app-ldev01
> Warning: No xauth data; using fake authentication data for X11 forwarding.
> /usr/bin/xauth:  unable to link authority file
> /home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
> Cm-app-ldev01:

I think this last message here is unusual, and is coming from xauth 
running on the remote server.  Can you you give a few more details on 
what OS that is running?

If you connect using ssh -vv -Y, you should be able to see the xauth 
commands that sshd is running, and if those, or some other step in the 
connection, is the cause of the delay.

You might also try running those xauth commands in the terminal to 
investigate further.

>>> Adefaria-lt:xhost +
>>> access control disabled, clients can connect from any host
>>> Adefaria-lt:ssh cm-app-ldev01
>>> Cm-app-ldev01:export DISPLAY=adefaria-lt:0
>>> Cm-app-ldev01:xclock
>>> Error: Can't open display: adefaria-lt:0
>>> Cm-app-ldev01:
>>
>> 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'.

-- 
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

Re: X11Forward and xauth problems

[Andrew DeFaria]

On 3/24/2015 5:40 AM, Jon TURNEY wrote:

>>> Firstly, if you don't want these warnings, use ssh -Y.
>>>
>>> (By using ssh -X, you are asking for something which the X server can't
>>> give you, hence the warnings.  See
>>> http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trusted-untrusted-x11-forwarding
>>>
>>>
>>> for more details)
>>
>> Yeah but -Y gives me the same thing:
>
> This is similar, but it is not the same.

What I mean by the same thing is that it also fails in the same manner:

Adefaria-lt:ssh -Y cm-app-ldev01
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Cm-app-ldev01:xclock
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:11.0
Cm-app-ldev01:

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.

OK, here's an odd sequence that seems to point to the "unable to link 
authority file" problem. Adefaria-lt is my Windows 7 laptop - 
Cm-app-ldev01 is a Cent OS 6.5

Adefaria-lt:echo $DISPLAY
:0
Adefaria-lt:ssh -X cm-app-ldev01
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Cm-app-ldev01:echo $DISPLAY
localhost:10.0
Cm-app-ldev01:xclock
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0
Cm-app-ldev01:rm .Xauthority*
Cm-app-ldev01:exit
logout
Connection to cm-app-ldev01 closed.
Adefaria-lt:ssh -X cm-app-ldev01
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  creating new authority file /home/adefaria/.Xauthority
Cm-app-ldev01:echo $DISPLAY
localhost:10.0
Cm-app-ldev01:xclock
Warning: Missing charsets in String to FontSet conversion
Cm-app-ldev01:exit
logout
Connection to cm-app-ldev01 closed.

Adefaria-lt:ls -l .Xauthority*
-rw------- 1 adefaria Domain Users 74 Mar 25 10:19 .Xauthority
Adefaria-lt:ssh -X cm-app-ldev01
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Cm-app-ldev01:echo $DISPLAY
localhost:10.0
Cm-app-ldev01:xclock
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0
Cm-app-ldev01:

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.

>> Adefaria-lt:ssh -Y cm-app-ldev01
>> Warning: No xauth data; using fake authentication data for X11
>> forwarding.
>> /usr/bin/xauth:  unable to link authority file
>> /home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
>> Cm-app-ldev01:
>
> I think this last message here is unusual, and is coming from xauth
> running on the remote server.  Can you you give a few more details on
> what OS that is running?

Cent OS 6.5

> If you connect using ssh -vv -Y, you should be able to see the xauth
> commands that sshd is running, and if those, or some other step in the
> connection, is the cause of the delay.

Adefaria-lt:ssh -vv -Y cm-app-ldev01
OpenSSH_6.8p1, OpenSSL 1.0.2a 19 Mar 2015
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 51: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to cm-app-ldev01 [10.252.8.152] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/adefaria/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/adefaria/.ssh/id_rsa-cert type -1
debug1: identity file /home/adefaria/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/adefaria/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/adefaria/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/adefaria/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/adefaria/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/adefaria/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 
curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 
ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: 
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: kex: server->client aes128-ctr umac-64@openssh.com none
debug1: kex: client->server aes128-ctr umac-64@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1544/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa 
SHA256:FM8zkVJ3lA+qEuWC0l+NV1szCmrG+f5czMTo2s6JZZ8
debug1: Host 'cm-app-ldev01' is known and matches the RSA host key.
debug1: Found key in /home/adefaria/.ssh/known_hosts:41
debug2: bits set: 1540/3072
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/adefaria/.ssh/id_rsa (0x0),
debug2: key: /home/adefaria/.ssh/id_dsa (0x60005f0f0),
debug2: key: /home/adefaria/.ssh/id_ecdsa (0x0),
debug2: key: /home/adefaria/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: 
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/adefaria/.ssh/id_rsa
debug1: Offering DSA public key: /home/adefaria/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 435
debug2: input_userauth_pk_ok: fp 
SHA256:ZijSNCmYg0tL2z4LIcRGLDS+AF3Ms+8Md93qGF5zHtc
debug1: Authentication succeeded (publickey).
Authenticated to cm-app-ldev01 ([10.252.8.152]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: X11 forwarding request accepted on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Cm-app-ldev01:

> You might also try running those xauth commands in the terminal to
> investigate further.

Cm-app-ldev01:xauth list :0
Cm-app-ldev01:echo $?
0

>
>>>> Adefaria-lt:xhost +
>>>> access control disabled, clients can connect from any host
>>>> Adefaria-lt:ssh cm-app-ldev01
>>>> Cm-app-ldev01:export DISPLAY=adefaria-lt:0
>>>> Cm-app-ldev01:xclock
>>>> Error: Can't open display: adefaria-lt:0
>>>> Cm-app-ldev01:
>>>
>>> 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.
-- 
Andrew DeFaria
http://defaria.com


--
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

Re: X11Forward and xauth problems

[Jon TURNEY]

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

Re: X11Forward and xauth problems

[Andrew DeFaria]

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

Note I don't see a ~/.serverauth. Maybe this file is created just for 
this purpose and quickly removed?

> - 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?

Sounds plausible. Is that configurable?

> 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 I thought this might be a crude workaround and put this in my .bashrc:

# Hack to fix ~/.Xauthority
if [ -f $HOME/.Xauthority-n ]; then
   mv $HOME/.Xauthority-n $HOME/.Xauthority
   echo "Fixed ~/.Xauthority"
fi

and then thought, "What happens when I ssh into yet another Linux 
machine that shares this home directory" and when I tried to ssh -X to 
another machine I got (with a little instrumentation):

Adefaria-lt:id
uid=20393(adefaria) gid=10513(Domain Users) groups=10513(Domain 
Users),0(root),545(Users)
Adefaria-lt:ssh -X cm-app-lprod01
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
/usr/bin/xauth:  unable to link authority file 
/home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n
Attempting mv /home/adefaria/.Xauthority-n /home/adefaria/.Xauthority
mv: cannot move `/home/adefaria/.Xauthority-n' to 
`/home/adefaria/.Xauthority': Permission denied
adefaria
uid=80176(adefaria) gid=701(Domain Users) groups=701(Domain 
Users),10013(CMAdmins),10014(CMMachines-admin.sec) 
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-rw-------. 1 adefaria Domain Users 223 Mar 26 13:25 
/home/adefaria/.Xauthority
-rw-------. 1 adefaria Domain Users 223 Mar 26 13:46 
/home/adefaria/.Xauthority-n
Cm-app-lprod01:mv .Xauthority-n .Xauthority
Cm-app-lprod01:

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

Could it be because on Cygwin my uid is 20393 and on Linux it's 80176 
(and probably equivalenced by some mapping in the Netapp of 20393 <-> 80176?

> 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?

But I did rename it once I got a prompt without a problem.

> 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)

Again, I don't use startx, I simply run Xwin directly. In fact the 
startx command is not found! Setting XAUTHORITY didn't do anything different

> Or editing startx and changing enable_xauth to 0 might also be a
> workaround.

Since I don't even have startx, this is not really an option.

I need to read that googling on 'Xauthority hostname nfs'...vi

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
DISPLAY = ''
Adefaria-lt:echo "ForwardX11Trusted yes" > ~/.ssh/config
Adefaria-lt:ssh cm-db-ldev01 "echo DISPLAY = \'\$DISPLAY\'"
DISPLAY = ''
Adefaria-lt:

Also why does this work:

Adefaria-lt:ssh -X cm-app-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.
DISPLAY = 'localhost:11.0'
Adefaria-lt:

But this fail:

Adefaria-lt:ssh -X 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
DISPLAY = ''
Adefaria-lt:


I find all of this behavior erratic and unreliable.
-- 
Andrew DeFaria
http://defaria.com


--
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

Re: X11Forward and xauth problems

[Andrew DeFaria]

On 3/26/2015 3:06 PM, Andrew DeFaria wrote:

Not having to wait 20 seconds every time I start a remote terminal would 
be a plus too!
-- 
Andrew DeFaria
http://defaria.com


--
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

Re: X11Forward and xauth problems

[Jon TURNEY]

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