2

Я пытаюсь запустить сеанс экрана и подключиться к трем различным машинам с одним и тем же пользователем.

Вот что у меня в .screenrc

screen -t "machine1" 0 ssh user@machine1
screen -t "machine2" 1 ssh user@machine2
screen -t "machine3" 2 ssh user@machine3

Мой ~/.ssh/config содержит

ForwardX11 yes

Я получаю следующую ошибку в терминалах machine2 и machine3 .

Warning: No xauth data; using fake authentication data for X11 forwarding
/usr/X11/bin/xauth: error in locking authority file /home/user/.Xauthority

Если я удаляю только одну из машин из моего .screenrc, она работает правильно.

Как я могу избежать этой ошибки и подключиться к нескольким машинам с экрана.

РЕДАКТИРОВАТЬ: домашний каталог пользователя находится на NFS, и блокировка не работает должным образом с NFS. Чтобы обойти это, я старался либо иметь файл XAuthority в локальной файловой системе (/tmp), либо иметь один файл на ssh. Мне не удалось, почему-то мой xauth, похоже, полностью игнорирует переменную окружения XAUTHORITY . Все еще озадаченный ...

1 ответ1

1
/usr/X11/bin/xauth: error in locking authority file /home/user/.Xauthority

Вы когда-нибудь получали ту же ошибку без screen после того, как был установлен первый сеанс SSH? Странно, что ваше «Если я удаляю только одну из машин [..], она работает правильно», похоже, говорит, что 2 машины работают, но третья приводит к проблемам. Если ssh поддерживает несколько X-переадресованных соединений, то может быть, дело в том, чтобы делать что-то медленнее? Я думаю, это лучше всего проверить без screen . А что если поменять порядок машин?

Догадайся, что это .Xauthority находится на удаленной машине, но я не эксперт. (Если /home/user в вашем вопросе на самом деле был более конкретным каталогом, то вы можете легко определить, локальный он или удаленный.) Итак, странный вопрос: вы уверены, что все 3 машины действительно разные, и что никто другой не использует одну и ту же учетную запись? От man ssh:

ssh также автоматически настроит данные Xauthority на сервере. Для этого он сгенерирует случайный cookie-файл авторизации, сохранит его в Xauthority на сервере и проверит, что любые перенаправленные соединения содержат этот cookie-файл, и заменит его реальным cookie-файлом при открытии соединения. Настоящий куки-файл аутентификации никогда не отправляется на сервер (и в обычном режиме куки не отправляются).

(И не могли бы вы заменить screen на ssh -f -N , или вы используете заголовок экрана, чтобы иметь возможность что-то остановить?)

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .