При попытке SSH на хост я получил следующее сообщение от xauth:

/ usr / bin / xauth: время ожидания в файле прав доступа блокировки /home/sam/.Xauthority

ПРИМЕЧАНИЕ. Я пытался удаленно отобразить графический интерфейс X11 через соединение SSH, поэтому мне нужно xauthбыло иметь возможность $HOME/.Xauthorityуспешно создать файл, но, как указывалось в этом сообщении, это явно не так.

Попытки запустить любые приложения на основе X11, такие как xeyesприветствовались с этим сообщением:

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

Как я могу решить эту проблему?

Запуск straceв удаленной системе, где xauthпроисходит сбой, покажет вам, что происходит xauth.

Например

$ 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

Так xauthпытается открыть файл, и он уже существует. Файл виновника есть /home/sam/.Xauthority-c. Мы можем подтвердить наличие этого файла в удаленной системе:

$ 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

Исправление

Как оказывается. Эти файлы являются блокирующими файлами .Xauthority, поэтому простое их удаление решает проблему.

$ rm -fr .Xauthority-*

После удаления файлов выйдите из SSH-соединения, а затем снова подключитесь. Это позволит xauthповторно выполнить успешно.

$ 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
$

Теперь мы можем запускать xauth listи приложения X11 без проблем.

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

GUI

$ xeyes

Альтернативный метод решения проблемы

Я наткнулся на этот пост под названием: xauth: ошибка в файле авторизации блокировки .Xauthority [linux, ssh, X11], в котором упоминается использование xauth -bдля взлома любых файлов блокировки, которые могут зависать. xauthСправочная страница, кажется, подтверждает это:

 -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.

Ссылки

• Работа с ошибками xauth «ошибка в файле блокировки»

Корень проблемы может заключаться в том, что у вас нет разрешения на запись в каталог $ HOME.

Вот почему я получил это сообщение:

/ usr / bin / xauth: время ожидания в файле прав доступа блокировки /home/fooftp/.Xauthority

Вот как я проверил разрешение:

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.

Если это проблема, то вы должны быть уверены, что у вас есть права на запись в $ HOME:

chmod u+rwX $HOME

У меня есть другой ответ на вопрос, который мучил меня, прежде чем я выясню проблему. Проблема заключается в ошибке в ОС Fedora и ее производных, как я позже выяснил. Если проблема не указана в принятом ответе, и / или вы не используете Fedora, RedHat, Korora и т. Д., То это вам не поможет.

Проблема

Как сказал пользователь slm, запуск strace покажет вам проблему, но в данном конкретном случае ошибка будет другой:

$ 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) 
  ...

Чтобы было ясно, это говорит о том, что EACCES возвращает код, который запрещен. Это отличается от проблемы пользователя slm, где у него был код возврата EEXIST, что означает, что файл существует. Итак, для кода возврата EACCES, очевидно, первое, что вы проверяете: настроены ли мои домашние разрешения, чтобы я мог писать в свой домашний каталог? Сначала вы должны убедиться, что в вашем домашнем каталоге есть флаг записи для вашего собственного пользователя. Если вы это сделаете, то вы можете стать жертвой ошибки, описанной ниже.

Ошибка

Через пару поисков в Google я наконец смог найти кого-то с подобной проблемой, и это привело меня к сообщению об ошибке в Fedora. Для тех из вас, кто хочет прочитать об этом: https://bugzilla.redhat.com/show_bug.cgi?id=772992

Обходной путь

Обходной путь к проблеме:

#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

Когда вы снова включите SSH, все будет хорошо, и вы сможете снова успешно перенести X-сессию.

РЕДАКТИРОВАТЬ (и другие альтернативные обходные пути):

Чтобы быть как можно более полными, другие пользователи указывали в отчете об ошибке, что приведенное выше исправление не работает для них - оно работает для меня. Другая попытка обойти проблему была (я не проверял этот обходной путь лично):

# setsebool -P use_nfs_home_dirs 1

Другой человек упоминает кое-что о GDM, о котором я ничего не знаю. Если это относится к вам, я рекомендую прочитать его пост в BugZilla и посмотреть, что его комментарий что-то значит для вас.

Конфигурация SELinux - самое первое, что нужно проверить, с ...

*/usr/sbin/sestatus*

или

*/usr/sbin/sestatus -v*

Если для конфигурации SELinux установлено значение «Enforcing», это может вызвать проблему «xauth» .

 /usr/sbin/setenforce 0

Вы можете временно установить его в «разрешающий» режим следующим образом (чтобы можно было исключить эту проблему как основную причину проблемы) .

Затем следуйте инструкциям SELinux, чтобы установить правильную конфигурацию или отключите ее, если вы предпочитаете другой метод защиты (f.ex.by, отредактировав файл конфигурации / etc / selinux / config в RHEL v.6)