Wednesday, June 3, 2009

Migrating to an Encrypted Home Directory



UPDATE (2011-02-15): These manual instructions are no longer required, however, they may prove useful if you need to deviate from the norm.  You can now use the ecryptfs-migrate-home command.


Howdy!

Many eCryptfs and Ubuntu Jaunty users have requested instructions on migrating their existing, non-encrypted home directories to an Encrypted-Home setup. I have some instructions for you now!

Prerequisites

  1. Make a complete backup copy of your non-encrypted data to another system or external media. Some of the following instructions are dangerous, could result in data lost, or lock you out of your system! Please read and follow all instructions very carefully.
  2. Make sure you have sufficient disk space available. To make a full copy, you will need at least 2x the disk usage of your current home directory. Assuming the copy succeeds and you have access to your encrypted data, you can recover some space by deleting the unencrypted data.
    du -sh $HOME
    df -h $HOME
    
  3. You must have administrator (sudo) privileges.
  4. You should install ecryptfs-utils
    sudo apt-get install ecryptfs-utils
    

  5. These instructions require an empty $HOME/Private directory. If you already have some data in your $HOME/Private directory, please move all of these files and directories out of the way, and follow the instructions in:
    ecryptfs-setup-private --undo
    

Instructions


Exit all desktop sessions. You need to ensure that there are no other processes on your system reading and/or writing data in your home directory. Perform all of the following instructions by logging in via SSH or at a tty terminal (ctrl-alt-F1).

Login and setup an Encrypted Private directory:
login
ecryptfs-setup-private


Logout, and log back in and make sure $HOME/Private is mounted.
exit
login
mount | grep "$USER.*ecryptfs"


Use rsync to copy all data from your home directory to your new Encrypted Private directory. If you have a large home directory, this step might take a very long time. Be very wary of any errors at this point. This is the most essential step in this migration scheme. I usually re-run this step 3 times.
rsync -aP --exclude=.Private --exclude=Private \
--exclude=.ecryptfs $HOME/ $HOME/Private/


Sync to disk, unmount, logout, and log back in.
sync && sync && sync
ecryptfs-umount-private
exit
login


Setup your eCryptfs configuration directory.
ecryptfs-umount-private
cd /
sudo mkdir -p /home/.ecryptfs/$USER
sudo chown $USER:$USER /home/.ecryptfs/$USER
mv $HOME/.ecryptfs /home/.ecryptfs/$USER/
mv $HOME/.Private /home/.ecryptfs/$USER/
sudo chmod 700 /home/.ecryptfs/$USER/.Private
sudo chmod 700 /home/.ecryptfs/$USER/.ecryptfs


Setup your new, unmounted home directory.
sudo mkdir -p -m 700 /home/$USER.new
sudo chown $USER:$USER /home/$USER.new
ln -sf /home/.ecryptfs/$USER/.ecryptfs \
/home/$USER.new/.ecryptfs
ln -sf /home/.ecryptfs/$USER/.Private \
/home/$USER.new/.Private


Move your old, unencrypted home directory out of the way.
sudo mv $HOME $HOME.old


"Activate" your new, unmounted home directory by renaming it.
sudo mv /home/$USER.new $HOME
echo $HOME > $HOME/.ecryptfs/Private.mnt
ln -sf \
/usr/share/ecryptfs-utils/ecryptfs-mount-private.txt \
$HOME/README.txt
sudo chmod 500 $HOME


Logout, and log back in. Ensure that $HOME is mounted, and that you have a symlink to your configuration directory.
exit
login
mount | grep "$USER.*ecryptfs"
ln -sf /home/.ecryptfs/$USER/.ecryptfs \
/home/$USER/.ecryptfs
ln -sf /home/.ecryptfs/$USER/.Private \
/home/$USER/.Private


Check all of your home directory data. Ensure that everything is in order. Once you are completely confident that the migration worked, you can reclaim some disk space by removing your old, non-encrypted data.
sudo rm -rf $HOME.old


Notes



If you are a shred-minded-individual, you will need to backup your cleartext data, shred your disk, and reinstall from scratch.

:-Dustin

