用 LUKS 加密租用的 root 服务器

LUKS 容器、loop 镜像文件、加密头备份：为租用的 root 服务器做加密，去掉神话滤镜。年付入门套餐低至 $4.80/月。

LUKS 到底保护什么（以及它永远保护不了什么）

大众想象中，加密像一层装甲板，把运行中的机器整个包起来。现实要窄得多：LUKS 保护的是那些没人盯着的时刻。退役时被拔走的硬盘、静静躺在冷备份里的镜像、你睡觉期间被挂载的救援盘——没有你的口令，它们全都只是一堆密文。而与此同时，已经启动的系统、密钥就驻留在内存里，对任何拿到 root 权限的人完全透明。

从机制上讲，这里只有一个主密钥，以多种方式包裹。格式化时会生成一个随机的卷密钥——默认 aes-xts 加密算法下为 512 位——并封存在加密头的 keyslots 中，每个口令占一个槽位，完全遵循 cryptsetup 项目的规范。解锁时会解开这个密钥并交给 dm-crypt，由它在数据读写过程中实时解密。磁盘上存储的字节从未改变，改变的只是它们的可读性，而这道门槛握在你手里。

这层封装是可以检查的。cryptsetup luksDump /dev/vdb 会打印加密算法、加密头几何结构以及每个凭据对应的槽位——清清楚楚地证明，是什么把你的数据和外界隔开。但这种可检查性是双刃剑：加密头同时也是不可恢复故障的唯一单点，这正是本页一半篇幅围绕它展开的原因。口令强度很重要，但加密头的存亡更重要，而且那两份备份必须放在不同的地方。

对运行状态的过度自信才是真正的坑。一台已启动的机器必须在内存中持有解包后的密钥，否则什么都解不开；由此产生的后果是：root 看到的是明文，宿主机运营商看到的是明文，一次内存泄露就能带出密钥。相信加密算法能保护一台正在运行的服务器，就是本页反复纠正的错误——加密针对的是静态存储，从来不是传输中的会话。

换一种说法来划清边界：被拔走的磁盘、归档的镜像和救援挂载都在保护范围之内；运行中宿主机的管理员则在范围之外。拥有自己的金属设备，意味着这个管理员受你的合同约束。租用一台 KVM 切片，则等于多了一个密钥停留的地点——启动路径——这个地点值得单独用一节来讨论。

租用服务器的启动路径：不加滤镜地看清楚

一台租来的切片从借来的代码开始启动：虚拟机监控器先加载内核和 initramfs，然后才轮到任何属于你的东西执行。在启动过程中提示输入口令的加密方案在这条路径上照样能工作——但请注意其中的含义。你的口令是通过一套你并不管理的基础设施输入的，也就是说，这个秘密或多或少触碰过宿主机一侧的启动过程。诚实的模型会把这次接触计算在内，而不是一笔勾销。

有两种设计可以应对。第一种：让启动卷保持明文，把敏感数据封在里面的一个 LUKS 容器中——放在一块备用卷上或一个磁盘镜像文件里——每次重启后通过 SSH 用一把只有你持有的密钥解锁；代价是重启要等你到场。第二种：完全拥有这台机器，自建 initrd，并把 IPMI 作为紧急控制台，以备解锁提示出问题时使用。

还存在一条中间路线——在 initramfs 里跑一个微型 SSH 守护进程，类似 dropbear 那样，让口令通过网络传输——而 RFC 4253 正是这条信道值得信任的依据。不过要诚实地为其定价：此后秘密仍然留在宿主机的内存里，落在你不掌管的硅片上。它能防住硬盘失窃；防不住平台本身。

最常见的错误是把各种真相取平均值：看到解锁提示出现了，就断定服务商“什么都看不到”。可它交付了引导加载程序，它托管着存放你密钥的内存，它可以对你刚刚锁好的机器做镜像。这些都不妨碍这套练习的价值——它只是把“容器”设计（启动后让服务商远离秘密的路径）提升为诚实的默认方案。

