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:
excerpt
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
localhost:11.0
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
.
.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. 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
localhost:10.0
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"
References
Second case is very useful in situation when example.com can connect to [google.com] host while your box can't.
For example, you have VPN connection which is restricted to a number of boxes, while you want to access host not in list.
ssh -L 123:target.host.com:456 user@vpn.host.com.
So, basic usage is to jump INSIDE the network or jump OUTSIDE the network (ssh to some kind of proxy/gateway).
And finally, there may be firewall restrictions on target server which accepts connections only from given hosts.
Best Answer
When you connect to a remove machine via ssh with X11 forwarding enabled, ssh on the server creates a
.Xauthority
file in the user's home directory. Because ssh listens for X11 on a TCP socket, anyone can connect. Because anyone can connect, we need some way of preventing just anyone from using your display. This is done with that.Xauthority
file. The file contains a "cookie" which is presented to the X11 server that verifies the client should be allowed to connect.Skipping all the details, if you copy that
.Xauthority
file to your target user's home directory (and give them ownership), you should be able to connect.