X Forwarding with SSH and Sudo

Information: If you don't know what X, ssh, or sudo are then this document is probably not for you.  
Caveats: There are many ways to skin the proverbial cat.  One of the reasons I like Unix/Linux so much is that this ability is always present.  My solution may not match your solution, but both work just as well.
Warning:  Use these steps at your own risk!  I tend to clean as I go, so see little risk from taking the steps defined below.  Most people don't, and being lazy and careless can cause huge problems.

This "problem" is really not a problem once all the parts are put together in the right order.  Knowing the parts is like knowing the shape of the piece.  I have seen several documents on "how to configure" this, but nothing in one place that really explains what's going on.  I'm not going to be very techie with most of this, just summary.  There are lots of technical details about all the parts written and probably much better than I could write them.

X clients look for a $HOME/.Xauthority file for information.  This file is made for each new session, generally created and managed by the X server.  When we ssh -X to a host, we have no X server running.  What happens without any technical details is that sshd creates the file for us, and proxies X services through a tunnel within the ssh session.  So without attaching to graphics (X) we still have the ability to launch graphical applications.

Now, it's important to remember that the $HOME/.Xauthority is not just a pointer to the display.  There is also information in the file for security including session information. A good handy fact is that when sshd creates the file, the permission is set to 0600.

It's also important to note that $HOME/.Xauthority can be be something of a different name or location.  This is controlled  by a variable "XAUTHORITY".  For now, we only need to know that the variable is not set by default, but it can be.  What I'll show in a bit is how to use this so that you can sudo to a new account and maintain your X client abilities.

Lets say I need to ssh to a server, and run a graphical installer.  This is pretty common now days, Unix isn't all command line any more.

% ssh -X -l johndoe myserver.mydomain.com

After I'm on the console, I should be able to launch "xterm" for example and bring the display back to myself (assuming I have an X server running and allowing connections from myserver.mydomain.com.)

What happens if I need to sudo to a different account and run an xterm (given I could just run the installer, but for testing xterm is a bit lighter weight).

% sudo /bin/su - dbadmin
% xterm


Best case, I'll see an error that I have an invalid cookie "Invalid MIT_MAGIC_COOKIE" something, which means I have a ~dbadmin/.Xauthority file, but it's not correct.  Worst case, I'll see a slightly different error that I have no X server defined.  Either way, I can't launch my installer.

If I was to run strace or truss on the xterm command, I would eventually find that the problem is with my ~/.Xauthority file.  A lot of people at this time start cursing sshd or sudo thinking that they are the problem.

First things first.  Lets make sure sudo is functional.  Are we passing a DISPLAY and XAUTHORITY variable?  Are both variables being set as our initial connection?

% echo $DISPLAY
 localhost:140:0
% echo $XAUTHORITY


Well, you see that we have no XAUTHORITY being set.  In order for the dbadmin account to use johndoe's X pipe, they will need to have that set and accessable.

Add this to johndoes .bashrc or what ever equivalent log in file and language.  Now, we also need to make sure that both johndoe and dbadmin are in the same primary group.  This is important because we don't want any schmuck to send DISPLAY to your monitor.

XAUTHORITY="$HOME/.XAUTHORITY"
if [ -f $XAUTHORITY ] ; then
   chmod 640 $XAUTHORITY
else
   touch $XAUTHORITY
   chmod 640 $XAUTHORITY
fi
export XAUTHORITY

So now, johndoe has the variable set and exported (that part is important).  We have also given group read access to the file, which is more important.

Log in as johndoe again, and make sure you can see both variables.
% echo $DISPLAY ; echo $XAUTHORITY

localhost:140.0
/home/johndoe/.Xauthority

Good so far, so lets sudo to our database admin account and see if we have both.
% sudo /bin/su - dbadmin
% echo $DISPLAY ; echo $XAUHORITY
localhost:140.0


Uh oh, we have no Xauthority file.  X clients will still fail.  The problem is with a PAM module that tries to set up the xauthority for the user when they su.  I'm sure I could monkey with it and make it work, but right now I just need my dbadmin installer to run.  Comment out the entry for pam_xauth.so in /etc/pam.d/su.

So exit, and sudo back to dbadmin and you should see both entries.  If you can, make sure you can read the $XAUTHORITY file.

% strings $XAUTHORITY

If is shows you a bunch of text that you don't understand, you are ready to go.  If it errors, see where your permission setting went wrong or.. double check that group ownership is proper.. and that your primary group for both users match.

When all that works, so will your X clients.

As a final warning, there is nothing secure about graphics.  Keeping default permission on files is much better than manipulating things to make them work.  The above steps are only a way of hacking something to make it work as I needed it to work.  Use at your own risk!