Encrypted partitions with Ubuntu/Debian

I figured out how to set up an encrypted partition on Ubuntu the other day. There are a bunch of ways of doing it but I found this to be the simplest. It should work on Debian too, since all the relevant packages are Debian ones anyway. In my example I’m encrypting an LVM partition (logical volume), but it should work with any device, including removable USB keys (see end notes). UPDATE: This is broken in Edgy but I figured out a simple fix, see below.

Install the cryptsetup package from apt

# apt-get install cryptsetup

Choose a partition you’d like to encrypt.

In my case, I’m encrypting an LVM logical volume on a sata harddisk:


Format the partition as a “LUKS” partition

LUKS stands for Linux Unified Key Setup. Run the following command and enter a password when prompted:

# cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/mapper/vg0-home

The option “-c aes-cbc-essiv:sha256” sets what cipher to use. It’s AES by standard, which is a good default but you want to enable ESSIV support explicitly because it’s rather important. With this option the crypto uses an different IV for each sector – protecting against known plaintext attacks and information leakage (such as the “watermarking attack).

Configure cryptsetup initscript

In /etc/crypttab add a line like this:

crypt-home    /dev/mapper/vg0-home             none    luks

crypt-home” is the name of the device mapper node that will be created (in the /dev/mapper/ dir). This is the the device you’ll mount.

Make the filesystem

Firstly, execute the cryptsetup initscript (or reboot):

/etc/init.d/cryptdisks start

This asks for your password and (if successful) creates the /dev/mapper/crypt-home device.
Now init your filesystem of choice (in this example, ext3):

mkfs.ext3 /dev/mapper/crypt-home

Configure fstab to automount the partition

Add a line to /etc/fstab:

/dev/mapper/crypt-home /home   ext3    defaults   0       2

Obviously, mounting this won’t work unless the cryptdisks initscript has been executed, but this happens in the correct order on boot.


On boot, you’ll be prompted for the password quite early on in the boot process. The prompt should time out after 180 seconds if you don’t type anything (handy for a server).

After you’ve typed the correct password, the device mapper device is created and then the unencrypted partition is mounted shortly after (alongside all the other partitions, as usual).

UPDATE: LUKS on boot broken in Edgy
This worked fine for me with Dapper, but an upgrade to Edgy broke it. It’s been reported as a bug on launchpad but I figured out a simple fix in the mean time:

Change line 294 in /lib/cryptsetup/cryptdisks.functions from:

$CRYPTCMD $PARAMS luksOpen $src $dst < &1


$CRYPTCMD $PARAMS luksOpen $src $dst < /dev/console

Now it jumps to console from splash on boot and asks for password.

Encrypted Swap

Remember, data from your encrypted partition could end up on disk in your unencrypted swap partition. Depending on what you’re trying to achieve, this probably isn’t desirable. Set your swap partition to be stored in another encrypted device using LUKS. Use /dev/random as the keyfile and it’ll use a random password for encryption on every boot. I expect this will break hibernate support though.

USB keys and other removable devices

If you create a LUKS partition on a removable device (such as a USB key), the HAL daemon will spot that it’s LUKS and automatically handle all the cryptsetup stuff (including a nice Gnome password box). In this case, don’t setup the crypttab or fstab. Instead:

  1. After creating the LUKS partition, open it manually (you’ll be prompted for the password):
    cryptsetup luksOpen /dev/sdusbdiskdevicename1 luks-temp
  2. Create the filesystem:
    mkfs.ext3 /dev/mapper/luks-temp
  3. Manually close the LUKS partition:
    cryptsetup luksClose luks-temp
  4. Now just eject/unplug the device then reinsert it and you’ll be asked for the password!

These encrypted removable devices are even supported on Windows (see FreeOFTE) but you’ll obviously need to use a Windows compatible file system, like FAT32 or NTFS rather than EXT3).


An old man says:

You’re a bloody genius, cheers.

Marco says:

Hi, thanks for the documentation. Works perfectly. I have a little problem. When I plug the usb disk I’m asked for the password (gnome way) but I haven’t the rights to write on the disk. And since there is nothing about this partition in fstab neither in the crypttab… I’m lost.

john says:

Marco: FAT32 doesn’t support permissions, so whenever you plug it into a computer, the user plugging it in gets access to it. With EXT3 (and other filesystems that do support permissions) only the root user can access it by default (usually).

