☰

обновлять

tag-icon • tag-icon x11 ssh-tunneling xforwarding xauth
обновлять

С моей локальной машины я sshподключаюсь к удаленному серверу вместе с аутентификацией относительно X display. Я знаю, что в этом процессе MIT-MAGIC-COOKIESиспользуются и значение на сервере и клиенте должно быть идентичным, чтобы процесс аутентификации был действительным.

Однако, когда я вхожу на удаленный сервер и убеждаюсь, что X display работает нормально (например, выполняется, xclockчтобы увидеть, xclockвсплывает ли приложение на моей локальной машине), когда я проверяю значение cookie-файлов, значение на локальной машине и на удаленном сервере, похоже, различаются. Вот командные строки:

значение cookie на удаленном сервере

chulhyun@chulhyun-Inspiron-3420:~$ ssh -X Black@$labcom
Last login: Wed Jun 25 10:02:25 2014 from 

Black@Black-PC ~
$ xclock    ### xclock appears in local machine.

Black@Black-PC ~
$ xauth list
Black-PC/unix:10  MIT-MAGIC-COOKIE-1  708f623489b1ea129a77e98287d130ca

значение cookie на локальном компьютере

chulhyun@chulhyun-Inspiron-3420:~$ xauth list
chulhyun-Inspiron-3420/unix:0  MIT-MAGIC-COOKIE-1  5ddd2ce92004eab53ceee8a64b7b88c0

Как вы видите, значение cookie на двух машинах разное. Тогда разве X-дисплей не должен работать?

Что я здесь упускаю?

P.S. Я слышал, что $XAUTHORITYтам указан путь к xauthorityфайлу, и я проверил этот путь на локальной машине:

chulhyun@chulhyun-Inspiron-3420:~$ echo $XAUTHORITY
/var/run/gdm/auth-for-chulhyun-iZfH2u/database

Когда я заглядываю в файл «база данных», его содержимое невозможно прочитать, поскольку оно состоит из странных символов.

^A^@^@^Vchulhyun-Inspiron-3420^@^A0^@^RMIT-MAGIC-COOKIE-1^@^P]?,? ^D??<???      K{??

может ли это быть связано с вопросом?

обновлять

результат xhostи $XAUTHORITYна удаленном сервере

Black@Black-PC ~
$ xhost
access control enabled, only authorized clients can connect
SI:localuser:chulhyun

Black@Black-PC ~
$ echo $XAUTHORITY

*как оказалось $XAUTHORITYне определено... это нормально?

результат xhostна локальной машине

chulhyun@chulhyun-Inspiron-3420:~$ xhost
access control enabled, only authorized clients can connect
SI:localuser:chulhyun

решение1

Я думаю, вы путаете то, как SSH выполняет проксирование соединения X11 через туннель, который он устанавливает на стороне удаленного сервера, с тем, как обычно работают волшебные куки. Из страницы руководства SSH:

выдержка 
The DISPLAY value set by ssh will point to the server machine, but with a 
display number greater than zero.  This is normal, and happens
because ssh creates a “proxy” X server on the server machine for forwarding 
the connections over the encrypted channel.

ssh will also automatically set up Xauthority data on the server machine.  
For this purpose, it will generate a random authorization cookie,
store it in Xauthority on the server, and verify that any forwarded 
connections carry this cookie and replace it by the real cookie when the
connection is opened.  The real authentication cookie is never sent to the 
server machine (and no cookies are sent in the plain).

Так что, похоже, что волшебные куки, которые вы видите на стороне удаленного сервера, на самом деле не являются настоящими волшебными куки на локальном сервере (на вашей стороне). Помните, что DISPLAY устанавливается следующим образом, когда вы подключаетесь по SSH к удаленному серверу:

$ echo $DISPLAY
localhost:11.0

А волшебные печеньки связаны вот этим $DISPLAY:

$ xauth list
remotey.dom.com/unix:11  MIT-MAGIC-COOKIE-1  00f505f4c5731714d30f24a956d4cb8f

Дело в том, что /unix:11. Это волшебный файл cookie для локальной стороны SSH-подключения, а не X11 вашего локального сервера, который обычно был бы :0.

.Xauthority

Это правда, что этот файл содержит эти волшебные куки, но это двоичный файл, и вы обычно взаимодействуете с ним через команду xauth. xauthПодробнее об этом смотрите на странице руководства .

Делаем это вручную

Часто это сообщение появляется, если вы делаете следующее:

$ ssh -X user1@remotey
$ su - user2
$ xclock

X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).

Это потому, что 2-й пользователь .Xauthorityничего не знает о волшебном cookie, который был передан SSH, когда вы вошли в систему изначально. Вы можете сгенерировать xauth addтребуемый файл, пока вы user1, и использовать его как user2, например, так:

$ ssh -X user1@remotey
$ echo $DISPLAY
localhost:10.0

Обратите внимание, что вы находитесь на дисплее # :10.0. Теперь сгенерируйте xauth addтребуемый для этого дисплея #:

$ echo xauth add $(xauth list ${DISPLAY#localhost})
xauth add remotey.dom.com/unix:10 MIT-MAGIC-COOKIE-1 111ef940f6d75b4a9eb64ea3579ef67e

Теперь станьте пользователем user2 и добавьте его:

$ su - user2
$ xauth add remotey.dom.com/unix:10 MIT-MAGIC-COOKIE-1 111ef940f6d75b4a9eb64ea3579ef67e
$ xclock

И мы получаем ожидаемые результаты измерения времени.

ПРИМЕЧАНИЕ:Вы также сможете выполнять действия в одной командной строке, как только поймете, что происходит с вышеизложенным.

используя су 
$ xauth extract - ${DISPLAY#localhost} | \
    su - user2 -c "xauth merge -; xclock"
использовать судо 
$ xauth extract - ${DISPLAY#localhost} | \
    sudo su - user2 -c "xauth merge -; xclock"

Рекомендации

Связанный контент