* X11Forward and xauth problems @ 2015-03-23 21:06 Andrew DeFaria 2015-03-23 21:26 ` Jon TURNEY 0 siblings, 1 reply; 9+ messages in thread From: Andrew DeFaria @ 2015-03-23 21:06 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X11Forward and xauth problems 2015-03-23 21:06 X11Forward and xauth problems Andrew DeFaria @ 2015-03-23 21:26 ` Jon TURNEY 2015-03-23 22:03 ` Andrew DeFaria 0 siblings, 1 reply; 9+ messages in thread From: Jon TURNEY @ 2015-03-23 21:26 UTC (permalink / raw) To: cygwin; +Cc: Andrew 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X11Forward and xauth problems 2015-03-23 21:26 ` Jon TURNEY @ 2015-03-23 22:03 ` Andrew DeFaria 2015-03-24 13:35 ` Jon TURNEY 0 siblings, 1 reply; 9+ messages in thread From: Andrew DeFaria @ 2015-03-23 22:03 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X11Forward and xauth problems 2015-03-23 22:03 ` Andrew DeFaria @ 2015-03-24 13:35 ` Jon TURNEY 2015-03-25 22:11 ` Andrew DeFaria 0 siblings, 1 reply; 9+ messages in thread From: Jon TURNEY @ 2015-03-24 13:35 UTC (permalink / raw) To: Andrew DeFaria, cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X11Forward and xauth problems 2015-03-24 13:35 ` Jon TURNEY @ 2015-03-25 22:11 ` Andrew DeFaria 2015-03-26 20:39 ` Jon TURNEY 0 siblings, 1 reply; 9+ messages in thread From: Andrew DeFaria @ 2015-03-25 22:11 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X11Forward and xauth problems 2015-03-25 22:11 ` Andrew DeFaria @ 2015-03-26 20:39 ` Jon TURNEY 2015-03-26 22:17 ` Andrew DeFaria 0 siblings, 1 reply; 9+ messages in thread From: Jon TURNEY @ 2015-03-26 20:39 UTC (permalink / raw) To: cygwin; +Cc: Andrew DeFaria 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X11Forward and xauth problems 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 0 siblings, 2 replies; 9+ messages in thread From: Andrew DeFaria @ 2015-03-26 22:17 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X11Forward and xauth problems 2015-03-26 22:17 ` Andrew DeFaria @ 2015-03-27 3:12 ` Andrew DeFaria 2015-03-30 13:40 ` Jon TURNEY 1 sibling, 0 replies; 9+ messages in thread From: Andrew DeFaria @ 2015-03-27 3:12 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: X11Forward and xauth problems 2015-03-26 22:17 ` Andrew DeFaria 2015-03-27 3:12 ` Andrew DeFaria @ 2015-03-30 13:40 ` Jon TURNEY 1 sibling, 0 replies; 9+ messages in thread From: Jon TURNEY @ 2015-03-30 13:40 UTC (permalink / raw) To: Andrew DeFaria, cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-03-30 13:33 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-23 21:06 X11Forward and xauth problems 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 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).