设计一不需要什么英雄壮举：一块备用卷、一个口令、每次重启后一套固定动作。下一节将一步步搭好这套流程，再下一节会把它压缩进一个磁盘镜像文件，供只有一块盘的机器使用。两条路的终点相同——把一份加密头副本存到很远的地方。

设计一：放在操作系统旁边的密封容器

默认方案刻意朴素。让操作系统待在原地；把敏感数据集合——签名密钥、邮件队列、数据库转储、以及每份被人发誓“只是临时用用”的 .env——集中到第二块卷上，这块卷在你到场之前始终处于关闭状态。如果这批数据装得下 80 GB NVMe 的一半，那就选入门套餐：标价 $6/月，12 个月预付仅 $4.80/月，然后安心待着。

四条命令搞定一切。cryptsetup luksFormat /dev/vdb 把加密头写进裸卷；cryptsetup open /dev/vdb vault 暴露出 /dev/mapper/vault；mkfs.ext4 在里面建好文件系统；mount 把它挂到你喜欢的位置。用 rsync 把数据复制过去，抽样校验，确认无误后再退役原始数据。此后，任何没有你口令的东西读这块卷，读到的都只是噪声。

把解锁绑定到人身上，绝不绑定到启动。那个诱人的捷径——一条 crypttab 条目加一个 fstab 挂载——要么让每次重启都卡在等一个控制台根本无法输入的口令上，要么用存在同一块磁盘上未加密的密钥材料来解包，那是加了若干步骤的安全表演。要么每次自己解锁卷，要么让一个单元通过认证信道等待你的输入；crypttab(5) 记录了相关选项，其中最重要的就是 noauto。

回顾事故报告，通常能追溯到两个失误。其一，就是那个盘上存密钥的捷径——它悄无声息地把容器降级成了装饰品。其二，是加密头本身：一次随手的重格式化，或一个脚本擦过开头那几兆字节，然后一个记得分毫不差的口令也解不开任何东西，因为包裹记录已经没了。把该设备的前 16 MiB 当作承重墙对待——它确实是。

一块卷、一个凭据、一套动作——大多数敏感数据集合需要的不过如此。没有第二块卷的机器，可以把同一设计折叠进一个伪装成磁盘的文件里，这正是下一节的主题。它的吞吐量损失远比传闻中小，而管理上的收益更大。

设计二：表现得像块硬盘的磁盘镜像

没有备用卷？Linux 可以把一个普通文件交给 loop 子系统，让 LUKS 把它当作块设备来寻址。密封的数据集合于是活在单个可移动的工件里：复制它、传输它、存到国外——一路都是密文。对于密钥和邮件队列的归档来说，这往往是加密所能呈现的最易管理的形态，而且配方有一半可以从卷方案原封不动地沿用过来。

流程是：truncate -s 40G /srv/vault.img 以稀疏文件的形式预留空间，losetup -f --show 挂载它并打印选定的 loop 设备，然后格式化和解锁的步骤与卷方案完全一样——涉及的参数见 losetup(8) 的文档。从挂载往后没有任何区别：同样的动作，同样的加密头纪律。命名也有讲究——别把镜像放在易变的目录里，因为日志写得凶的应用会愉快地把同一个文件系统填满。

备份退化成单纯的文件操作。夜间任务变成：停、复制、启动——而且副本是密文，到哪儿都受欢迎。在会话进行中拍摄的平台快照，捕获到的仍然只是密封的块，因为包裹密钥从不落盘。LUKS 设计带来的这份特性，正是镜像模式容器在快照友好的平台上蓬勃发展的原因。提醒一句：放在你家目录里的那把便利密钥可享受不到同样的豁免，后文有一节专门解释。

三个失误制造了绝大多数镜像事故。大小：ls 报告 40G，而 du -h 显示实际只分配了 2 GiB——按 du 的数字做规划，对谁都别恐慌。传输：不带 --sparse 的归档工具会在目的地把文件膨胀到标称大小。重新挂载：重启会丢掉 loop 映射，所以脚本必须重新发现设备，而不是把设备号写死。

