Do you use an external hard drive, USB Flash drive or other removable media for your personal or company backups? Let’s encrypt it!
My biggest concern with this scenario is in this: what if someone steals it? What if you lose it and someone else picks it up? Your data is a free for all and the finder (or thief) can access anything on the drive.
In this post, I’ll teach you how to use the Linux terminal to encrypt the entire partition. We’ll learn to encrypt your drive in such a way that it requires a password to mount and access, plus we’ll learn how to use a key file to setup trusted systems, so when you plug it into your own machine or server, the drive auto-mounts without a password (just like normal).
To be clear, this tutorial is for Linux. macOS and Windows users can upgrade to Linux for free! :p
Part 1: Encrypt Your Removable Backup Drive in the Linux Terminal
Part 2: Auto Mount Your Encrypted Backup Drive Linux With or Without a GUI
Everything we’re about to do requires running terminal as root.
In Debian, become root as follows:
In Ubuntu (and other “sudo”-based environments):
First things first:
Create a partition on your device, which we'll call /dev/whatever1. If you run luksFormat against the device itself (as opposed to a partition on the device) you will receive the error "no key available with this passphrase" when you try to run luksOpen, and will not be able to open the volume. If you accidentally do that, you can use a partition editor like gparted to change the drive to "unallocated" and try again.
apt-get install cryptsetup
Make the drive encrypted (destructive), 512-bit :
cryptsetup --verbose --verify-passphrase -s 512 luksFormat /dev/whatever1
cryptsetup luksDump /dev/whatever1
Map the drive:
cd /tmp cryptsetup luksOpen /dev/whatever1 backup
This will ask you for the passphrase and then creates a new mapper at /dev/mapper/backup
The reason I first go to /tmp is just in case there is a ./backup folder where I am currently situated within the filesystem. This could cause problems, so moving to /tmp removes the risk (unless there is a /tmp/backup, of course).
Create the filesystem (format):
You can now test mounting the drive if you like:
mkdir /tmp/backup mount /dev/mapper/backup /tmp/backup ls -lah /tmp/backup
Create a key file so you can auto-mount the drive (without having to enter the keyphrase). Only root should have access to this file:
dd if=/dev/urandom of=/root/backup.key bs=1024 count=4 chmod 400 /root/backup.key
Add the keyfile to our LUKS drive:
cryptsetup luksAddKey /dev/whatever1 /root/backup.key
Enter your passphrase when prompted.
Do another dump and you should now see Key Slot 1 has a key (from your key file):
cryptsetup luksDump /dev/whatever1
Now we need to determine the UUID of your LUKS-encrypted partition. This will be different than the actual physical UUID, so we have to use cryptsetup to find it:
cryptsetup luksUUID /dev/whatever1
Setup a crypttab entry:
Add the following:
backup /dev/disk/by-uuid/THE-UUID /root/backup.key luks
Start the crypto disk (replace backup with whatever you called it in the crypttab file):
Create your permanent mountpoint wherever you’d like and make it so you can’t write to it unless it’s mounted. For my example I’ll place it in /home/robbie/backup
mkdir /home/robbie/backup chattr +i /home/robbie/backup
Open your fstab file for editing:
Add your encrypted partition to the permanent mountpoint by adding this line:
# Encrypted external backup drive /dev/mapper/backup /home/robbie/backup ext3 defaults,nofail,noatime,rw,user,x-systemd.device-timeout=5 0 0
nofail means if the drive is not present, keep booting. noatime means access times are not updated when a file is read (read operations are read only: don’t use resources or reduce the life of the drive with write operations when not necessary). Our x-systemd.device-timeout setting means the mount will skip the drive if it is not plugged in after 5 seconds. The default is 90 so this speeds up boot big time.
Test to make sure everything worked:
mount -a ls /home/robbie/backup -lah
Do not reboot until you get a good result. 😀
Side note: If the drive is a USB drive, make sure you disable usbcore autosuspend, which will periodically turn off your USB, thereby breaking your mountpoint. On Debian I did this by editing /etc/default/grup and adding usbcore.autosuspend=-1 to GRUB_CMDLINE_LINUX_DEFAULT – you can confirm it worked by rebooting and then typing: cat /sys/module/usbcore/parameters/autosuspend – Here is some great info for other distros: http://unix.stackexchange.com/posts/175035/revisions
Update: January 16, 2018 – after using one such encrypted drive for nearly a year, I accidentally filled it beyond capacity and my system locked up. I rebooted at that point, and then forward could not mount my drive. I scared myself thinking I’d broken my LUKS system, but as it turns out it was quite easy to fix. I booted without the drive connected and commented out the fstab entry, then rebooted again. Then, I stopped the cryptdisk (as super user, of course) — cryptdisks_stop backup (where backup is the name of the mapper) — and plugged it in. Then, I ran cryptdisks_start backup to create the mapper, and did not mount it (that’s where it’d freeze up) – instead, I ran e2fsck on the mapper (not the drive / partition!) — e2fsck /dev/mapper/backup — and after an hour or so (a 2 TB USB flash drive) everything finished and I was able to mount the drive again! If you’re still having trouble at that point after a drive / filesystem issue, perhaps you have a bad superblock. There’s some great info here – just remember to use your mapper (eg., /dev/mapper/backup) and not the dev itself. From here forward I’ll be using my cleanup script to avoid this problem in future.