Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

no Xauth data



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org