How do I unlock a LUKS-encrypted rented server remotely?

Why does remote unlock matter on a rented server?

Because an encrypted drive waits for its key at every boot, and nobody is at the screen. There is no IPMI or KVM-over-IP access for customers; reboots and reinstalls you request in the dashboard are carried out by the team.

So plan the unlock before you encrypt. On a hold, the operating system lives on its own SSD and the data drives come blank. That split makes the first method easy: keep the system plain, encrypt the drives that hold your data.

Encrypt the drives that hold your data; keep the boot path simple enough to fix over SSH.

How do I encrypt the data drives and unlock them after a reboot?

Format each data drive as LUKS2, open it, and build the array on the opened devices. The passphrase never touches the server's disk. After a reboot, the system comes up, you log in over SSH, and you open the drives again. The array choice on top is on ZFS or hardware RAID.

Services that use the pool wait until you do. An outside uptime check, or a script that alerts when the pool is missing, tells you a reboot happened.

apt install cryptsetup
# ZFS tools: zfsutils-linux and zfs-dkms from Debian contrib; built into Proxmox

# once per data drive: this erases it and asks for a passphrase
cryptsetup luksFormat --type luks2 /dev/disk/by-id/ata-MODEL_SERIAL01
cryptsetup open /dev/disk/by-id/ata-MODEL_SERIAL01 data01
# ...repeat for data02, data03, data04

zpool create -o ashift=12 tank raidz2 \
  /dev/mapper/data01 /dev/mapper/data02 /dev/mapper/data03 /dev/mapper/data04

# after every reboot: log in, open each drive, import the pool
cryptsetup open /dev/disk/by-id/ata-MODEL_SERIAL01 data01
# ...repeat for each drive
zpool import tank

Can ZFS native encryption replace LUKS?

Yes, per dataset. Create the dataset with encryption=on and a passphrase, then run zfs load-key and zfs mount after each reboot. No initramfs work is needed.

It hides less, though. The OpenZFS manual says ZFS does not encrypt pool-structure metadata: dataset and snapshot names, properties and file sizes stay readable. LUKS encrypts the whole drive, metadata included. Both are covered by the same promise: You can encrypt every data drive with LUKS or ZFS native encryption; the keys stay with you and nobody on the team ever asks for them.

How do I unlock the drives automatically with Clevis and Tang?

Run a Tang server on a machine you control elsewhere, and bind each drive to it. Clevis adds a new key slot to LUKS and stores the encrypted key in the LUKS header. At boot it asks Tang to help recover the key; your passphrase keeps working as before.

The Clevis manual says early-boot unlocking only covers the root volume. Data drives use the late-boot unlocker, which reads /etc/crypttab. On Debian, the clevis-systemd package unlocks devices marked _netdev there.

The drives open only while the storage server can reach your Tang server. Allow only the storage server's IP address through Tang's firewall. Drives that leave that network stay locked.

# on your Tang machine, not on the storage server
apt install tang
systemctl enable tangd.socket --now

# on the storage server
apt install clevis clevis-luks clevis-systemd
clevis luks bind -d /dev/disk/by-id/ata-MODEL_SERIAL01 tang '{"url": "http://TANG_ADDRESS"}'
# ...repeat for each data drive

# /etc/crypttab, one line per drive:
# data01  /dev/disk/by-id/ata-MODEL_SERIAL01  none  luks,_netdev

systemctl enable clevis-luks-askpass.path

# check the binding, or unlock by hand
clevis luks list -d /dev/disk/by-id/ata-MODEL_SERIAL01
clevis luks unlock -d /dev/disk/by-id/ata-MODEL_SERIAL01

How do I unlock an encrypted root with dropbear-initramfs?

Put a small SSH server, dropbear, into the initramfs. It starts before the root filesystem, you log in with your key, and cryptroot-unlock asks for the passphrase. Debian's cryptsetup guide describes this for headless systems.

The Debian README sets the rules. Keys go in /etc/dropbear/initramfs/authorized_keys, and password logins are off. Options go in /etc/dropbear/initramfs/dropbear.conf. The network driver must be in /etc/initramfs-tools/modules, and a static address is set with the kernel's ip= parameter. The same paths apply on Debian 12, Debian 13 and Ubuntu 24.04.

The initramfs uses its own host keys, so your SSH client warns about a changed key. Keep a separate known_hosts file for it, as the README suggests.

apt install dropbear-initramfs

# your public key, limited to the unlock command
echo 'no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock" ssh-ed25519 AAAA... you@laptop' \
  > /etc/dropbear/initramfs/authorized_keys

# listen on another port than the main SSH server
echo 'DROPBEAR_OPTIONS="-p 2222"' >> /etc/dropbear/initramfs/dropbear.conf

# static address in the initramfs: client::gateway:netmask::interface:off
# add to GRUB_CMDLINE_LINUX in /etc/default/grub, for example:
# ip=203.0.113.10::203.0.113.1:255.255.255.0::eno1:off
update-grub
update-initramfs -u -k all

# from your computer, at each boot
ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.initramfs [email protected]

What does encryption protect, and what not?

It protects drives that are locked: powered off, pulled for replacement, or left behind after a cancellation. That is when the host or anyone else holds the hardware without your key. What happens to drives after you leave is on data after cancellation.

While the server runs unlocked, the key sits in memory. Someone who logs in can still delete data; that risk is covered on immutable backups. For data that the server never needs to read, encrypt on your own machine before upload; see client-side encrypted backups.

Of 23 storage-server sellers Basalthold checked on 2 November 2026, 2 required ID before delivery and 12 could ask for it on triggers. Encryption protects the drives; No KYC: no ID, no selfie, no documents, no card and no phone number, at any point.