26 comments:

  1. I follow your blog because encrypting ~ is important to me. As a bike commuter, I also try to maintain a system at home that mirrors the work files on my laptop at work, so I can telecommute from time to time.

    Currently I am using Unison to painlessly keep my local files in-sync between my two computers.

    Here's my question. If I encrypt my home directory on the laptop, will the sync performed by unison (which is nothing more than a fancy rsync) also be encrypted? If so, is there sane way to mirror the encryption set up between the two machines.

    I'm interested, but I really value my ability to move data back and forth, but would like to have an encrypted hard drive when I'm flying/traveling for work.

    I'm interested in your thoughts.

    ReplyDelete
  2. Thanks for these instructions.
    Everything went well except one thing:

    When done, a copy all the folders of my home directory also appears in the $HOME/Private folder! I assume these folders can be safely removed?

    ReplyDelete
  3. shred is a good idea, if you are paranoid (I am). Even paranoids *do* have enemies...

    Just two details on shred (on Jaunty it is version 6.10 (i.e., coreutils 6.10):

    (1) this version still performs, by default, 20+ iteractions on the file (or disk); each iteraction writes a specific bitmask, out of a pool of possible bitmasks;

    (2) at the beginning, middle, and the end of the iteractions a "random" pass is performed. This random pass reads from /dev/urandom, and writes over the file.

    The issues here are:

    (a) 20+ passes are now considered excessive; a consensus has been reached that 2 (even perhaps one!) passes would be enough (shred 7.3, onwards now defaults to 3 passes);
    (b) shred uses /dev/urandom! This is the critical issue, in fact: if you are shredding a small file (a few MB, at most) this is no big impact. But mass-shredding, or shredding a very large file (or disk) causes the system random pool to be deplected. The immediate consequence is a *much* longer wait to receive data from /dev/urandom (e.g., https://bugs.edge.launchpad.net/ubuntu/+source/coreutils/+bug/279598).

    (c) if you just reduce the number of passes (via the -n parameter), random passes will still be inserted.

    So... the best way is to call shred with the --random-source parameter. I usually run it with /dev/zero as the source, but a pipe could also be used:

    shred -n5 --random-source=/dev/zero file1

    ReplyDelete
  4. Andy-

    I'm not familiar with "Unison", but I do use rsync to backup my encrypted data on a daily basis.

    Your encrypted data actually exists in a .Private directory in your unmounted home directory.

    To access this, I do the following (which I'm suggesting we do something like this for Karmic):

    sudo mkdir /.home
    echo /home /.home none ro,bind

    And then reboot. After that, you should see your encrypted data in /.home/$USER/.Private. This is what you'd want to point Unison or rsync at ;-)

    :-Dustin

    ReplyDelete
  5. Michael-

    I don't understand your comment. Are you sure you followed these instructions *very* precisely?

    :-Dustin

    ReplyDelete
  6. hggdh2-

    Thanks for the education on shred.

    Personally, I only ever use shred when I'm returning a borrowed system to an employer.

    :-Dustin

    ReplyDelete
  7. Dustin Kirkland-
    I am sure I have followed your instructions very precisely.
    They only strange thing after the process is, that a copy of my home directory remains in the /home/michael/Private folder. I have tested it under a VirtualBox Ubuntu Jaunty distribution.
    Again, this is not really a serious issue(except more space is actually needed during the process).
    A last instruction step of 'rm -rf $HOME/Private' will do the trick.
    --Michael

    ReplyDelete
  8. Dustin Kirkland-
    Sorry. After repeating your instructions again it works well. The /home/michael/Private does now not exist anymore. Please forget my prior posts. Keep up the good work!
    --Michael

    ReplyDelete
  9. Thank you so much for this step-by-step guide! :)

    ReplyDelete
  10. Just followed this guide on Karmic on my laptop and it worked a treat. Thanks Dustin..

    http://beeroverip.org/

    ReplyDelete
  11. Looks like I did something wrong... After the procusedure, My $HOME contained a folder $USER will all my data instead of having the data directly under $HOME.

    I've done it twice and got the same result.

    ReplyDelete
  12. Thanks for this guide. Worked nicely on the second attempt on Ubuntu Netbook Remix 9.04. Not sure what I did wrong the first time...

    ReplyDelete
  13. I followed your guide, and it worked. However, I can merely `su - ' as root, and be in the auto-mounted, encrypted volume. I tried changing the user's password, but this still did not prevent me from either logging in directly as the user, or switching users from root, and seeing the files. I'm lost. What's the point of this if root has wide open permissions to the files? Anyone can hack root on a lost laptop. Have I just not configured things correctly with the whole passphrase thing?

    ReplyDelete
  14. Dunkirk-

    The point is that (presumably) your attacker doesn't have the required passphrase to load and mount your home directory, like you did.

    If you home directory is encrypted, an attacker can't just mount up your disk and see your home data. They must have your passphrase to do so.

    Without encryption, anyone can steal your laptop or hard drive and just read your data.

    :-Dustin

    ReplyDelete
  15. Just to let readers know that a couple of the critical command-lines on this page do not render correctly in old browsers, more specifically Firefox 2.0.0/Ubuntu 6.10. Many thanks for this otherwise excellent documentation. Robbie Morrison, Berlin, Germany.

    ReplyDelete
  16. I think the command:
    echo /home /.home none ro,bind

    should be something like:
    echo /home /.home none ro,bind >> /etc/fstab

    Robbie Morrison, Berlin, Germany

    ReplyDelete
  17. Robbie, thanks. I was trying to figure out what Dustin intended there. You'll need sudo to write to fstab, so it should probably be:

    sudo mkdir /.home
    echo /home /.home none ro,bind |sudo tee -a /etc/fstab

    ReplyDelete
  18. Thanks for these instructions. They are very clear. Before I try them out, will they still work on Lucid?

    ReplyDelete
  19. @Dustin
    You should try Unison... it changes your life, really. See blogs linked from Wikipedia.
    Question: does Ubuntu support manually choosing the passphrase when creating/migrating an encrypted userhome folder without too much hacking?

    @Andy
    I run Unison on the upper layer, that is, on the unencrypted files that ecryptfs has mounted for you. The price to pay is 3 minutes instead of 3 seconds to check that there is nothing to sync, but only on the first sync after a reboot. Via ssh it always takes 3 minutes to check that nothing changed. I have 23.000 files and slow hardware.

    The big advantage is robustness. You can sync different computers regardless of having both with same passphrases (see question above), even regardless of having both encrypted at all, and there is no pain when you change the scheme for some of them or even when you use other platforms.

    Another big advantage is that when you sync you see that you have deleted "photos/2010/june/ugly-and-no-fucus.jpg" and you have no fear of propagating this deletion to the other device. Much better than "se523e4354a/2345srt45/h3465akj0ajkerh34990/56er6ydrh5656.454sat4wse45w5s"

    ReplyDelete
  20. Since the encrypted home directory automatically mounts and decrypts when you log in, is there nothing to stop someone if they reset your password like in this tutorial?

    http://www.psychocats.net/ubuntu/resetpassword

    ReplyDelete
  21. I don't think reseting the password would work. Isn't the password used to decrypt the actual key that in turn is used to encrypt/decrypt the data?

    In that case you would have to reset the password to the same unknown value to get the key. Changing the password would give access to the user's account but not decrypt the key correctly and hence the home would be full of inaccessible data.

    ReplyDelete
  22. Another approach to this, using a temporary user:

    http://ubuntuforums.org/showthread.php?t=1449168

    Might be some caveats?

    ReplyDelete
  23. Also found this on Ubuntu 10.04 Lucid Lynx:

    ecryptfs-migrate-home --help

    Usage:

    /usr/bin/ecryptfs-migrate-home -u USER

    -u,--user Migrate USER's home directory to an encrypted home directory

    WARNING: Make a complete backup copy of the non-encrypted data to
    another system or external media. This script is dangerous and, in
    case of an error, could result in data lost, or lock you out of your
    system!

    This program must be executed by root.

    ReplyDelete
  24. Applied these changes to Ubuntu 10.04 Netbook Edition after forgetting to select encrypted home directory during installation. Worked like a charm. Thanks for clear, concise, and accurate instruction.

    ReplyDelete
  25. Just FYI: I followed these instructions very carefully. I ended up with an empty home directory and my 'Private' directory was under /home/user.old/Private

    I noticed this when one of the commands in your instructions failed:

    echo $HOME > $HOME/.ecryptfs/Private.mnt

    It stated that /home/user/.ecryptfs/Private.mnt did not exist. That's because it was actually under /home/user.old/.ecryptfs/Private.mnt

    I'm using Ubuntu 10.10, not sure if that might make a difference. The command I reference above was the first command to fail during this whole process.

    ReplyDelete
  26. I think you should specify --one-file-system in the rsync command otherwise files from other possible mount points will be copied to the encrypted home and probably consume a lot more space than a user will expect.

    ReplyDelete

Please do not use blog comments for support requests! Blog comments do not scale well to this effect.

Instead, please use Launchpad for Bugs and StackExchange for Questions.
* bugs.launchpad.net
* stackexchange.com

Thanks,
:-Dustin