Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Restate: The question is why do I get the warning and the X=20 authentication delay. Additionally, I am running Fedora 9 on my home system and I can ssh with = X forwarding with no warning as well as xauth list. Both have the gdm cookie. On 10/14/2008 11:01 AM, Jerry Feldman wrote: > The question is what do I get the warning. There is absolutely no=20 > delay in the authentication or the DNS. The delay is specific to X. I=20 > am logging into hosts that are locally connected via 2 Netgear GB=20 > switches. The problem is specific to X forwarding. I've got 8 systems = > on our LAN with my home directory exported from one of those servers=20 > (RHEL 4.6 X86-64). I can ssh from any of the X86-64 servers and my=20 > Ubuntu laptop to any of the other systems. The problem occurs only=20 > when connecting from my IA64 workstation AND using X forwarding. > ssh -X foo # this takes about 25 seconds > ssh foo # this is instantaneous > > Another clue is: > [gaf at boslc01 ~]$ xauth list > xauth: timeout in locking authority file=20 > /var/run/gdm/auth-cookie-XXF4YZIU-for-gaf > [gaf at boslc01 ~]$ ls -al /var/run/gdm/auth-cookie-XXF4YZIU-for-gaf > -rw------- 1 gaf algo 69 2008-10-13 08:49=20 > /var/run/gdm/auth-cookie-XXF4YZIU-for-gaf > > When I use the KVM and log in locally on one of the other servers,=20 > there is no xauth timeout, and apparently gdm does not set lock. > > > > On 10/14/2008 10:12 AM, John Abreau wrote: >> I don't see a question in there; I'll assume you meant to ask about >> the 20-second delay vs the normal 1-second delay. The first thing >> that comes to mind is DNS settings; a delay like that could occur >> if the sh client can't reach the first nameserver in /etc/resolv.conf,= >> but can reach the second one after the first one times out. >> >> >> >> On Tue, Oct 14, 2008 at 8:56 AM, Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> wrote: >> =20 >>> I am using Fedora 9 on an IA64 workstation. When I ssh -X to any host= >>> including localhost I receive the following message: >>> Warning: No xauth data; using fake authentication data for X11=20 >>> forwarding. >>> >>> I have looked at some of the blogs on this. I have changed my DIPLAY >>> environment variable from ":0.0" to "localhost:0.0" and to=20 >>> <hostname>:0.0" >>> with no change in the message. Additionally, ssh takes about 20=20 >>> seconds >>> from this host. When I ssh -X from our other servers (RHEL 4.6=20 >>> X86-64) the >>> login takes about a second, including ssh from one of the others=20 >>> hosts to >>> the IA64. >>> The public key authentication takes under 1 second, so all the delay = >>> occurs >>> after a successful login. Once logged in,X forwarding works fine. I=20 >>> have >>> "ForwardX11Trusted yes" set in /etc/ssh_config. >>> >>> OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007 >>> debug1: Reading configuration data /home/gaf/.ssh/config >>> debug1: Reading configuration data /etc/ssh/ssh_config >>> debug1: Applying options for * >>> debug1: Connecting to boslc04 [10.71.0.54] port 22. >>> debug1: Connection established. >>> debug1: identity file /home/gaf/.ssh/identity type -1 >>> debug1: identity file /home/gaf/.ssh/id_rsa type 1 >>> debug1: identity file /home/gaf/.ssh/id_dsa type -1 >>> debug1: Remote protocol version 1.99, remote software version=20 >>> OpenSSH_3.9p1 >>> debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.* >>> debug1: Enabling compatibility mode for protocol 2.0 >>> debug1: Local version string SSH-2.0-OpenSSH_5.0 >>> debug1: SSH2_MSG_KEXINIT sent >>> debug1: SSH2_MSG_KEXINIT received >>> debug1: kex: server->client aes128-cbc hmac-md5 none >>> debug1: kex: client->server aes128-cbc hmac-md5 none >>> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent >>> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP >>> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent >>> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY >>> debug1: Host 'boslc04' is known and matches the RSA host key. >>> debug1: Found key in /home/gaf/.ssh/known_hosts:7 >>> debug1: ssh_rsa_verify: signature correct >>> debug1: SSH2_MSG_NEWKEYS sent >>> debug1: expecting SSH2_MSG_NEWKEYS >>> debug1: SSH2_MSG_NEWKEYS received >>> debug1: SSH2_MSG_SERVICE_REQUEST sent >>> debug1: SSH2_MSG_SERVICE_ACCEPT received >>> debug1: Authentications that can continue: >>> publickey,gssapi-with-mic,password >>> debug1: Next authentication method: gssapi-with-mic >>> debug1: Unspecified GSS failure. Minor code may provide more=20 >>> information >>> No credentials cache found >>> >>> debug1: Unspecified GSS failure. Minor code may provide more=20 >>> information >>> No credentials cache found >>> >>> debug1: Unspecified GSS failure. Minor code may provide more=20 >>> information >>> >>> >>> debug1: Next authentication method: publickey >>> debug1: Offering public key: /home/gaf/.ssh/id_rsa >>> debug1: Server accepts key: pkalg ssh-rsa blen 149 >>> debug1: Authentication succeeded (publickey). >>> debug1: channel 0: new [client-session] >>> debug1: Entering interactive session. >>> =3D=3D=3D=3D Note; All the delay takes place here =3D=3D=3D >>> Warning: No xauth data; using fake authentication data for X11=20 >>> forwarding. >>> debug1: Requesting X11 forwarding with authentication spoofing. >>> debug1: Sending environment. >>> debug1: Sending env LANG =3D en_US.UTF-8 >>> Last login: Tue Oct 14 08:36:05 2008 from 10.71.0.51 >>> >>> =20 --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |