Desde mi máquina local ssha un servidor remoto junto con la autenticación con respecto a la pantalla X. Sé que en este proceso MIT-MAGIC-COOKIESse utilizan y el valor tanto en el servidor como en el cliente debe ser idéntico para que el proceso de autenticación sea válido.
Sin embargo, cuando inicio sesión en un servidor remoto y confirmo que la pantalla X funciona bien (por ejemplo, ejecutándola xclockpara ver si la xclockaplicación aparece en mi máquina local), cuando verifico el valor de las cookies, el valor en la máquina local y eso en el servidor remoto parece ser diferente. Aquí están las líneas de comando:
valor de la cookie en el 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 de la cookie en la máquina local
chulhyun@chulhyun-Inspiron-3420:~$ xauth list
chulhyun-Inspiron-3420/unix:0 MIT-MAGIC-COOKIE-1 5ddd2ce92004eab53ceee8a64b7b88c0
Como puede ver, el valor de las cookies en dos máquinas es diferente. Entonces, ¿no debería funcionar la pantalla X?
¿Que me estoy perdiendo aqui?
PD: Escuché que $XAUTHORITYcontiene la ruta al xauthorityarchivo y verifiqué esa ruta en la máquina local:
chulhyun@chulhyun-Inspiron-3420:~$ echo $XAUTHORITY
/var/run/gdm/auth-for-chulhyun-iZfH2u/database
Cuando miro el archivo de "base de datos", el contenido es ilegible porque está compuesto de caracteres extraños.
^A^@^@^Vchulhyun-Inspiron-3420^@^A0^@^RMIT-MAGIC-COOKIE-1^@^P]?,? ^D??<??? K{??
¿Podría esto estar relacionado con la pregunta?
actualizar
resultado de xhosty $XAUTHORITYen el servidor remoto
Black@Black-PC ~
$ xhost
access control enabled, only authorized clients can connect
SI:localuser:chulhyun
Black@Black-PC ~
$ echo $XAUTHORITY
*Resulta que $XAUTHORITYno está definido... ¿es esto normal?
resultado de xhosten la máquina local
chulhyun@chulhyun-Inspiron-3420:~$ xhost
access control enabled, only authorized clients can connect
SI:localuser:chulhyun
Respuesta1
Creo que te estás confundiendo sobre cómo SSH realiza el proxy de la conexión X11 a través del túnel que está establecido en el lado del servidor remoto y cómo funcionan normalmente las cookies mágicas. Desde la página de manual de SSH:
extractoThe 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).
Entonces, parecería que las cookies mágicas que se le muestran en el lado del servidor remoto no son en realidad las verdaderas cookies mágicas en el servidor local (su final). Recuerde que la PANTALLA se configura así cuando ingresa por SSH a un servidor remoto:
$ echo $DISPLAY
localhost:11.0
Y las galletas mágicas están conectadas por esto $DISPLAY:
$ xauth list
remotey.dom.com/unix:11 MIT-MAGIC-COOKIE-1 00f505f4c5731714d30f24a956d4cb8f
La noticia es esa /unix:11. Esa es la cookie mágica para el lado local de la conexión SSH, no la X11 de su servidor local, que normalmente sería :0.
.Xautoridad
Es cierto que este archivo contiene esas cookies mágicas, pero es un archivo binario y normalmente interactúas con él mediante el xauthcomando. Consulte xauthla página de manual de para obtener más información sobre esto.
hacerlo manualmente
Muchas veces verás aparecer este mensaje si haces lo siguiente:
$ 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).
Esto se debe a que el segundo usuario .Xauthorityno sabe nada de la cookie mágica que pasó SSH cuando inició sesión inicialmente. Puedes generar lo xauth addrequerido mientras eres usuario1 y usarlo como usuario2 de esta manera:
$ ssh -X user1@remotey
$ echo $DISPLAY
localhost:10.0
Observe arriba que está en la pantalla # :10.0. Ahora genere lo xauth addrequerido para ese número de pantalla:
$ echo xauth add $(xauth list ${DISPLAY#localhost})
xauth add remotey.dom.com/unix:10 MIT-MAGIC-COOKIE-1 111ef940f6d75b4a9eb64ea3579ef67e
Ahora conviértete en usuario2 y agrégalo:
$ su - user2
$ xauth add remotey.dom.com/unix:10 MIT-MAGIC-COOKIE-1 111ef940f6d75b4a9eb64ea3579ef67e
$ xclock
Y obtenemos el cronometraje como se esperaba.
NOTA:También puedes hacer cosas en una sola línea de comando una vez que hayas comprendido lo que sucede con lo anterior.
usando su$ xauth extract - ${DISPLAY#localhost} | \
su - user2 -c "xauth merge -; xclock"
$ xauth extract - ${DISPLAY#localhost} | \
sudo su - user2 -c "xauth merge -; xclock"