Podczas próby połączenia SSH z hostem otrzymałem następujący komunikat xauth:

/ usr / bin / xauth: limit czasu w pliku uprawnień do blokowania /home/sam/.Xauthority

UWAGA: Próbowałem zdalnie wyświetlić interfejs GUI X11 za pośrednictwem połączenia SSH, więc musiałem xauthmóc $HOME/.Xauthoritypomyślnie utworzyć plik, ale jak wskazał ten komunikat, najwyraźniej tak nie było.

Próby uruchomienia dowolnych aplikacji opartych na X11, takich jak na przykład xeyesten komunikat:

$ xeyes
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0

Jak mogę rozwiązać ten problem?

Uruchomienie stracena zdalnym systemie, w którym xauthzawodzi, pokaże, co się dzieje xauth.

Na przykład

$ strace xauth list
stat("/home/sam/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0

Więc xauthpróbuje otworzyć plik i już istnieje. Plik winowajcy to /home/sam/.Xauthority-c. Możemy potwierdzić obecność tego pliku w systemie zdalnym:

$ ls -l .Xauthority*
-rw------- 1 sam sam 55 Jul 12 22:04 .Xauthority
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-c
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-l

Poprawka

Jak się okazuje. Te pliki są plikami blokującymi .Xauthority, więc ich usunięcie rozwiązuje problem.

$ rm -fr .Xauthority-*

Po usunięciu plików wyjdź z połączenia SSH, a następnie ponownie połącz. Umożliwi xauthto ponowne uruchomienie z powodzeniem.

$ ssh -t skinner ssh sam@blackbird
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Sun Jul 12 22:37:54 2015 from skinner.bubba.net
$

Teraz jesteśmy w stanie uruchomić xauth listi X11 aplikacje bez problemu.

$ xauth list
blackbird/unix:10  MIT-MAGIC-COOKIE-1  cf01f793d2a5ece0ea58196ab5a7977a

GUI

$ xeyes

Alternatywna metoda rozwiązania problemu

Natknąłem się na ten post zatytułowany: xauth: błąd w blokowaniu pliku autoryzacji .Xauthority [linux, ssh, X11], który wspomina o użyciu xauth -bdo łamania wszelkich blokowanych plików, które mogą się zawieszać. xauthwydaje się, że strona podręcznika man to kopii zapasowej:

 -b      This option indicates that xauth should attempt to break any
         authority file locks before proceeding.  Use this option only to
         clean up stale locks.

Referencje

• Radzenie sobie z błędami „błąd w blokowaniu pliku urzędu” xauth

Przyczyną problemu może być brak uprawnień do zapisu w katalogu $ HOME.

Właśnie dlatego dostałem tę wiadomość:

/ usr / bin / xauth: limit czasu w pliku autoryzacji blokady /home/fooftp/.Xauthority

Oto jak sprawdziłem pozwolenie:

fooftp@for-fun-work:~> ls -l .Xauthority 
-rw-r--r-- 1 fooftp fooftp 1 Sep 14  2015 .Xauthority
# Conlusion: I can write this file: ok

fooftp@for-fun-work:~> rm .Xauthority
rm: cannot remove '.Xauthority': Permission denied
# Conlusion: strange ... I can't delete it 

fooftp@for-fun-work:~> id
uid=1001(fooftp) gid=1000(fooftp) groups=1000(fooftp)
# Conlusion: Yes, I am user fooftp

fooftp@for-fun-work:~> ls -ld .
dr-xr-xr-x 14 fooftp fooftp 4096 Sep 14  2015 .
# Conlusion: Bug found :-)
# The permissions should be "rwx" for you.

Jeśli to jest problem, musisz upewnić się, że masz uprawnienia do zapisu w $ HOME:

chmod u+rwX $HOME

Mam inną odpowiedź na pytanie, które nękało mnie, zanim zrozumiałem problem. Problemem jest błąd w systemie operacyjnym Fedory i jego pochodnych, jak się później zorientowałem. Jeśli problem nie jest taki, jak wskazano w zaakceptowanej odpowiedzi i / lub nie korzystasz z Fedory, RedHat, Korory itp., To ci to nie pomoże.

Problem

Jak powiedział slm użytkownika, uruchomienie strace da ci wskazanie problemu, ale w tym konkretnym przypadku błędu, wynik jest inny:

$ strace xauth list
  ...
  stat64("/home/USER/.Xauthority-c", 0xbff23280) = -1 ENOENT (No such file or directory)
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
  ...

Żeby było jasne, oznacza to, że kod powrotu EACCES, który jest odmowa zgody. Różni się to od problemu użytkownika slm, w którym miał kod powrotu EEXIST, co oznacza, że ​​plik istnieje. Tak więc, w przypadku kodu powrotu EACCES, pierwszą rzeczą, którą sprawdzasz, jest: czy skonfigurowano moje uprawnienia do domu, aby móc pisać w moim katalogu domowym? Najpierw powinieneś sprawdzić, czy masz flagę zapisu w swoim katalogu domowym dla własnego użytkownika. Jeśli to zrobisz, możesz być ofiarą opisanego poniżej błędu.

Bug

Przez kilka wyszukiwań w Google udało mi się w końcu znaleźć kogoś z podobnym problemem, co doprowadziło mnie do zgłoszenia błędu Fedory. Dla tych z Was, którzy chcą o tym przeczytać: https://bugzilla.redhat.com/show_bug.cgi?id=772992

Obejście

Obejście problemu:

#verify you're not crazy
$ xauth list
  /usr/bin/xauth:  timeout in locking authority file /home/USER/.Xauthority
#use restorecon to reset it all
$ /sbin/restorecon -v -v /home/USER/.Xauthority 
$ /sbin/restorecon -v -v -R /home/USER/
#log out of the remote system
$ exit

Gdy ponownie włączysz SSH, w tym momencie powinno być w porządku i powinieneś być w stanie ponownie pomyślnie przenieść sesję X.

EDYCJA (i inne alternatywne obejścia):

Aby być jak najbardziej kompletnym, inni użytkownicy stwierdzili w raporcie o błędzie, że powyższa poprawka nie działała dla nich - zdarzyło się, że zadziałało dla mnie. Kolejną próbą obejścia tego problemu (osobiście nie zweryfikowałem tego obejścia):

# setsebool -P use_nfs_home_dirs 1

Inna osoba wspomina coś o GDM, o którym nie mam żadnej wiedzy. Jeśli to dotyczy ciebie, polecam przeczytanie jego postu w BugZilli i sprawdzenie, czy jego komentarz coś dla ciebie znaczy.

Konfiguracja SELinuksa to pierwsza rzecz do sprawdzenia, z ...

*/usr/sbin/sestatus*

lub

*/usr/sbin/sestatus -v*

Jeśli konfiguracja SELinux jest ustawiona na „Wymuszanie” , może to powodować problem „xauth” .

 /usr/sbin/setenforce 0

Możesz tymczasowo ustawić go w tryb „permisive” w następujący sposób (aby wykluczyć ten problem jako podstawową przyczynę problemu) .

Następnie postępuj zgodnie z samouczkiem SELinux, aby wprowadzić odpowiednią konfigurację lub ją wyłączyć, jeśli wolisz inną metodę bezpieczeństwa (np. Edytując plik konfiguracyjny / etc / selinux / config w RHEL v.6)