FedoraForum.org - Fedora Support Forums and Community
Page 1 of 2 1 2 LastLast
Results 1 to 15 of 16
  1. #1
    Join Date
    Dec 2007
    Posts
    23

    .Xauthority problems

    I'd been SSH'ing to my fedora 12 box from a laptop since I installed the operating system. I've always connected using:

    ssh -X name@machine

    This has worked as long as I remember. However, just recently, I've been getting errors and remote X sessions don't work. Fundamentally, I get errors like these:

    Code:
    $ ssh -X name@machine
    name@machine's password:
    Last login: Sun Feb 28 15:59:46 2010 from localhost
    /usr/bin/xauth:  timeout in locking authority file /home/name/.Xauthority
    $
    I've looked for solutions. It seems that most people have this problem when they screw up the ownership of their home directory so that it's not owned by the user. But, I've checked both ownership and permissions, and there is no problem there.

    On another forum, someone had the problem, deleted the .Xauthority file from the affected user (like me it's only one user who has the problem) and restarted X. For them, problem solved. For me, problem not solved. The affected user can log in and run X applications, but ssh -X simply doesn't work. Same error messages. "xhost +" gives the output:

    Code:
    xhost +
    X11 connection rejected because of wrong authentication.
    xhost:  unable to open display "localhost:10.0"
    The curious thing is that the person whose problem was solved deleted the .Xauthority file, and a new one was created. But in my case, no such file has been created. But they can run X fine. If I delete the .ICEauthority file (as recommended by another "solution"), then the file gets recreated, but the problem is still there.

    Running xauth -b doesn't help either.

    Code:
    $ xauth -b
    Attempting to break locks on authority file /home/name/.Xauthority
    xauth:  timeout in locking authority file /home/name/.Xauthority
    $
    So, I'm completely stumped. Does anyone know what might be wrong?

    Another page says that copying the .Xauthority from another user, and then changing the permissions to:

    -rw------- name users .Xauthority

    would work. I tried it, and it doesn't.
    Last edited by RossClement; 28th February 2010 at 05:23 PM.

  2. #2
    Join Date
    Jun 2009
    Posts
    472


    Annoying isn't it ?

    here a hint: if it worked before , and now it doesnt. something was changed
    So , Did you disable ipv6?

    Openssh needs to know not to use ipv6 or strange things happen , such as not being able to run xauth to create new Xauthority files, or use existing ones.

    if you HAVE disabled ipv6 , then I suggest you do the following and see if it helps. Please edit your sshd config to only use ipv4

    in the file /etc/ssh/sshd_config uncomment the line AddressFamily and use inet as the argument


    AddressFamily inet

    restart sshd and you should be good to go for your X11 Forwarding and xauth should now work to create Xauthority files



    from man sshd_config

    AddressFamily
    Specifies which address family should be used by sshd. Valid
    arguments are ``any'', ``inet'' (use IPv4 only) or ``inet6'' (use
    IPv6 only). The default is ``any''.

  3. #3
    Join Date
    Dec 2007
    Posts
    23
    Thanks. I gave it a go. But, it hasn't made any difference. I still get this:

    Code:
    $ ssh -X name@machine
    name@machine's password:
    Last login: Mon Mar  1 21:58:06 2010 from 192.168.0.4
    /usr/bin/xauth:  timeout in locking authority file /home/name/.Xauthority
    $ gimp
    X11 connection rejected because of wrong authentication.
    Cannot open display:
    $
    Any ideas as to what I could try next?

  4. #4
    leigh123linux Guest
    Try

    Code:
    ssh -Y name@machine

  5. #5
    Join Date
    Dec 2007
    Posts
    23
    Thanks. I gave it a go, but still the same problem.

    Code:
    $ ssh -Y name@machine
    name@machine's password:
    Last login: Mon Mar  1 21:59:50 2010 from 192.168.0.4
    /usr/bin/xauth:  timeout in locking authority file /home/name/.Xauthority
    $

  6. #6
    Join Date
    Aug 2006
    Location
    /dev/realm/{Abba,Carpenters,...stage}
    Posts
    3,285
    Try
    Code:
    rm -fv  /home/name/.Xauthority
    For safer browsing, use OpenDNS nameservers 208.67.222.222 and 208.67.220.220

    SELinux User Guide

    AutoPager

  7. #7
    Join Date
    Jun 2009
    Posts
    472
    this is the clue to work with now ...

    timeout in locking authority file /home/name/.Xauthority
    on the machine that you are tryng to connect to . can you run lsof or lslk ?

    also run a ps ax and grep for auth

    we need to find what is keeping the file locked away from xauth. The Ipv6 stuff covers yours unable to use xauth issues ... this lock file issue is someting else.
    Do you have some other username owning the Xauthority file ? run ls -lZ on the file ,
    Do you have selinux blocking xauth from editing the file? -- see /var/log/audit/audit.log

  8. #8
    Join Date
    Dec 2007
    Posts
    23
    OK. /usr/sbin/lsof .Xauthority gives no output. I don't have lslk on my system.

    The .Xauthority file is owned by "name", "users".

    If I remove the .Xauthority file (move to different filename), then I get exactly the same error when logging in. No difference there.

    The SELinux file /var/log/audit/audit.log lists some "write denied" entries, such as these:

    Code:
    type=AVC msg=audit(1267518064.280:116): avc:  denied  { write } for  pid=5677 comm="xauth" name="name" dev=dm-0 ino=525236 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=dirtype=SYSCALL msg=audit(1267518064.280:116): arch=40000003 syscall=5 success=no exit=-13 a0=bfc0e29b a1=c1 a2=180 a3=1 items=0 ppid=5645 pid=5677 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts2 ses=4 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null)

  9. #9
    Join Date
    Jun 2009
    Posts
    472
    Well you definitely have at least one selinux issue. Xauth is being denied write access to "name"'s home directory


    it probably has the incorrect selinux context:
    tcontext=unconfined_u:object_r:home_root_t:s0
    typically a user's home directory has an selinux context of
    unconfined_u:object_r:user_home_dir_t:s0
    to find a files selinux context use the Z option with the ls command
    ls -lZ
    ls -ldZ
    ls -laZ

    you can change the context using the chcon utility

    man chcon

    example

    Code:
     chcon  unconfined_u:object_r:user_home_dir_t:s0 /home/name
    to confirm this is a selinux issue only you might want to try a test by temporarily putting selinux into permissive mode on the remote host ,

    as root please run /usr/sbin/getenforce ; /usr/sbin/setenforce 0 ; /usr/sbin/getenforce on the remote host ,

    remove your Xauthority file on the remote host and try a fresh login invoking an X session.

    Xauth should at that point write a new Xauthority file and enable your X11Forwarding socket on the loopback address of the remote host as well as set your DISPLAY variable.

    You can set selinux back to enforcing after your test with

    /usr/sbin/setenforce 1

    if there are other issues , you will run into them after setting selinux to permissive.
    Last edited by madhavdiwan; 2nd March 2010 at 01:50 PM.

  10. #10
    Join Date
    Oct 2004
    Posts
    8

    Re: .Xauthority problems

    Quote Originally Posted by madhavdiwan
    Well you definitely have at least one selinux issue. Xauth is being denied write access to "name"'s home directory


    it probably has the incorrect selinux context:
    typically a user's home directory has an selinux context of


    to find a files selinux context use the Z option with the ls command
    ls -lZ
    ls -ldZ
    ls -laZ
    Hi folks,
    I had similar problem in FC17.
    Thanks to this thread, I got to idea that selinux can be inviolved.
    (previously I cloned my /home directory contents to another partition)
    However, chcon itself as redommended above was not enough.
    I have found a selinux alert in /var/log/messages.
    Then I followed the suggestion of
    sudo sealert -l XXXXXXXXX_ID_YYYYY
    The first recommendation worked for me:
    sudo /sbin/restorecon -v /home

  11. #11
    Join Date
    Dec 2007
    Posts
    9

    Re: .Xauthority problems

    If your home directory is from an NFS mount AND you are running SELinux, this command needs to be run:

    setsebool -P use_nfs_home_dirs 1

    but if not use 'cat /var/log/audit/audit.log | audit2why' for potential SELinux reasons why...
    Last edited by lrsas2; 8th February 2013 at 06:38 PM.

  12. #12
    Join Date
    Mar 2013
    Location
    Warsaw, Poland
    Posts
    2

    Thumbs down Re: .Xauthority problems

    Assuming that X11Forwarding in the /etc/ssh/sshd_config file was set, there is only one step necessary: disable SELinux completely. To do so, edit /etc/selinux/config, and change

    SELINUX=enforcing
    to
    SELINUX=disabled

    then restart.

    It works, as it always did. If you need SELINUX working with X forwarding and, even worse, XDMCP,
    be patient. This issue has not been resolved for many years.

  13. #13
    Join Date
    Oct 2004
    Posts
    5

    Smile Re: .Xauthority problems

    Even with SELinux Permissive, I got the error message
    [/usr/bin/xauth: error in locking authority file /home/user/.Xauthority].
    I didn't have trouble as a root. Then I checked display by
    "env|grep DISPLAY". These were different for user and root.
    When I did "export DISPLAY=localhost:10.0" (the numbers
    10.0 was from the root's env), everything worked fine!
    This is on Fedora 17.

  14. #14
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,346

    Re: .Xauthority problems

    The file /home/<user>/.Xauthority is what xauth uses when the environment variable XAUTHORITY doesn't exist.

    Ever since Fedora went to putting it somewhere else (around F15/F16) that environment points to /var/run/gdm/auth-for-<user>-<some key>/database, or /run/<user>/...

    And that path is a tmpfs path. There are lots of ways for it to be prevented from working correctly.

    Your problem may be that either the environment variable XAUTHORITY or DISPLAY is getting cleared/deleted/modified by a profile.

    Sshd uses an arbitrary port to forward the X protocol. Normally this starts by adding 10 (a configurable value) to 6000 (the designated X base TCP port) The 10 is just to skip local displays that may be using a TCP connection. On any port allocation failure it adds 1 and tries again (not sure how many it tries before it quits).

    The fact that it worked when you did the "export DISPLAY...." sounds like a profile damaged the DISPLAY environment variable, which in turn causes ssh use of xauth to try for a nonexistent file that should/does exist.

  15. #15
    Join Date
    Apr 2015
    Location
    dominican replubic
    Posts
    1

    Re: .Xauthority problems

    Quote Originally Posted by madhavdiwan
    Well you definitely have at least one selinux issue. Xauth is being denied write access to "name"'s home directory


    it probably has the incorrect selinux context:
    typically a user's home directory has an selinux context of


    to find a files selinux context use the Z option with the ls command
    ls -lZ
    ls -ldZ
    ls -laZ

    you can change the context using the chcon utility

    man chcon

    example

    Code:
     chcon  unconfined_u:object_r:user_home_dir_t:s0 /home/name
    to confirm this is a selinux issue only you might want to try a test by temporarily putting selinux into permissive mode on the remote host ,

    as root please run /usr/sbin/getenforce ; /usr/sbin/setenforce 0 ; /usr/sbin/getenforce on the remote host ,

    remove your Xauthority file on the remote host and try a fresh login invoking an X session.

    Xauth should at that point write a new Xauthority file and enable your X11Forwarding socket on the loopback address of the remote host as well as set your DISPLAY variable.

    You can set selinux back to enforcing after your test with

    /usr/sbin/setenforce 1

    if there are other issues , you will run into them after setting selinux to permissive.
    Thank you, very much madhavdiwan

    Your instructions were very usefull!!
    specifcally your command:

    # chcon unconfined_u:object_r:user_home_dir_t:s0 /home/name
    Last edited by franciscocp11; 20th April 2015 at 05:25 PM. Reason: the command

Page 1 of 2 1 2 LastLast

Similar Threads

  1. SSH, Environment and Xauthority
    By trashbird1240 in forum Servers & Networking
    Replies: 5
    Last Post: 14th March 2010, 07:45 PM
  2. Fedora breaks .Xauthority location??
    By mallarj in forum Using Fedora
    Replies: 0
    Last Post: 13th November 2007, 11:16 PM
  3. .XAuthority missing
    By ronin1982 in forum Using Fedora
    Replies: 1
    Last Post: 12th November 2007, 09:40 PM
  4. problem with .Xauthority
    By conexion2000 in forum Using Fedora
    Replies: 1
    Last Post: 19th June 2006, 07:39 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •