Eu acredito que você está ficando confuso com a forma como o SSH realiza o proxy da conexão X11 através do encapsulamento que é estabelecido no lado do servidor remoto com a forma como os cookies mágicos normalmente funcionam. Da página de manual do SSH:
trechoThe 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).
Então, parece que os cookies mágicos mostrados a você no lado do servidor remoto não são de fato os verdadeiros cookies mágicos no servidor local (o seu final). Lembre-se que o visor está sendo definido assim quando você SSH em um servidor remoto:
$ echo $DISPLAY
localhost:11.0
E os cookies mágicos estão conectados por este $DISPLAY :
$ xauth list
remotey.dom.com/unix:11 MIT-MAGIC-COOKIE-1 00f505f4c5731714d30f24a956d4cb8f
A conta é que /unix:11 . Esse é o magic cookie para o lado local da conexão SSH, não o X11 do seu servidor local, que normalmente seria :0 .
.Xauthority
É verdade que esse arquivo contém esses cookies mágicos, mas é um arquivo binário e você geralmente interage com ele por meio do comando xauth . Veja a página de manual de xauth para saber mais sobre isso.
Fazendo isso manualmente
Muitas vezes você verá essa 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 .Xauthority não sabe nada sobre o cookie mágico que foi passado pelo SSH quando você efetuou login inicialmente. Você pode gerar o xauth add necessário enquanto você é usuário1 e usá-lo como user2 assim:
$ ssh -X user1@remotey
$ echo $DISPLAY
localhost:10.0
Observe acima que você está em exibição # :10.0 . Agora gere o xauth add necessário para essa exibição #:
$ 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 temos a exibição do relógio conforme o esperado.
OBSERVAÇÃO: Você também pode fazer coisas em uma única linha de comando depois de entender o que está acontecendo com o acima.
usando su$ xauth extract - ${DISPLAY#localhost} | \
su - user2 -c "xauth merge -; xclock"
$ xauth extract - ${DISPLAY#localhost} | \
sudo su - user2 -c "xauth merge -; xclock"