Package: crypto-drive-manager
crypto-drive-manager: Unlock all your encrypted drives with one pass phraseThecrypto-drive-managerprogram allows you to safely, quickly and
conveniently unlock an unlimited number ofLUKS encrypted devicesusing a
single pass phrase. You can think of it as akey passfor LUKS encrypted
devices. It works by creating a small (10 MB) encrypted file system inside a
regular file (using aloop device) and storing key files for the encrypted
devices of your choosing inside this encrypted file system. Each time you run
the program it temporarily unlocks the 10 MB encrypted file system and uses the
key files to unlock and mount encrypted devices that are present and not
already unlocked.InstallationThecrypto-drive-managerprogram is written in Python and is available onPyPIwhich means installation should be as simple as:$ pip install crypto-drive-managerThere’s actually a multitude of ways to install Python packages (e.g. theper
user site-packages directory,virtual environmentsor just installing
system wide) and I have no intention of getting into that discussion here, so
if this intimidates you then read up on your options before returning to these
instructions ;-).ConfigurationThecrypto-drive-managerprogram doesn’t have a configuration file because
it looks at your system configuration to infer what it should do. You need to
create or change/etc/crypttabin order to enablecrypto-drive-manager.
As an example here’s my/etc/crypttabfile:# <target name>  <source device>                            <key file>                 <options>
internal-hdd     UUID=626f4560-cf80-4ed9-b211-ac263b41ca67  none                       luks
media-files      UUID=6d413429-f8d1-4d8e-8a3a-075603b8efdd  /mnt/keys/media-files.key  luks,noauto
mirror3          UUID=978d7a3a-c902-43e6-aa71-5654d406c247  /mnt/keys/mirror3.key      luks,noauto
mirror4          UUID=7a48e547-1dfa-4c6a-96e9-05842c87465d  /mnt/keys/mirror4.key      luks,noauto
mirror5          UUID=ac6aa22a-0c32-4bd9-829a-75316177affb  /mnt/keys/mirror5.key      luks,noauto
mirror6          UUID=00474636-6d6e-4ecc-a7d6-21b42d850ac6  /mnt/keys/mirror6.key      luks,noauto
mirror7          UUID=ec56dc10-1086-4f2b-808c-88995cb8b513  /mnt/keys/mirror7.key      luks,noautoYou can see why I don’t want to manage all of these encrypted devices manually
by entering pass phrases for each of them :-). Even though my root device
(internal-hdd) is also encrypted, storing key files to unlock my encrypted
devices on my root device doesn’t feel right because the key files will be
exposed at all times.You tellcrypto-drive-managerto manage an encrypted device by setting the
key file (the third field in/etc/crypttab) to a file located under the
mount point used bycrypto-drive-manager(/mnt/keysby default). Every
time you runcrypto-drive-managerit parses/etc/crypttabto find and
unlock managed devices. TheUUID=...definition in/etc/crypttabis
used to check if the physical device exists in/dev/disk/by-uuid. Because
of this a source device definition with aUUID=...value is required.Each physical device that exists is initialized, unlocked and mounted. Device
initialization happens when the key file for the encrypted device doesn’t exist
yet: The key file is created with 4 KB of random bytes and installed as a key
on the encrypted device.The end result is a program that requires a single pass phrase to unlock a
virtual keys device containing key files used to unlock a group of encrypted
devices. Once the encrypted devices have been unlocked the virtual keys device
is unmounted and the keys are no longer available (except in memory, which
cannot be avoided to the best of my knowledge).UsageUsage:crypto-drive-manager [OPTIONS] [NAME, ..]Safely, quickly and conveniently unlock an unlimited number of LUKS encrypted
devices using a single pass phrase.By default all entries in /etc/crypttab that reference a key file located under
the mount point of the encrypted disk with key files are unlocked (as needed).
To unlock a subset of the configured devices you can pass one or moreNAMEarguments that match mapper name(s) configured in /etc/crypttab.Supported options:OptionDescription-i,--image-file=PATHSet the pathname of the file that contains the encrypted disk image with
key files (defaults to ‘/root/encryption-keys.img’).-n,--mapper-name=NAMESet the mapper device name for the encrypted disk with key files so that
the device for the drive with key files will be created as
‘/dev/mapper/NAME’ (defaults to ‘encryption-keys’).-m,--mount-point=PATHSet the pathname of the mount point for the encrypted disk with key files
(defaults to ‘/mnt/keys’).--install-systemd-workaroundReplace the systemd-cryptsetup-generator program with a wrapper that
removes the ‘RequiresMountsFor’ option from the generated configuration
files at /var/run/systemd/generator/*.service.Refer to the readme for more details about how this works.-v,--verboseIncrease logging verbosity (can be repeated).-q,--quietDecrease logging verbosity (can be repeated).-h,--helpShow this message and exit.ProblemsWhen I upgraded my personal server to Ubuntu 16.04 and rebooted the system I
was immediately bitten bysystemd issue #3816: When any of the encrypted
drives managed bycrypto-drive-managerare affected by this issue then
unmounting of the keys device will cause systemd to immediately unmount and
lock those encrypted drives.My initial workaround for this issue (released in crypto-drive-manager 2.0) was
to simply leave the virtual keys device unlocked and mounted, but of course
this went straight against howcrypto-drive-managerwas originally designed
and intended to work.In crypto-drive-manager 3.0 I implemented and released a real workaround:The commandcrypto-drive-manager--install-systemd-workaroundreplaces/lib/systemd/system-generators/systemd-cryptsetup-generatorwith a
symbolic link to thecrypto-drive-managerprogram. The original
generator program is renamed so that it remains accessible.Whensystemctldaemon-reloadis run it callscrypto-drive-managerby following the symbolic link (without realizing it of course).By checking the value ofsys.argv[0]thecrypto-drive-managerprogram can determine whether it’s being run bysystemd.In this casecrypto-drive-managerwill first run the original generator
program and then it will rewrite the generated service files located in/var/run/systemd/generatorto removeRequiresMountsForfields.By the timesystemdrereads its configuration files theRequiresMountsForfields have already been removed.Becausecrypto-drive-managerautomatically detects the presence or
absence of problematicRequiresMountsForfields it will detect its own
workaround and properly lock the virtual keys device after use.Profit! :-PTo be honest all of this started as a thought experiment with me trying to
verify my understanding of the problem and what would be involved to fix it.
Once I realized that my (nasty! I know) workaround was actually effective I
decided I might as well publish it. I do actually use this workaround on my
personal server (for whatever that’s worth).ContactThe latest version ofcrypto-drive-manageris available onPyPIandGitHub. For bug reports please create an issue onGitHub. If you have
questions, suggestions, etc. feel free to send me an e-mail atpeter@peterodding.com.LicenseThis software is licensed under theMIT license.© 2017 Peter Odding.