掌握了文件变体之后，它会融为日常例行——而这恰恰是加密头纪律开始松懈的时刻。把下一节读两遍：一个没有异处副本的加密头，等于一份没人能验证的签名遗嘱，本页后面没有任何东西能挽回这种特定的损失。

决定一切的十六兆字节

把轻重颠倒的事实直说吧：密封卷中不可替代的部分不是数据——是加密头。LUKS2 默认的 16 MiB 加密头承载着包裹卷密钥的 keyslots；抹掉它，正确的口令也解不开任何东西。数据块依然在，只是纯粹意义上的噪声。先备份封装层，再备份数据；顺序颠倒的话，你关心的东西一样也保不住。

一条命令就能完成救援：cryptsetup luksHeaderBackup 指定目标文件，接着算校验和，然后转移到另一台设备上——另一块磁盘、另一个大洲，总之别在卷本身的机器上。用 luksDump 指向副本验证备份；打印出的 keyslot 布局必须与在线设备一致。读不出来的备份只是传说，项目 FAQ 反复强调的正是这一点。

趁着没事时演练恢复：建一个草稿文件，往上面写一个全新的加密头，用 luksHeaderRestore 把你的副本覆盖上去，然后确认解锁能成功。花两分钟，换来“你守护的字节就是正确的字节”这一确定性。另外注意失效规则——更改凭据会重写 keyslots，所以每次修改口令都会让旧副本作废；每次变更之后都要重新抓取一遍加密头。

过期恢复是沉默的杀手：卷在几个月前重建过，陈旧的加密头被重新套上，口令也通过了——内容却解出一堆乱码，因为旧封装持有的是上一个卷密钥，而数据是用新密钥写入的。封装层和数据块的版本必须对应。给每份副本标注日期，只保留最近两份，并且明令禁止任何自动化恢复。

加密头安全地离开本机之后，残余风险转移了位置——转移到内存里、流程里、以及能触及这台运行中机器的人身上。下一节将绘制这片运行状态的疆域：一个已解锁的容器暴露了什么，快照真正复制了什么，以及“可以丢的存储”与“丢不了的会话”之间，诚实的边界画在哪里。

内存、快照，以及那条线真正的位置

在一台已解锁的机器上做快照实验：镜像只捕获到密封的块，因为解密发生在读取的过程中，磁盘上从不存明文。听起来百毒不侵，直到那把便利密钥浮出水面——一个躺在 /root/vault.key、权限 600 的文件，明晃晃地搭上了同一个快照。于是你的归档强度等于启动盘的权限位：够用，直到某一天突然不够。

内核保留每一个已映射的密钥，而 root 有权索取它们：dmsetup table --showkeys 会以十六进制打印每个活动目标的主动密钥。这不是漏洞——这是设计。解密需要驻留，而内核 root 就是对机器的主权；内核的 dm-crypt 指南对此毫不讳言。你自己的威胁模型也应该用同样的语气说出同样的话。

诚实地画两栏。始终覆盖：静止的密封容器、密封状态的快照、被拔出的磁盘、运往国外的副本。从不覆盖：活动会话、内存中的密钥、输入口令的那个终端。加密算法只回答一个问题——存储离开之后会发生什么——并且明确拒绝回答另一个：机器在运行中被扣押时会怎样。不同的问题，需要不同的对策。

笔记本直觉放到服务器上会误导人。以为“卷是密封的，运营商就算不了什么”，忽视了三种能力：快照指令、内存检查、宿主机沦陷——无论你选哪种加密算法，每一种都能读取一台运行中的机器。加密照样要做，因为密封状态占据了一块磁盘日历上的绝大部分时间；只是别再假装平台置身于你写下的威胁模型之外。

以上全部假设是一个你无法掌控的启动过程。金属设备把这一切倒转：initrd 是你的，控制台是你的，开机后的提问由你来出题。独立服务器的情况就在下面，而且比预想的短——因为那些艰难的纪律——把加密头副本放在别处、勤换凭据——你在前面几节里已经学到了。

掌控启动：金属设备的论据

