From my local machine I ssh to a remote server along with authentication regarding X display. I know that in this process, MIT-MAGIC-COOKIES are used and the value in both server and client needs to be identical in order for the authentication process to be valid.

However, when I login to a remote server and have confirmed that X display stuff are working well (e.g. executing xclock to see if the xclock application is popped up in my local machine), when I check the value of the cookies, the value in local machine and that in the remote server seems to be different. Here's the command lines:

cookie value in remote server

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 value in local machine

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

As you can see the cookie value in two machines are different. Then shouldn't the X display not work?

What am I missing here?

P.S. I heard that $XAUTHORITY contains the path to the xauthority file and I've checked that path in local machine:

chulhyun@chulhyun-Inspiron-3420:~$ echo $XAUTHORITY

When I take a look into the "database" file, the contents are unreadable because the contents are composed of weird characters.

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

could this be related to the question?


result of xhost and $XAUTHORITY in remote server

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

Black@Black-PC ~

*as it turns out $XAUTHORITY is not defined... is this normal?

result of xhost in local machine

chulhyun@chulhyun-Inspiron-3420:~$ xhost
access control enabled, only authorized clients can connect
  • What's the remote $XAUTHORITY? What's the output of xhost in both servers? – LatinSuD Jun 25 '14 at 11:18
  • @LatinSuD I've updated the question with the results you wanted... it doesn't seem to suggest anything much further though... what do you reckon? – kwagjj Jun 25 '14 at 11:58
  • @kawajj Might be because of xhost authorization. If you want to experiment try this on you local host: xhost -SI:localuser:chulhyun – LatinSuD Jun 25 '14 at 12:01
  • @LatinSuD hmm.. I've done what you suggested and all it says is localuser:chulhyun being removed from access control list but still X display with remote server works.. what does the command line supposed to mean anyway? – kwagjj Jun 25 '14 at 12:06
  • xhost is an alternative way of authorizing clients normally based on the host the client comes from. I thought it could have been authorizing all your processes to the server. – LatinSuD Jun 25 '14 at 12:08

I believe you're getting confused by how SSH performs the proxying of the X11 connection via the tunnel it's established on the remote server side with how magic cookies typically works. From the SSH man page:

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

So it would seem the magic cookies being shown to you on the remote server side are not in fact the true magic cookies on the local server (your end). Remember that the DISPLAY is being set like so when you SSH into a remote server:

$ echo $DISPLAY

And the magic cookies are connected by this $DISPLAY:

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

The tell is that /unix:11. That's the magic cookie for the local side of the SSH connection, not your local server's X11, which would typically be :0.


It's true that this file contains that magic cookies, but it's a binary file and you do typically interact with it via the xauth command. See xauth's man page for more on this.

Doing it manually

Often times you'll see this message show up if you do the following:

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

This is because the 2nd user's .Xauthority knows nothing of the magic cookie that was passed by SSH when you logged in initially. You can generate the xauth add required while you're user1 and make use of it as user2 like so:

$ ssh -X user1@remotey
$ echo $DISPLAY

Notice above that you're on display # :10.0. Now generate the xauth add required for that display #:

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

Now become user2 and add it:

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

And we get the clocking showing as expected.

NOTE: You can also do things in a single command line once you've grasped what's going on with the above.

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


  • sorry for late selection. thanks for a great answer! helps to understand more about the X-stuff – kwagjj Feb 10 '15 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.