Best practice/recommended way to mount encrypted USB disk at boot

English Install/Boot/Login
#1

I have a question regarding the recommended openSUSE (13.1) way is for automatically, at boot, mounting an encrypted USB disk. I know how to manually mount the disk but I am just wondering what the best way would be to do it automatically, except for entering the pass-phrase. I don’t mind entering that by hand.

The scenario is as follows:
On my system, all partitions that hold data or temporary data (/home, /tmp, /var/tmp and swap) are encrypted. I want to regularly backup the home partition to an external USB hard drive, via Backintime. This is done using a schedule so that I don’t forget to start the backup. Obviously, if the hard drive isn’t mounted, the backup fails because there is no destination to write to. Because I don’t want to have to remember mounting this drive by hand each time, I want the drive to be mounted at boot time by the system.

I know I can mount the disk manually as follows:

# cryptsetup open /dev/sdc1 backup

This opens the encrypted disk, which I can then mount the ordinary way:

# mount -t ext4 /dev/mapper/backup /mnt/backup

In order to achieve the above automatically, is it sufficient to create an entry in /etc/crypttab?
Are there other/better ways or caveats that I should be aware of?

#2

You might also need to an an entry to “/etc/fstab”.

Instead of calling it “/dev/sdc1” in the “crypttab” entry, you would be better off calling it “/dev/disk/by-id/some-ugly-string-part1”. To find out the “some ugly string” part, look at what’s in “/dev/disk/by-id” (use “ls -l”), and pick a suitable name that currently shows as a symlink to “/dev/sdc1”.

The reason for this, is that if there happens to be another USB disk also plugged in, your disk might be assigned a different device name, but the “by-id” name will remain unchanged. So it’s more reliable.

#3

On 2014-01-21 02:06, nrickert wrote:
>
> joopberis;2617960 Wrote:
>> In order to achieve the above automatically, is it sufficient to create
>> an entry in /etc/crypttab?
> You might also need to an an entry to “/etc/fstab”.

And add to it “nofail”, because if the usb stick is missing, boot will
crash.

> joopberis;2617960 Wrote:
>> Are there other/better ways or caveats that I should be aware of?
>
> Instead of calling it “/dev/sdc1” in the “crypttab” entry, you would be
> better off calling it “/dev/disk/by-id/some-ugly-string-part1”. To find
> out the “some ugly string” part, look at what’s in “/dev/disk/by-id”
> (use “ls -l”), and pick a suitable name that currently shows as a
> symlink to “/dev/sdc1”.
>
> The reason for this, is that if there happens to be another USB disk
> also plugged in, your disk might be assigned a different device name,
> but the “by-id” name will remain unchanged. So it’s more reliable.

Correct.

I just connected a non-encrypted usb stick to see what is available:


> Telcontar:~ # l /dev/disk/by-id/ | grep sde
> lrwxrwxrwx 1 root root    9 Jan 21 02:23 scsi-1USB_DISK_2.0 -> ../../sde
> lrwxrwxrwx 1 root root   10 Jan 21 02:23 scsi-1USB_DISK_2.0-part1 -> ../../sde1
> lrwxrwxrwx 1 root root   10 Jan 21 02:23 scsi-1USB_DISK_2.0-part2 -> ../../sde2
> lrwxrwxrwx 1 root root    9 Jan 21 02:23 usb-_USB_DISK_2.0_1210042255588CDD-0:0 -> ../../sde
> lrwxrwxrwx 1 root root   10 Jan 21 02:23 usb-_USB_DISK_2.0_1210042255588CDD-0:0-part1 -> ../../sde1
> lrwxrwxrwx 1 root root   10 Jan 21 02:23 usb-_USB_DISK_2.0_1210042255588CDD-0:0-part2 -> ../../sde2
> Telcontar:~ #

There is a curiosity. You can not use “uuid”, because they belong to the
filesystem, which is only available after decryption. But there is a
trick: if, when creating the encrypted device, you create first a plain
filesystem (I use xfs for this), and keep a note of the “uuid” it gets,
and then you created the encrypted device and format it, it is very
curious that the “uuid” from the overwritten xfs filesystem survives and
is available for use in “/etc/crypttab”:


cr_something   /dev/disk/by-uuid/39-some-fancy-uuid  none  noauto

The advantage (to me) is that the external device can be plugged via
eSATA or USB as I choose or can (the by-id changes, but the uuid does not).

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

#4

I’m not sure that is true. At least for LUKS encryption, there should be a UUID in the LUKS header.


/dev/sdb6: UUID="593a078b-1dc7-4977-a02e-2c2578f901ec" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="82012208-4805-4527-9cbc-b8894a0d9ec4"

That’s part of the output of “blkid”. The particular partition is not unlocked and not mounted.

When I unlock, with “cryptsetup”, I get:


/dev/mapper/cr_home: UUID="94ca9007-74dd-4e8b-a742-c9ee039ebcaf" TYPE="ext4"

so the UUID for the file system is different from the UUID for the LUKS header.

#5

Thank you both, this answers my questions perfectly.
I appreciate it!

#6

On 2014-01-21 06:06, nrickert wrote:
>
> robin_listas;2617967 Wrote:
>> There is a curiosity. You can not use “uuid”, because they belong to the
>> filesystem, which is only available after decryption.
>
> I’m not sure that is true. At least for LUKS encryption, there should
> be a UUID in the LUKS header.

I’m not sure either. When I tried this years ago, I did not see that
UUID after I encrypted the device. This may have changed, or I might be
mistaken then.

I do see an UUID on all my current encrypted devices. But it could be
because I followed the procedure I described of initially creating a
filesystem which is then overwritten by the encrypted device…

I’ll have to try again to make sure of this.

> so the UUID for the file system is different from the UUID for the LUKS
> header.

Yes, that has to be so regardless of the procedure used for creation.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)