加密驱动管理器 3.0

加密驱动管理器：使用一个密码短语解锁您所有的加密驱动器

crypto-drive-manager 程序允许您安全、快速、方便地使用单个密码短语解锁无限数量的 LUKS 加密设备。您可以将其视为 LUKS 加密设备的“密钥通行证”。它通过在常规文件内创建一个小的（10 MB）加密文件系统（使用 循环设备）并在此加密文件系统中存储您选择的加密设备的关键文件来实现。每次运行程序时，它都会临时解锁 10 MB 的加密文件系统并使用关键文件解锁和挂载已存在且尚未解锁的加密设备。

安装

crypto-drive-manager 程序是用 Python 编写的，可在 PyPI 上找到，这意味着安装应该非常简单

$ pip install crypto-drive-manager

实际上有无数种方法可以安装Python包（例如，个人站点包目录per user site-packages directory，虚拟环境或仅安装系统级），我没有打算在这里讨论这个问题，所以如果你感到害怕，请在返回这些说明之前先了解你的选项 ;-).

配置

crypto-drive-manager程序没有配置文件，因为它通过查看系统配置来推断应该做什么。您需要创建或更改/etc/crypttab才能启用crypto-drive-manager。以下是我的/etc/crypttab文件示例

# <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,noauto

你可以看到为什么我不想手动管理所有这些加密设备，通过为每个设备输入密码短语来解锁它们 :-)。尽管我的根设备（internal-hdd）也是加密的，但将密钥文件存储在根设备上以解锁我的加密设备并不合适，因为密钥文件将始终处于暴露状态。

您通过将密钥文件（/etc/crypttab中的第三个字段）设置为位于crypto-drive-manager使用的挂载点下的文件（默认为/mnt/keys）来告诉crypto-drive-manager管理一个加密设备。每次运行crypto-drive-manager时，它都会解析/etc/crypttab以查找和解锁管理的设备。/etc/crypttab中的UUID=...定义用于检查物理设备是否存在于/dev/disk/by-uuid。因此，需要一个具有UUID=...值的源设备定义。

每个存在的物理设备都会被初始化、解锁和挂载。当加密设备的密钥文件不存在时，发生设备初始化：密钥文件使用4KB的随机字节创建，并作为密钥安装到加密设备上。

最终结果是，一个程序只需单个密码短语即可解锁包含用于解锁一组加密设备的密钥文件的虚拟密钥设备。一旦加密设备被解锁，虚拟密钥设备就会卸载，密钥就不再可用（除了内存中，据我所知无法避免）。

使用方法

用法： crypto-drive-manager [OPTIONS] [NAME, ..]

使用单个密码短语安全、快速、方便地解锁无限数量的LUKS加密设备。

默认情况下，/etc/crypttab中所有引用位于加密磁盘密钥文件挂载点下密钥文件的条目都将解锁（如有需要）。要解锁配置设备的一部分，您可以传递一个或多个匹配于/etc/crypttab中配置的映射器名称的NAME参数。

支持选项

问题

当我将个人服务器升级到Ubuntu 16.04并重启系统时，我立即遇到了systemd问题#3816：当由crypto-drive-manager管理的任何加密驱动器受到影响时，卸载密钥设备将导致systemd立即卸载并锁定这些加密驱动器。

我对该问题的初始解决方案（在crypto-drive-manager 2.0中发布）是简单地让虚拟密钥设备保持未锁定和挂载，但这当然与crypto-drive-manager最初的设计和预期工作方式相矛盾。

在crypto-drive-manager 3.0中，我实现了并发布了真正的解决方案

1. 命令crypto-drive-manager --install-systemd-workaround将/lib/systemd/system-generators/systemd-cryptsetup-generator替换为指向crypto-drive-manager程序的符号链接。原始生成程序被重命名以便仍然可访问。

2. 当运行systemctl daemon-reload时，它会通过符号链接调用crypto-drive-manager（当然，没有意识到这一点）。

3. 通过检查sys.argv[0]的值，crypto-drive-manager程序可以确定它是否由systemd运行。

4. 在这种情况下，crypto-drive-manager将首先运行原始生成程序，然后它会重写位于/var/run/systemd/generator的生成服务文件，以删除RequiresMountsFor字段。

5. 当systemd重新读取其配置文件时，RequiresMountsFor字段已经被删除。

6. 因为crypto-drive-manager会自动检测有问题RequiresMountsFor字段的缺失或存在，它会检测自己的解决方案并在使用后正确锁定虚拟密钥设备。

7. 搞定！:-P

说实话，这一切最初只是我进行的一个思想实验，我试图验证我对问题的理解以及修复它可能需要什么。一旦我意识到我的（很糟糕！我知道）解决方案实际上有效，我就决定最好将其发布。实际上，我在我的个人服务器上使用了这个解决方案（无论这值多少）。

联系

crypto-drive-manager的最新版本可在PyPI和GitHub上获取。有关错误报告，请GitHub上创建一个问题。如果您有任何问题，建议等，请随时通过peter@peterodding.com发送电子邮件。

许可协议

此软件根据MIT许可证许可。

© 2017 Peter Odding。