Hoe ontgrendel ik een LUKS-versleutelde gehuurde server op afstand?

Waarom is remote unlock belangrijk op een gehuurde server?

Omdat een versleutelde drive bij elke boot op zijn sleutel wacht, en niemand achter het scherm zit. Er is geen IPMI- of KVM-over-IP-toegang voor klanten; reboots en herinstallaties die je in het dashboard aanvraagt, worden door het team uitgevoerd.

Plan de ontgrendeling dus voordat je versleutelt. Op een hold staat het besturingssysteem op een eigen SSD en komen de datadrives leeg. Die splitsing maakt de eerste methode eenvoudig: houd het systeem onversleuteld, versleutel de drives die je data bevatten.

Versleutel de drives die je data bevatten; houd het opstartpad simpel genoeg om via SSH te herstellen.

Hoe versleutel ik de datadrives en ontgrendel ik ze na een reboot?

Formatteer elke datadrive als LUKS2, open hem en bouw de array op de geopende devices. De passphrase komt nooit op de schijf van de server terecht. Na een reboot komt het systeem op, log je in via SSH en open je de drives opnieuw. De array-keuze daarboven staat in ZFS of hardware-RAID.

Diensten die de pool gebruiken wachten tot je dat doet. Een externe uptime-check, of een script dat alarm slaat wanneer de pool ontbreekt, vertelt je dat er een reboot is geweest.

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

Kan ZFS native encryption LUKS vervangen?

Ja, per dataset. Maak de dataset aan met encryption=on en een passphrase, en voer na elke reboot zfs load-key en zfs mount uit. Er is geen initramfs-werk nodig.

Het verbergt wel minder. De OpenZFS-handleiding zegt dat ZFS metadata over de poolstructuur niet versleutelt: namen van datasets en snapshots, properties en bestandsgroottes blijven leesbaar. LUKS versleutelt de hele drive, metadata inbegrepen. Beide vallen onder dezelfde belofte: Je kunt elke dataschijf versleutelen met LUKS of native ZFS-encryptie; de sleutels blijven bij jou en niemand in het team vraagt er ooit naar.

Hoe ontgrendel ik de drives automatisch met Clevis en Tang?

Draai een Tang-server op een machine die je elders beheert, en bind elke drive eraan. Clevis voegt een nieuwe keyslot toe aan LUKS en bewaart de versleutelde sleutel in de LUKS-header. Bij het opstarten vraagt hij Tang om de sleutel te helpen herstellen; je passphrase blijft gewoon werken.

De Clevis-handleiding zegt dat ontgrendelen tijdens early boot alleen het root-volume dekt. Datadrives gebruiken de late-boot-unlocker, die /etc/crypttab leest. Op Debian ontgrendelt het pakket clevis-systemd daar devices die gemarkeerd zijn met _netdev.

De drives openen alleen zolang de opslagserver je Tang-server kan bereiken. Sta alleen het IP-adres van de opslagserver door in de firewall van Tang. Drives die dat netwerk verlaten, blijven vergrendeld.

# 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

Hoe ontgrendel ik een versleutelde root met dropbear-initramfs?

Plaats een kleine SSH-server, dropbear, in de initramfs. Die start voordat het root-bestandssysteem er is, je logt in met je sleutel en cryptroot-unlock vraagt om de passphrase. De cryptsetup-gids van Debian beschrijft dit voor headless systemen.

De README van Debian stelt de regels. Sleutels gaan in /etc/dropbear/initramfs/authorized_keys en aanmelden met een wachtwoord staat uit. Opties gaan in /etc/dropbear/initramfs/dropbear.conf. De netwerkdriver moet in /etc/initramfs-tools/modules staan en een statisch adres stel je in met de kernelparameter ip=. Dezelfde paden gelden op Debian 12, Debian 13 en Ubuntu 24.04.

De initramfs gebruikt eigen host keys, dus je SSH-client waarschuwt dat de sleutel is veranderd. Houd daarvoor een apart known_hosts-bestand bij, zoals de README aanraadt.

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]

Waartegen beschermt encryptie wel, en waartegen niet?

Het beschermt schijven die op slot zijn: uitgeschakeld, eruit gehaald voor vervanging of achtergelaten na een opzegging. Dan heeft de host of wie dan ook de hardware zonder jouw sleutel. Wat er met schijven gebeurt nadat je weggaat, staat op data na opzegging.

Zolang de server ontgrendeld draait, staat de sleutel in het geheugen. Iemand die inlogt kan nog steeds data verwijderen; dat risico staat op immutable backups. Voor data die de server nooit hoeft te lezen, versleutel je op je eigen machine voordat je uploadt; zie client-side versleutelde backups.

Van 23 verkopers van storage-servers die Basalthold op 2 November 2026 controleerde, vroegen 2 een ID vóór levering en 12 konden erom vragen bij bepaalde triggers. Encryptie beschermt de schijven; Geen KYC: geen ID, geen selfie, geen documenten, geen kaart en geen telefoonnummer, op geen enkel moment.