VPSCrypto
租用服务器时加密的理由，比营销话术说的要窄，但在这个窄范围内，理由却硬得多。NVMe 硬盘会坏，坏了就带着你的数据一起退回供应商。节点会被淘汰下线，存储设备被转卖。硬件会被镜像复制，或者直接从机架上被搬走。在这些情况下，LUKS 决定的就是：文件系统是可读的 — 你的密钥、你的数据库、你的邮件队列 — 还是一堆谁也拿它没办法的乱码。
它做不到的，是防住你正在运行的这台机器本身。这个区别就是本文的核心，所以要先讲清楚，再谈任何一条命令。然后才是具体工作：正确建立一个 LUKS2 卷、备份卷头、加密 swap、通过 SSH 远程解锁，以及万一重启后机器再也起不来时的恢复方案。你脚下这台机器本身可以无需身份证明租用，也可以用门罗币支付；加密是加在这之上的一层，不是替代品。
静态加密实际保护的是什么
全盘加密只回答一个问题，而且回答得很彻底：当磁盘断电后落到别人手里，会发生什么？在租用的基础设施上，这不是假设。硬盘会坏，坏了退回供应商。节点会被淘汰下线，存储设备被转卖。卷会在调查过程中被镜像复制，或者装进箱子搬出大楼。
- 能防住的。断电的磁盘、卷的离线镜像、保修退回的硬盘、被淘汰下线的节点、被复制走的快照文件。这些情况下，攻击者拿到的都是密文和卷头，没有密码短语，故事就到此为止。
- 防不住：正在运行的机器。卷一旦被打开，密钥就在内核内存里，文件系统对任何拿到 root 权限的人都是明文。
- 防不住：你的流量。线路上的数据是 TLS 和 WireGuard 该管的事，LUKS 根本看不到它们。
- 防不住：被攻破的 root 账户。已经潜入进来的入侵者，会通过和你一样的挂载点读你的文件。这正是加固要解决的问题，这两道防线互不能替代。
这份清单故意列得很短。静态加密是一项便宜、高价值、范围划得很精确的控制手段，而人们对它的失望，几乎都是因为暗自指望它也能顺带把另外三条线也一并防住。
租用硬件这件事，把话说清楚
你的加密卷一旦被打开，密钥就在客户机的内存里 — 而且不管在哪个地方的 VPS 上，这块内存都在运营商实际控制的机器上。虚拟化管理程序（hypervisor）能读取客户机内存。这不是 LUKS 的缺陷，也不是 KVM 的缺陷，更不是这家主机商特有的问题；这就是租用一台计算机的本质含义，凡是告诉你并非如此的服务商，说的都是一款并不存在的产品。
所以账要算得直白：静态加密能把离线攻击变得不可能，却让在线攻击原地踏步。一块离开机架的硬盘会变得一文不值。一台正在运行的服务器，暴露程度和昨天相比毫无变化。这句话的两半同时成立，一份只告诉你前一半的指南，算不上帮了你的忙。
真正能改变第二种风险的，是另一套控制手段，它们叠加在加密之上，而不是取代加密。这里没有档案可以被披露，因为这里的注册无需 KYC — 只需要一个用来接收凭据的邮箱，仅此而已。付款在链上结算，而不经过银行。主机所在的司法辖区，则决定了究竟有哪些命令能强制到什么。我们那篇关于加密货币付款 VPS 到底隐藏了什么的诚实说明讲清楚了剩下的部分，“十四只眼”词条则讲清楚了情报共享那一面。把 LUKS 当成众多防线中的一层，它物超所值；把它当成挡住你自己主机商的盾牌，那就是一种误解。
数据卷还是根文件系统：先选定，再动手
这件事有两种做法，选哪种取决于风险，而不是取决于强度。
- 加密数据卷。在操作系统旁边放一个 LUKS 容器。所有要紧的东西 — 数据库、邮件、密钥、上传文件、备份 — 都放在里面；操作系统本身仍是明文。只需十分钟，完全没有引导风险，而且随时可以撤销。大多数读者应该做的就是这个，下面的步骤也是照这个来的。
- 加密根文件系统。所有东西都在里面，包括日志、软件包列表，还有你早就忘了的 shell 历史记录。强度确实更高，但要用到一台已经在运行的机器上，也确实更难。
难在哪里，值得说清楚，因为没有哪篇教程会讲：你没法加密一个当前以读写方式挂载、还在支撑你这个 SSH 会话的文件系统。两种真正可行的方法 — 缩小再复制，或者原地用 cryptsetup reencrypt — 都需要根文件系统先离线。在带外置控制台的机器上，启动一个安装程序就行，很常规。但在无显示器的 VPS 上，你得先把正在运行的系统切到一个内存盘里，这个过程只要有一步出错，机器就再也起不来，唯一的恢复办法就是重装，而重装会把磁盘清空。
所以：今天就建好数据卷，把所有要紧的东西放进去，至于加密根文件系统，留到部署阶段、机器上还没有任何值得损失的东西时再决定。最后一节会讲这条路线，包括如何用 dropbear-initramfs 在启动时通过 SSH 输入密码短语。
开始之前，你需要准备什么
要准备的不多，这也是这件事值得做的部分原因。
- 一个套餐。加密不额外占用内存，也几乎不占用 CPU。Cub（1 vCPU / 2 GB / 40 GB NVMe，$5.00/mo）就够用；如果机器上还要跑真正的业务，Scout（2 vCPU / 4 GB / 70 GB，$9.00/mo）会更宽裕。唯一要紧的数字是磁盘容量，因为加密卷是从里面切出来的。
- 从模板库选 Debian 12 或 13，或者 Ubuntu LTS — 下面的命令是 Debian 风格的，其他系统的包名会不一样。部署大约一分钟，完整的 KVM 虚拟化意味着一个带
dm-crypt模块的真实内核，而不是借用别人内核的容器。 - 先花十分钟做好基础加固。在一台还能用密码登录的机器上做加密，就像给一扇没有门框的门装锁。
- 一个没在别处用过的密码短语，要生成而不是自己编，存在一个即使你丢了这台机器也还在的地方。没有找回机制，没有重置，也没有哪张支持工单能帮上忙。
- 机器之外找个地方存放卷头备份。每个套餐都自带每周快照，但加密卷的快照本身仍然是加密的 — 对回滚有用，密码短语丢了就没用。
位置对这些都没有影响，所以可以只按价格或司法辖区来选：Amsterdam、Paris、Bucharest 和 Sofia 是基础价，Zurich、Reykjavik、Stockholm 和 Kuala Lumpur 则要加价。
分步操作
- 部署、加固，并确认 CPU 支持 AES-NI
从模板库部署 Debian 13，先花十分钟做好基础加固：只用 SSH 密钥登录、禁用 root 密码登录、nftables 默认拒绝、开启无人值守安全更新。然后确认硬件不会让你为这件事多付出代价：
grep -o -m1 ' aes ' /proc/cpuinfo apt update && apt install -y cryptsetup cryptsetup benchmark你要找的是每秒好几个 GB 这个量级的
aes-xts数字。近十年任何一款 x86-64 服务器 CPU 都带 AES-NI，所以加密不会是你的瓶颈 — 瓶颈会一如既往地落在底下的 NVMe 上。 - 为加密卷腾出空间
如果你的套餐磁盘上还有未分区的空间，就用它 — 一个真正的分区是最干净的加密对象：
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT sgdisk -n 0:0:0 -c 0:secure /dev/vda partprobe /dev/vda如果模板已经把磁盘占满了，不必和它较劲。文件承载的容器在这里同样是一等公民，在 NVMe 上完全不损失吞吐量，之后也能扩容：
fallocate -l 20G /var/lib/secure.img chmod 600 /var/lib/secure.img losetup --find --show /var/lib/secure.img记下它打印出来的那个 loop 设备 — 通常是
/dev/loop0。下文所有地方写的都是/dev/disk/by-partlabel/secure；如果你走的是容器这条路，就把它替换成你自己的 loop 设备。 - 将它格式化为 LUKS2——并设定内存开销上限
这条命令决定了一切，所以值得认真读一遍，而不是直接复制粘贴：
cryptsetup luksFormat --type luks2 \ --cipher aes-xts-plain64 --key-size 512 \ --pbkdf argon2id --pbkdf-memory 262144 --iter-time 5000 \ /dev/disk/by-partlabel/secure--key-size 512是 XTS 模式下的 AES-256，它把密钥一分为二 — 而不是什么 AES-512，那种东西根本不存在。--pbkdf argon2id是一种耗内存的密钥派生算法，让暴力破解你的密码短语在内存和 CPU 上都变得代价高昂。--pbkdf-memory 262144把这个开销上限设在 256 MB，而这正是人们经常漏掉、之后又后悔的一行。如果不管它，cryptsetup会按格式化那一刻可用的内存去调整开销大小。之后如果在内存更小的地方解锁同一个卷头 — 比如 1 GB 的套餐、救援环境，或者 initramfs — 就可能直接失败。所以要主动设上限。 - 打开它、建文件系统、挂载它
cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \ --allow-discards open /dev/disk/by-partlabel/secure secure mkfs.ext4 -L secure /dev/mapper/secure mkdir -p /srv/secure mount -o noatime /dev/mapper/secure /srv/secure df -h /srv/secure这两个 workqueue 参数只在 NVMe 上才有意义，别的地方都无所谓；
--allow-discards能让 TRIM 继续生效，代价是会让任何拿到这块断电磁盘的人看出哪些块在用。下文还会详细讨论这两个参数 — 对一台通用服务器来说，上面这组默认值就是对的。 - 把 LUKS 头备份到机器之外
现在就做这件事，趁卷里还没有什么值得损失的东西。卷头大约是 16 MB 的元数据，存着密钥槽，一旦卷头损坏，不管你把密码短语记得多牢，密文都无法恢复：
cryptsetup luksHeaderBackup /dev/disk/by-partlabel/secure \ --header-backup-file /root/secure-header.img sha256sum /root/secure-header.img把它复制到别处 — 用
scp传下去，存进密码管理器，或者打印出哈希值 — 然后删掉本地这一份。把这个文件当成和密码短语等价的东西来对待，因为只要配上它曾经持有过的任何一个密码短语，它确实就是。 - 把重要数据搬到加密卷上
一个没有任何东西往里写的加密卷，什么也保护不了。先停服务，把它的状态数据搬过去，再把旧路径绑定挂载回去，这样其他地方就都不用改配置了：
systemctl stop postgresql rsync -aHAX --info=progress2 /var/lib/postgresql/ /srv/secure/postgresql/ mv /var/lib/postgresql /var/lib/postgresql.old mkdir /var/lib/postgresql echo '/srv/secure/postgresql /var/lib/postgresql none bind 0 0' >> /etc/fstab mount /var/lib/postgresql systemctl start postgresql确认服务恢复正常之后，再考虑用
shred清除或者删掉.old目录 — 而且要记住，在写时复制（copy-on-write）文件系统上，或者带磨损均衡的 NVMe 上，删除明文并不等于真正销毁它。这件事干净的做法，是先建好加密卷，再让服务存在。 - 决定它怎么解锁，并对这个选择保持诚实
这里是每个人都会遇到的分岔口。把这个卷加进
/etc/crypttab，带上noauto，这样它就不会卡住启动流程，需要用的时候再通过 SSH 手动解锁：echo 'secure /dev/disk/by-partlabel/secure none \ luks,noauto,discard,no-read-workqueue,no-write-workqueue' >> /etc/crypttab cryptdisks_start secure这是诚实的配置：密钥只在你在场的时候存在，重启之后这个卷会保持关闭状态，直到你亲自开口。代价是无人值守的重启，回来之后服务是停着的。
另一种做法，是在
/etc/crypttab里放一个密钥文件，让卷自动打开。如果这个密钥文件和卷放在同一块磁盘上，你其实什么都没加密 — 谁拿到这块断电的硬盘，谁就把钥匙和锁一起拿走了。只有当密钥来自磁盘之外的某个地方时，这个做法才有意义：比如启动时通过 WireGuard 隧道获取，或者像上一节那样通过 SSH 输入到 initramfs 里。要主动做出选择；默认的手动解锁，才是名副其实的那一个。 - 加密 swap，并验证整套配置
内存会以 swap 的形式变成磁盘上的痕迹，所以一个加密卷旁边摆着明文的 swap，泄露的正是你本来想保护的那些秘密。每次启动用一个随机密钥，是正确答案 — 不用管理，也没什么可丢的。先执行
swapon --show确认现状，再替换成你自己的设备；如果模板给你的是 swap 文件而不是分区，就把它删掉，换成一个小分区，因为随机密钥设备要用的是块设备：swapoff -a sed -i '/swap/s/^/#/' /etc/fstab echo 'swap /dev/vda3 /dev/urandom \ swap,cipher=aes-xts-plain64,size=512' >> /etc/crypttab echo '/dev/mapper/swap none swap sw 0 0' >> /etc/fstab然后重启 — 趁现在出错的代价还很低 — 老老实实检查一下结果：
lsblk -o NAME,FSTYPE,MOUNTPOINT cryptsetup status secure blkid /dev/disk/by-partlabel/secure # should say crypto_LUKS swapon --show # should show /dev/mapper/swap真正说明问题的测试是：在卷关闭的状态下，确认
/srv/secure是空的，而且依赖它的服务会拒绝启动。如果这两点都成立，这份加密就是真的，而不是摆设。
密钥槽、卷头，以及你轮换过的那个密码短语
LUKS2 最多能保留 32 个密钥槽。每个槽里存的都是同一把主密钥的副本，只是用不同的密码短语包裹，这也是为什么你可以另外添加一个密码短语，而不用重新加密任何东西：
cryptsetup luksAddKey /dev/disk/by-partlabel/secure
cryptsetup luksDump /dev/disk/by-partlabel/secure | grep -A2 '^Keyslots'
cryptsetup luksKillSlot /dev/disk/by-partlabel/secure 1一开始就设两个密码短语才是正确的默认做法：一个自己用，另一个写下来存在别处。因为密码管理器里的一个笔误就彻底失去一个卷的唯一访问权限，是人们弄丢 LUKS 数据最常见的方式，比对手做的任何事都常见得多。
现在说说这个陷阱。在你轮换密码短语之前做的卷头备份，用旧密码短语依然能打开这个卷。密钥槽存在卷头里，所以一份旧的卷头，就是一份旧的密钥槽 — 底下那把主密钥从来没变过。如果你轮换密码短语是因为它可能已经泄露，那就必须把轮换之前的每一份卷头备份都销毁，再重新做一份。不然这次轮换除了让你自己感觉好一点，什么也没改变。
同样的事实，也让卷头备份本身变得敏感：那个 16 MB 的文件，加上它曾经认得的任何一个密码短语，就足以解密这个卷。存放它的地方，应该和存放密码短语的地方一样，而不是和你存放快照的地方一样。
性能：AES-NI、NVMe，以及两个值得了解的参数
cryptsetup benchmark 大约十五秒就能告诉你，你这颗 vCPU 的真实情况。任何带 AES-NI 的 CPU — 也就是近十年任何一款 x86-64 服务器处理器 — 跑 aes-xts 都能达到每秒好几个 GB，比底下的 NVMe 快得绰绰有余。实际工作负载里的开销是百分之个位数，而且瓶颈在 CPU，不在延迟。
有两个 cryptsetup 选项只在快速存储上才要紧，也只在快速存储上才要紧：
cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \
--allow-discards open /dev/disk/by-partlabel/secure secure这两个 workqueue 参数会绕开 dm-crypt 内部的队列，把 I/O 直接交给设备。在机械硬盘上它们什么都不改变；在 NVMe RAID10 上，它们能在高队列深度时消除一个实实在在的瓶颈。把它们写进 crypttab 的选项行，写成 no-read-workqueue,no-write-workqueue，就能永久生效。
--allow-discards 则是有取舍的那一个。它把 TRIM 命令透传给 NVMe，能让写入性能长期保持住 — 但也会让任何拿到这块断电磁盘的人看出哪些块在用、哪些是空的。这是一种真实存在的信息泄露，虽然程度不大：它会暴露这个卷大致有多满，还可能暗示文件系统的结构。在一台通用服务器上，选性能就好。但如果卷里存的东西，连它的大小都算敏感信息，那就别开 discard。
根文件系统这条路线，以及通过 SSH 远程解锁
如果你想把所有东西都加密，那就在一台还什么都没有的机器上做 — 先部署，再转换，然后才开始搭建。转换过程本身是标准套路：先在离线状态下缩小根文件系统，在腾出来的空间里建一个 LUKS2 容器，用 rsync -aHAX 把系统复制过去，把 /etc/fstab 和 /etc/crypttab 指向映射设备，再执行 update-initramfs -u -k all 并重装 GRUB。真正让这件事在无显示器 VPS 上变得棘手的，是离线状态下这几个字：没有控制台要做到这一点，就得先把正在运行的系统切换到一个内存根文件系统里，而这一步一旦出错，结局就是重装。
让加密根文件系统在远程机器上还能用得起来的，是 dropbear-initramfs — 一个体积大约 200 KB、直接内置在启动镜像里的 SSH 服务器，在内核等待密码短语时负责监听：
apt install dropbear-initramfs cryptsetup-initramfs
# Debian 12/13: /etc/dropbear/initramfs/
cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys
echo 'DROPBEAR_OPTIONS="-I 300 -j -k -p 2222 -s -c cryptroot-unlock"' \
>> /etc/dropbear/initramfs/dropbear.conf
echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
update-initramfs -u -k all启动过程中，你执行 ssh -p 2222 root@your-ip，被强制调用的 cryptroot-unlock 命令就会问你要密码短语。在依赖它之前，有三件事值得了解。initramfs 有自己的一套主机密钥，所以你的客户端会在 2222 端口报告密钥不匹配的警告 — 这是预期之中的，也正是要给它单独分配一个端口的原因。这个主机密钥和你的 authorized_keys，都放在一个未加密的启动分区上，任何拿到这块磁盘的人都能读到，所以解锁密钥要专用，别干别的事。而 -s 会禁用 initramfs 里的密码登录，这一点没有商量余地。
另一个在小套餐上容易踩坑的细节，和第三步是同一个问题，而且在这里踩得最狠。initramfs 运行的时候，你大部分内存都还用不上，所以一个用较大 Argon2id 内存开销格式化出来的卷头，可能在创建它的那台机器上都解不开。格式化时用 --pbkdf-memory 设个上限，并且趁现在还没什么可损失的时候，测试一次重启。
日常运维：什么变了，什么没变
变化很小，这正是重点所在。一个已打开的 LUKS 卷就是个普通的块设备；fsck、rsync、df 和你的备份工具，行为都和以前一模一样。内核升级不受影响，因为 dm-crypt 就在内核树里。升级套餐后扩容这个卷，只需要两条命令 — 先 cryptsetup resize，再做文件系统自己的扩容 — 完全不需要重新加密。
有三个习惯值得养成。定期演练重启，别等到凌晨三点才发现，那个你从没写下来的密码短语是唯一的一份。让备份独立加密 — 用 restic 或 borg 备份到异地目标，这是一道独立于该卷之外的防线，即便整台机器都丢了也还在；如果不想自己搭，每天异地备份的附加服务是 $2.00/mo。以及在不再关心这台机器之前先关闭这个卷：在计划中的关机、迁移或重装之前执行 cryptsetup close secure，能让密钥在磁盘不再属于你之前，先从内存里消失。
在政策上，这没什么好商量的。你在 KVM 客户机上拥有完整的 root 权限，怎么处理块设备层是你自己的事；加密自己的卷是再普通不过的系统管理工作，不是什么特殊情况。可接受使用政策约束的是行为 — 底线是不许有 CSAM、不许涉恐 — 跟 dm-crypt 没有任何关系。加密真正改变的，是一个假想的倒霉日子的样子：一块离开这栋大楼、已经断电的卷，只是一堆噪声，这就值得你花上十分钟。
常见问题
全盘加密能阻止我的主机商读取我的数据吗？
服务器运行的时候不能。卷一旦解锁，密钥就在客户机的内存里，而在任何 VPS 上，这块内存都在运营商控制的硬件上 — 虚拟化管理程序是能读到它的。LUKS 能彻底做到的，是让断电的磁盘变得毫无价值：退回供应商的硬盘、被淘汰下线的节点、离线镜像。任何把磁盘加密宣传成能防住你自己主机商的说法，说的都是一个并不存在的东西。
没有控制台或 KVM-over-IP 访问权限的 VPS，能加密吗？
加密数据卷可以 — 完全通过 SSH 完成，没有引导风险，大约十分钟。加密根文件系统则不一样：任何方法都需要先让根文件系统离线，而在无显示器的机器上，这意味着要先把正在运行的系统切换到一个内存盘里。这个办法确实可行，但也是人们弄丢服务器的常见原因。请在部署阶段、机器上还什么都没有的时候做这个转换，并用 dropbear-initramfs，这样就能在启动时通过 SSH 输入密码短语。
LUKS 实际会带来多大的性能损耗？
在任何带 AES-NI 的 CPU 上都是百分之个位数，也就是说，任何现代 x86-64 vCPU 都是如此。执行 cryptsetup benchmark，你会看到 aes-xts 达到每秒好几个 GB — 比它所在的 NVMe 还快，所以瓶颈始终在存储上。在高速磁盘上，--perf-no_read_workqueue 和 --perf-no_write_workqueue 能在高队列深度时把剩下的性能差距补回大半。
如果我丢了密码短语会怎样？
数据就没了。没有恢复机制，没有别人手里握着的主密钥，也没有哪张支持工单能帮上忙 — 你买的就是这个特性。提前做好防范：用 cryptsetup luksAddKey 在另一个密钥槽里加一个备用密码短语，并把卷头备份存到机器之外。注意，在密码短语轮换之前做的卷头备份，依然能用旧密码短语打开这个卷，所以轮换的时候要把过期的备份都销毁。
运行加密卷需要用哪个 VPS 套餐？
加密不额外占用内存，也几乎不占用 CPU，所以该选哪个档位，取决于你的业务负载，而不是取决于 LUKS。Cub（1 vCPU / 2 GB / 40 GB NVMe，$5.00/mo）跑一个加密卷都感觉不到；如果机器还要跑数据库或邮件服务器，Scout（2 vCPU / 4 GB / 70 GB，$9.00/mo）会更宽裕。唯一真正的限制是磁盘，因为卷是从里面切出来的。
在你们的套餐上加密自己的服务器，是被允许的吗？
swap 也需要加密吗？
需要，而且这是大多数教程都会跳过的一步。内核内存 — 包括密钥和已解密的缓冲区 — 最终都会以 swap 的形式变成磁盘上的痕迹，所以加密卷旁边摆一个明文 swap，泄露的正是你想保护的东西。通过 /etc/crypttab 让每次启动都用一个随机密钥：不用管理，也没什么可丢的。这样做的后果是无法休眠，而在 VPS 上，这不会让你损失什么。