To fix this, just plugin your key and type your passphrase to get it mounted. Then set the permissions to something you can access (you’ll need to do this as root).

What permissions you use really depend on your situation. If you only ever plug it into a one-user desktop machine then running chmod 777 /mount/point should be fine.

If you move the key between different Linux computers, you might hit the permission problem again if the users on the machines have different uids.

It might be better just to reformat as FAT32, so you can easily use it anywhere. Remember though, FAT32 has some limitations that might prevent you from copying files with certain characters in it, or files larger than a certain size.

It’d be nice to have a filesystem with the flexibility of EXT3 but with no permissions system, or one which could be overridden on mount. Anyone know of one?

rdg says:

Well the simples thing to do would be:

sudo chown -R uid:gid /device/mount/point

or without sudo run by root. But changing the owner back and forth isn’t what we’re looking for all the time (but most cases would be ok with that).

I think looking into the stuff like SGID and SUID on mount directory and umask as well might do the trick. But still – ext3 without the permissions would be perfect.

Daniel says:

Thanks for this great howto!

I just wanted to point out that luksClose expects the name of the mapping not of the device.

Therefore, step 3 in the USB key section will fail, it should read:

cryptsetup luksClose luks-temp

john says:

Thanks Daniel, fixed now.

doctor headcrash says:

It’s not so much that LUKS is broken under Edgy, it’s the whole getting the passphrase thing under cryptsetup.

Using your LUKS solution as a guide, I hacked around this problem by changing line 318 of /lib/cryptsetup/cryptdisks.functions to read:

$CRYPTCMD $PARAMS create $dst $src

doctor headcrash says:

… my angle braces broke the previous posting.

Let me try with HTML escapes:

$CRYPTCMD $PARAMS create $dst $src < /dev/console

disk_noir says:

Great tutorial, espacially the removable disks part is very interesting for me.
But.. do you have any expierience with updating an encrypted system eg from dapper to edgy ? Did such an update work even with encrypted root ?

MFH says:

Great tutorial, with one problem: encrypted swap files. The man page for cryptsetup clearly says that exhaustive reads makes it impossible to use /dev/random, etc as sources for keyfiles. Please give more explicit directions on how one can use your method to set up an encrypted swap space. TIA.

pierre says:

I have been trying to crypt the USB stick (partition of it, about 70 MB) but is saying that it inexplicably (for me ;) ) failed.
any idea ? I am running Kubuntu 7.04.

pierre@HomePC:~$ mount
/dev/sdg2 on /media/disk-2 type vfat (rw,nosuid,nodev,noatime,uid=1000,utf8,shor pierre@HomePC:~$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/sdg2

This will overwrite data on /dev/sdg2 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sdg2 contains at least 133 sectors.
Failed to write to key storage.
Command failed.

Justin says:

You need to modprobe aes, dm-crypt, and dm_mod. Then, add these to /etc/modules. Then, run cryptsetup again as root (sudo).

Danbar says:

Our family computer is used be several family members. I created several partitions (one for each member). Now can I have a different password for each user when it comes to save in his/her own partition in order to avoid deleting or mixing up important files? I’m the only administrator as the other are users.
I don’t wish to use the home directory (for each user)in case I have problems with the program. Having partitions gives more security to the computer.
I use dual boot (XP and Ubuntu) and I have the latest edition of Ubuntu (7.04).
Many thanks!

[…] mainly used this tutorial, but I derived a little from it about the unlocking system : I did not want to input a password […]

Wanderer says:

“These encrypted removable devices are even supported on Windows (see FreeOFTE)”

Right now I’m a bit frustrated with FreeOTFE, as it doesn’t show other partitions on my flash drive, only the first one, which is unencrypted. AFAIK there is no way to create more than one partition on removable drive in M$ Windows, which really sucks.

Robert says:

I am wondering if encrypting can be a solution for what follow and so just a direct question:

let say I have a “special” server configuration with a lot of my knowledge inside to make it working with special services.

How to prevent the customer (or other IT technicians) to clone it or to copy some configuration files or entire directories?

This is intended to prevent somebody to clone my box for its personal use.

Hope to have given an idea of what I mean.

Thank you for any tip.


Mich says:

I know this may a bit late but anyway, appreciate if someone could help on the following:

– not wanting to auto-mount the encrypted partition on bootup,
> do not add the encrypted partition into crypttab, correct?

– upon boot up without auto-mount
> how can I mount the encrypted-partition manually?

Appreciate your advise.

Leave a Reply