再次反直觉：裸金属反而让加密变简单。你编译 initrd，你拥有引导加载程序，口令提示出现在你掌控的控制台上——秘密的旅程中没有任何服务商的影子。前几节里关于租用路径的所有警告统统失效。剩下的只是你早已在实践的那套纪律：加密头副本放在别处，凭据有意识地轮换，解锁路径反复演练。

两块硬盘会逼你尽早对镜像做出决定。把每一块都密封——/dev/nvme0n1 和 /dev/nvme1n1 各自带独立的加密头，最好口令也分开——然后按 md(4) 的描述，用 md 对已映射的两块盘做镜像。一块盘故障，替换盘重新同步，而幸存的那块从未在别人的时间表上以未密封的状态存在过。把层次反过来也可以；深思熟虑地选择，并在灾难日到来之前写好恢复文档。

远程控制台就是你的降落伞。ipmitool sol activate 能从任何地方唤出串行提示符；每当 initrd 闹脾气，IPMI 虚拟介质就能挂载一张救援镜像。在第一周就把完整的解锁流程演练一遍——断电重启、串行口提示、输入凭据、映射卷。一条从未走过的解锁路径，不过是披着操作手册外衣的迷信。

当启动链里必须不含任何第三方时，租一台 Forge：标价 $49/月，年付预付仅 $39.20/月，把同样的纪律应用到它的两块 1 TB 硬盘上。然后避开那个毁掉金属方案的典型错误：以“便于救援”为由让第二块盘保持明文，而镜像却忠实地把你的秘密复制到了那块未密封的盘上。要么两半都密封，要么镜像本身就是那道裂缝。

这就是完整的阶梯：备用卷上的容器、磁盘镜像里的容器、自有金属上密封的镜像。最后一节把每项决策按你实际遇到的顺序排好——开通、格式化、接线、演练——并为每一步附上验证命令。把它当作一件完整的工具来读，这个阶梯用便利性换取攻击面的收缩：每上一级台阶，就多排除一方接触秘密——先是存储，然后是启动路径本身。

加密实操：按执行顺序来

先选定形态，因为后面每一步都继承它。单块盘上的适度秘密集合：磁盘镜像变体。有备用卷可买可租：卷变体——入门切片的八十 GB 闪存正好对半分。要求启动链完全摆脱服务商：金属设备，直接跳到 initrd 那一步。一次坐下来把形态和它的备份方案一起定下来，因为日后迁移一个装满数据的容器会重写你的所有脚本。

构建只需四条命令，文件和卷皆然：luksFormat 写入封装层，open 映射它，mkfs.ext4 建好文件系统，mount 把它呈现出来。用 rsync 把秘密搬过去，抽样校验，然后退役源数据——从容器存在的那一刻起，它们就成了新的责任。校验不必穷尽；一次抽样 diff 加一次成功解锁的转储，就能抓住那些实际会发生的复制错误。

把这套动作接线接好，让重启只等你一个人。不要从启动盘拉取密钥材料的 crypttab 默认项；不要预设 mapper 已解锁的 fstab 条目。要么每次重启后亲自通过 SSH 解锁，要么跑一个等待你输入的单元——并且在内容还无所谓丢的时候强制重启一次，在任何珍贵的东西依赖它之前先证明这套流程。

趁一切正常时抓取加密头：备份命令、校验和、移出本机、标注日期。在草稿文件上演练一次恢复；此后每次凭据变更后重复一次。这一个习惯决定了损坏的加密头是花两分钟解决还是损失一切，而且它是本页上最便宜的保险。副本之间的校验和出现分歧本身就是一个发现——先查清楚再信任任何一份。

然后诚实地活在这条边界之内：密封容器的镜像可以安全传输；在解锁状态下拍摄的镜像会暴露当时躺在 /root 里的任何密钥材料；已启动的系统对它的 root 而言是透明的，无论用什么加密算法。当启动链必须完全排除第三方时，同一架阶梯就爬上金属设备——initrd 属于你，控制台留给紧急情况，解锁在第一周演练完毕。按顺序执行这些步骤，这个习惯能稳稳保持多年。