How do I get Xwindows to work when I am using an encrypted Drive?

My friend Mike Jansen pinged me this afternoon with an interesting problem.  

Here is the background:

He has setup a Linux VM and needs to get to it remotely from his PC running Windows.  He has xming(A great free XWindows server for Windows) and connects to the machine over SSH.  He decided he would take security to the next level and encrypted his personal directory.  Interesting fact is that when you do this on Ubuntu your home directory isn’t decrypted or mounted until you actually login.  Why is that a problem?  Well as part of the login process SSH puts the magic-coookie XWindows needs to start into your /home/<UserID>/.Xauthority file.  The next thing that happens is that your encrypted directory is decrypted and mounted to /home/<UserID>/ which then hides /home/<UserID>/.Xauthority under the mount.  At that point it breaks X and stops you from running the XWindows Programs.  Unless you do something like what Mike pieced together.  What Mike has below should work system wide for all users.  You should as with all scripts test this out on a non-production system first.

Here is what he gave back to be to post to for everyone:

So I got my issue with encrypted home and ssh/xauth figured out. The solution is actually simple once it’s figured out 🙂

The basic idea for xauth transfer was from


The idea for this came from the man page for SSH. 

I got rid of ~/.ssh/rc and put this in /etc/ssh/sshrc:

if read proto cookie && [ -n "$DISPLAY" ]; then
if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
# X11UseLocalhost=yes
echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie
# X11UseLocalhost=no
echo add $DISPLAY $proto $cookie
fi | xauth -q -
MYXAUTH=/home/.ecryptfs/`id -un`/.xauth
xauth list > $MYXAUTH
chmod go-r $MYXAUTH

Mount encrypted home

The idea’s behind this section came from this page

In /etc/profile, I mount encrypted home (if it’s not already mounted):

if test -e $HOME/.ecryptfs/auto-mount; then
mount | grep "$HOME type ecryptfs"
if test $? != 0; then


I got rid of ~/.bash_login and put this in /etc/bash.bashrc:

# Load xauth information from pre-encrypt mounting ssh initialiation
MYXAUTH=/home/.ecryptfs/`id -un`/.xauth
if [ -e "$MYXAUTH" ]; then
xauth add `cat $MYXAUTH`

Sample SSH LOGIN after Implementation

Here’s what my ssh login looks like now (I have a bunch of outputs to understand the flow and make sure my real and effective uid’s are what I expect):

Using username "mike-jansen".
Authenticating with public key "REALLY_COOL_DEV_SERVER" from agent
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-11-generic-pae i686)

* Documentation:

56 packages can be updated.
29 updates are security updates.

Last login: Thu Sep 22 15:48:24 2011 from
------ BEGIN /etc/ssh/sshrc Real [mike-jansen] Effective [mike-jansen]
------ END /etc/ssh/sshrc Real [mike-jansen] Effective [mike-jansen]
------ BEGIN /etc/profile Real [mike-jansen] Effective [mike-jansen]
Enter your login passphrase:
Inserted auth tok with sig [c46ead8832a353d7] into the user session keyring

INFO: Your private directory has been mounted.
INFO: To see this change in your current shell:
cd /home/mike-jansen

------ BEGIN /etc/bash.bashrc Real [mike-jansen] Effective [mike-jansen]
------ END /etc/bash.bashrc Real [mike-jansen] Effective [mike-jansen]
------ END /etc/profile Real [mike-jansen] Effective [mike-jansen]
------ BEGIN ~/.profile Real [mike-jansen] Effective [mike-jansen]
------ BEGIN ~/.bashrc Real [mike-jansen] Effective [mike-jansen]
------ END ~/.bashrc Real [mike-jansen] Effective [mike-jansen]
------ END ~/.profile Real [mike-jansen] Effective [mike-jansen]




*For those who don't know ~ is a shortcut to the current users home directory as recorded in the user repoistory for the system.







Automation – Can to much of a good thing be bad?

Senior  systems administrators on any platform know that automation is the  single fastest way to improve the effectiveness of their team.  Scripts  provide stability, repeatability and reduce the time spent on often  repeated tasks.  If done correctly, automation will make everything more  stable and manageable.  

However,  scripts for managing systems can be a double edged sword.  On one hand,  they make a team highly efficient.  They can help junior admins perform  far above their experience level and free senior admins up to  investigate more difficult problems.  On the other hand though, they can  lead to a loss of knowledge.  The knowledge it took to create the  scripts becomes locked inside of them.  So what do you do to strike the  proper balance?  How can you keep the knowledge fresh in every-one’s  mind while still automating?  What steps can be taken to avoid knowledge  erosion and worse the brain drain or vacuum that is left when people  leave?

The  first thing to remember is that there is no one thing that can be done  to answer these questions.  Here we will provide you with some tips and  ideas we have found to be useful and effective.  This is a short list  and we hope that it will inspire you to think about what might work for  you and your company. 

The  first item is well documented scripts and procedures.  Taking 5 minutes  to write up what you were thinking when you wrote the script can save  you days trying to figure it out later.  As more object oriented  scripting languages like Python, Ruby and Perl take hold, it becomes  easier to break down complex scripts into much easier and digestable  chunks.  These smaller chunks, like the core ideas behind Linux, should  do one thing and do it well.  The names of the functions should describe  what they do.  For instance, a function called createNewSSHKeys, should  probably create new SSH keys.  This combined with an explanation of  what you were trying to do inside the function will help you and others  manage them.  When you get really good at this way of thinking, people  should be able to take your function calls out and write a manual  procedure that could replace your automation.  If that is your goal,  then it only makes sense that starting with a well documented procedure  to compare against when your done scripting makes sense.  It is unlikely  that every procedure step will match a function or series of function  calls.  Getting everything close does count though.

As  much as self documenting scripts helps though,  documenting  configuration files for your scripts can keep things fresh in peoples  mind.  At the very least, if done correctly, it will give them a  breadcrumb trail to follow to see if what they think is being set is  set.  We recently began testing out Puppet, an automated way to manage  server configuration files and other admin related tasks.  The  configuration files for Puppet can be used as a great example.  They  allow you to use a combination of intelligent names and comments to  inform the person reading the file what will be changed.  They also  include a description of where to look to verify that the changes are  being done correctly.  This means that I don’t need to know Ruby, the  language Puppet is written in, to figure out how or what its going to  do.  The configuration file itself tells me everything I need to know.   When you write your own script, the time it takes to do this may not be  warranted.  So at the very least, make sure that you have comments that  tell people where to look for the output based on these configurations  or what the configurations mean in the file.

Try  to keep everyone with the sharp skills needed so they are ready to  slice through problems as they arise. This also means internal training.   One of the things we have participated in on a regular basis is a  short one hour refresher put on by the subject matter experts(SME) for  each of the technologies we use.  Doing this accomplishes a few  different things at once.  It helps the SME keep their documentation  current.  It gives the SME an opportunity to share changes they want to  make or have made in the environment.  Then it gives everyone supporting  the environment a chance to ask questions about the technology when  there is no pressure.  When possible, annual reviews of each area that a  team supports, goes a long way towards elevating the teams ability to  be as productive as possible.

While  you can never completely prevent brain drain when a team member leaves,  the steps above, if done correctly, can go a long way.  Having been the  person transitioned to more than once, the better these steps are  followed, the better we have felt about taking on the responsibility.   Another side effect of these approaches and others along the same  thought process is that it allows people to migrate from one SME area to  another.  This helps people stay fresh and keeps them from becoming  bored and complaisant.  The more driven your team is to solve businesses  problems, the more profitable you will be.