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
/var/run/gdm/auth-for-chulhyun-iZfH2u/database
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?
update
result of xhost
and $XAUTHORITY
in remote server
Black@Black-PC ~
$ xhost
access control enabled, only authorized clients can connect
SI:localuser:chulhyun
Black@Black-PC ~
$ echo $XAUTHORITY
*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
SI:localuser:chulhyun
Best Answer
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:
excerptSo 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:
And the magic cookies are connected by this
$DISPLAY
: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
..Xauthority
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. Seexauth
's man page for more on this.Doing it manually
Often times you'll see this message show up if you do the following:
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 thexauth add
required while you're user1 and make use of it as user2 like so:Notice above that you're on display #
:10.0
. Now generate thexauth add
required for that display #:Now become user2 and add it:
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 use sudoReferences