☰

atualizar

tag-icon • tag-icon x11 ssh-tunneling xforwarding xauth
atualizar

Da minha máquina local I sshpara um servidor remoto junto com a autenticação referente à exibição do X. Eu sei que neste processo MIT-MAGIC-COOKIESsão usados ​​e o valor tanto no servidor quanto no cliente precisa ser idêntico para que o processo de autenticação seja válido.

No entanto, quando eu faço login em um servidor remoto e confirmo que o material de exibição do X está funcionando bem (por exemplo, executando xclockpara ver se o xclockaplicativo aparece na minha máquina local), quando verifico o valor dos cookies, o valor na máquina local e isso no servidor remoto parece ser diferente. Aqui estão as linhas de comando:

valor do cookie no servidor remoto

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

valor do cookie na máquina local

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

Como você pode ver, o valor do cookie em duas máquinas é diferente. Então o display X não deveria funcionar?

O que estou perdendo aqui?

PS Ouvi dizer que $XAUTHORITYcontém o caminho para o xauthorityarquivo e verifiquei esse caminho na máquina local:

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

Quando dou uma olhada no arquivo "banco de dados", o conteúdo fica ilegível porque é composto de caracteres estranhos.

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

isso poderia estar relacionado à pergunta?

atualizar

resultado de xhoste $XAUTHORITYno servidor remoto

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

Black@Black-PC ~
$ echo $XAUTHORITY

*Acontece que $XAUTHORITYnão está definido... isso é normal?

resultado de xhostna máquina local

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

Responder1

Acredito que você esteja confuso sobre como o SSH executa o proxy da conexão X11 por meio do túnel estabelecido no lado do servidor remoto e como os cookies mágicos normalmente funcionam. Na página de manual do SSH:

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

Portanto, parece que os cookies mágicos mostrados a você no servidor remoto não são de fato os verdadeiros cookies mágicos no servidor local (sua extremidade). Lembre-se de que o DISPLAY está sendo definido assim quando você usa SSH em um servidor remoto:

$ echo $DISPLAY
localhost:11.0

E os cookies mágicos estão conectados por isto $DISPLAY:

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

A dica é essa /unix:11. Esse é o cookie mágico para o lado local da conexão SSH, não para o X11 do seu servidor local, que normalmente seria :0.

.Xautoridade

É verdade que este arquivo contém cookies mágicos, mas é um arquivo binário e você normalmente interage com ele por meio do xauthcomando. Consulte xautha página de manual do para obter mais informações sobre isso.

Fazendo isso manualmente

Muitas vezes você verá esta mensagem aparecer se fizer o seguinte:

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

Isso ocorre porque o segundo usuário .Xauthoritynão sabe nada sobre o cookie mágico que foi passado pelo SSH quando você efetuou login inicialmente. Você pode gerar o xauth addnecessário enquanto for usuário1 e usá-lo como usuário2 assim:

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

Observe acima que você está no display # :10.0. Agora gere o número xauth addnecessário para esse display:

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

Agora torne-se usuário2 e adicione-o:

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

E obtemos o relógio exibido conforme o esperado.

OBSERVAÇÃO:Você também pode fazer coisas em uma única linha de comando depois de entender o que está acontecendo acima.

usando su 
$ xauth extract - ${DISPLAY#localhost} | \
    su - user2 -c "xauth merge -; xclock"
usar sudo 
$ xauth extract - ${DISPLAY#localhost} | \
    sudo su - user2 -c "xauth merge -; xclock"

Referências

informação relacionada