Respect my ~/.Xauthority !#@$!

South Park is a hilarious show, and I think that Cartman is the best character.  One of Cartman’s classic lines is “YOU WILL RESPECT MY AUTHORITAH!#!”

So Cartman wasn’t a unix geek and wasn’t talking about X11 Forwarding / SSH, but maybe there is a moral to the story.

You have to execute some sort of GUI program on a remote host and it requires root access in order to execute (or you have to change to a different user to execute the GUI with correct permissions)… 

At first, when you logged into the machine for the first time without X11 forwarding enabled, your ~/.Xauthority file doesn’t exist…

cartman@locutus:~$ ls -l ~/.Xauthority
ls: /home/cartman/.Xauthority: No such file or directory

So you log back out, and when you ssh back into the remote machine, you remember to forward X11 by issuing..

$ ssh -X <user>@<remote box>


$ ssh -X cartman@locutus
Linux locutus 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686
cartman@locutus:~$ xclock

Sure enough, you fire up /usr/bin/xclock (or /usr/openwin/bin/xclock) and verify that the GUI program displays back on your local desktop.  

cartman@locutus:~$ echo $DISPLAY

Sweet.  Next, when you change users..

cartman@locutus:~$ su –

root@locutus:~# id
uid=0(root) gid=0(root) groups=0(root)

root@locutus:~# xclock
Error: Can’t open display:


you loose your X11 forwarding.  DOH!

So whats the solution here?  You can’t log in directly to the box as the root user (this should always be disabled.  Its really bad practice if it isn’t) — and you don’t really want to throw a SSH key into /root/.ssh/authorized_keys for obvious reasons — so what’s there to do?

When you SSH into a machine with X11 forwarding, it opens a TCP port, tunnels it through SSHD, and stores this information into a MIT cookie file in your home directory called ~/.Xauthority

All we have to do is “move” this information along with us when we change users.  We can use the xauth command to manipulate this for us.  First, lets display what the value of our cookie is.  Note the :10 matching up to our $DISPLAY variable…

cartman@locutus:~$ xauth list
locutus/unix:10  MIT-MAGIC-COOKIE-1  e2cba22d040f0e75dcbd203ee40736de

Now lets change users..

cartman@locutus:~$ su –

root@locutus:~# ls -l /root/.Xauthority
ls: /root/.Xauthority: No such file or directory

root@locutus:~# xauth list

So no MIT cookies currently exist… That makes sense because we didn’t X11 port forward into the root account.. Lets add one.  Don’t forget the “/unix” after the FQDN..
root@locutus:~# xauth add locutus/unix:10 MIT-MAGIC-COOKIE-1

xauth:  creating new authority file /root/.Xauthority

root@locutus:~# xauth list
localhost/unix:10  MIT-MAGIC-COOKIE-1  e2cba22d040f0e75dcbd203ee40736de

We’re not done yet… The last thing we have to do is to set our $DISPLAY variable to the same display as above..  Right now it may be set to null…

root@locutus:~# echo $DISPLAY

root@locutus:~# xclock
Error: Can’t open display:

So lets set it to localhost:10.0

root@locutus:~# export DISPLAY=localhost:10
root@locutus:~# xclock

Sure enough, we get xclock to display.  We didn’t have to be the root user in this example.  Any local user could perform the same function.

Alternativly, xauth also has a “merge” function to where you can read an existing ~/<user/.Xauthority file to merge with another.  This really is only going to work for the root user (unless you chmod) because the permissions on this file is octal 600…

root@locutus:~# ls -l /home/cartman/.Xauthority
-rw——- 1 cartman cartman 53 2008-04-05 00:22 /home/cartman/.Xauthority

Lets remove the previous Xauthority we had in place…

root@locutus:~# xauth list
locutus/unix:10  MIT-MAGIC-COOKIE-1  e2cba22d040f0e75dcbd203ee40736de

root@locutus:~# xauth remove locutus/unix:10


And then we’ll use the merge function pointing at a specific .Xauthority file…
root@locutus:~# xauth merge /home/cartman/.Xauthority

Sure enough, it imported correctly..

root@locutus:~# xauth list
locutus/unix:10  MIT-MAGIC-COOKIE-1  e2cba22d040f0e75dcbd203ee40736de

Our DISPLAY variable matches the display above and xclock starts up without any errors.
root@locutus:~# echo $DISPLAY
root@locutus:~# xclock


When xauth is invoked without any options, it brings up a menu based configuration utility thats pretty neat… Here’s “xauth info” in action…

root@locutus:~# xauth
Using authority file /root/.Xauthority
xauth> help
    add dpyname protoname hexkey   add entry
    exit                           save changes and exit program
    extract filename dpyname…    extract entries into file
    help [topic]                   print help
    info                           print information about entries
    list [dpyname…]              list entries
    merge filename…              merge entries from files
    nextract filename dpyname…   numerically extract entries
    nlist [dpyname…]             numerically list entries
    nmerge filename…             numerically merge entries
    quit                           abort changes and exit program
    remove dpyname…              remove entries
    source filename                read commands from file
    ?                              list available commands
    generate dpyname protoname [options]  use server to generate entry
    options are:
      timeout n    authorization expiration time in seconds
      trusted      clients using this entry are trusted
      untrusted    clients using this entry are untrusted
      group n      clients using this entry belong to application group n
      data hexkey  auth protocol specific data needed to generate the entry

xauth> info
Authority file:       /root/.Xauthority
File new:             no
File locked:          no
Number of entries:    1
Changes honored:      yes
Changes made:         no
Current input:        (stdin):2

There are also all sorts of security implecations surrounding ~/.Xauthority where the root user or administrator could hijack X11 sessions.  This article is a great read and I suggest taking a look at it when you have a chance.  It also goes into better detail on the steps of how the X11 forward occurs and security hazards surrounding it.


8 thoughts on “Respect my ~/.Xauthority !#@$!”

  1. Thanks! I’ve often wondered how to do this, but never seen it done before.

    As a side note, while I am a bit of a sudo nazi, if managed correctly, I think having root ssh keys is not a bad thing. So long as the ssh keys are password protected, centrally managed and associated with a person, and all commands are logged and associated with that person, and the hosts are only available internally, it’s not a terrible compromise. That’s an awful lot of ifs, but it’s handy for recovering hosed machines.

    I’ll still prefer sudo, myself.

  2. Lawina: Yes, this will work with pretty much any unix or linux O/S that supports ssh. There are a few different variants of clients that used -Y to initiate a X11 session instead of -X

    I’m waiting for Google’s android linux based phone to be released. It would be really cool to ssh into your mobile device and fire up GUI applications.

    On Windows, putty supports X11 forwarding in the configuration tab. Google on where to find it.

    Unfortunatly, windows doesn’t have a native embedded X server so you have to run a 3rd party application like hummingbird exceed. Cgywin also has a X server and its free.

  3. Thanks a lot for this helpful post!

    I put your info into a single change-user-command so you do not have to repeat the whole process of finding the MIT cookie and adding it as the other user.
    This works fine for me:

    su username -c “xauth add ${HOSTNAME}/unix:${DISPLAY//[a-zA-Z:_-]/} $(xauth list | grep -o ‘[a-zA-Z0-9_-]*\ *[0-9a-zA-Z]*$’); bash”

Leave a Reply

Your email address will not be published. Required fields are marked *