x11 соединение установлено, но значение magic-cookie отличается?

4

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

Тем не менее, когда я вхожу на удаленный сервер и подтверждаю, что X-дисплей работает хорошо (например, выполняется, 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?

Что мне здесь не хватает?

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

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

Когда я заглядываю в файл «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
kwagjj
источник
Что за пульт $XAUTHORITY? Каков выход xhostна обоих серверах?
LatinSuD
@LatinSuD Я обновил вопрос с результатами, которые вы хотели ... он, кажется, не предлагает ничего дальше, хотя ... что вы думаете?
kwagjj
@kawajj Может быть из-за авторизации xhost. Если вы хотите поэкспериментировать, попробуйте это на xhost -SI:localuser:chulhyun
своем
@LatinSuD хм .. я сделал то, что вы предложили, и все, что он говорит, localuser:chulhyun being removed from access control listно все равно X display с удаленным сервером работает .. что в любом случае должна означать командная строка?
kwagjj
xhost - это альтернативный способ авторизации клиентов, обычно основанный на хосте, с которого приходит клиент. Я думал, что это могло бы авторизовать все ваши процессы на сервере.
LatinSuD

Ответы:

5

Я полагаю, что вас смущает то, как 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. Это волшебное печенье для локальной стороны SSH-соединения, а не X11 вашего локального сервера, как это обычно бывает :0.

.Xauthority

Это правда, что этот файл содержит эти волшебные куки, но это двоичный файл, и вы обычно взаимодействуете с ним с помощью xauthкоманды. Смотрите xauthman-страницу для более подробной информации.

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

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

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

Это связано с тем, что второй пользователь .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"
использовать sudo
$ xauth extract - ${DISPLAY#localhost} | \
    sudo su - user2 -c "xauth merge -; xclock"

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

SLM
источник
извините за поздний выбор. спасибо за отличный ответ! помогает понять больше о X-материале
kwagjj