Wie entsperre ich einen LUKS-verschlüsselten gemieteten Server remote?

Warum ist Remote Unlock auf einem gemieteten Server wichtig?

Weil ein verschlüsseltes Laufwerk bei jedem Boot auf seinen Schlüssel wartet und niemand am Bildschirm ist. Für Kunden gibt es keinen IPMI- oder KVM-over-IP-Zugang; von Ihnen im Dashboard angeforderte Neustarts und Neuinstallationen werden vom Team ausgeführt.

Planen Sie das Entsperren also, bevor Sie verschlüsseln. Bei einem Hold liegt das Betriebssystem auf einer eigenen SSD und die Datenlaufwerke kommen leer. Diese Trennung macht die erste Methode einfach: Halten Sie das System unverschlüsselt und verschlüsseln Sie die Laufwerke, die Ihre Daten enthalten.

Verschlüsseln Sie die Laufwerke, die Ihre Daten enthalten; halten Sie den Boot-Pfad so einfach, dass er sich über SSH reparieren lässt.

Wie verschlüssele ich die Datenlaufwerke und entsperre sie nach einem Reboot?

Formatieren Sie jedes Datenlaufwerk als LUKS2, öffnen Sie es und bauen Sie das Array auf den geöffneten Geräten auf. Die Passphrase landet nie auf der Festplatte des Servers. Nach einem Reboot fährt das System hoch, Sie loggen sich über SSH ein und öffnen die Laufwerke erneut. Die Wahl des Arrays darüber steht auf ZFS oder Hardware-RAID.

Dienste, die den Pool nutzen, warten, bis Sie das tun. Eine externe Uptime-Prüfung oder ein Skript, das alarmiert, wenn der Pool fehlt, zeigt Ihnen, dass ein Reboot stattgefunden hat.

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

Kann ZFS native Verschlüsselung LUKS ersetzen?

Ja, pro Dataset. Erstellen Sie das Dataset mit encryption=on und einer Passphrase, führen Sie dann nach jedem Reboot zfs load-key und zfs mount aus. Es ist keine initramfs-Arbeit nötig.

Es verbirgt allerdings weniger. Das OpenZFS-Handbuch sagt, dass ZFS die Metadaten der Pool-Struktur nicht verschlüsselt: Dataset- und Snapshot-Namen, Eigenschaften und Dateigrößen bleiben lesbar. LUKS verschlüsselt das gesamte Laufwerk, Metadaten inklusive. Beides fällt unter dasselbe Versprechen: Sie können jedes Datenlaufwerk mit LUKS oder der nativen ZFS-Verschlüsselung verschlüsseln; die Schlüssel bleiben bei Ihnen, und niemand im Team fragt jemals danach.

Wie entsperre ich die Laufwerke automatisch mit Clevis und Tang?

Betreiben Sie einen Tang-Server auf einer Maschine, die Sie anderswo kontrollieren, und binden Sie jedes Laufwerk daran. Clevis fügt einen neuen Key-Slot zu LUKS hinzu und speichert den verschlüsselten Schlüssel im LUKS-Header. Beim Boot bittet es Tang, den Schlüssel wiederherzustellen; Ihre Passphrase funktioniert weiterhin wie zuvor.

Das Clevis-Handbuch sagt, dass Early-Boot-Unlocking nur das Root-Volume abdeckt. Datenlaufwerke nutzen den Late-Boot-Unlocker, der /etc/crypttab liest. Unter Debian entsperrt das Paket clevis-systemd Geräte, die dort mit _netdev markiert sind.

Die Laufwerke öffnen sich nur, solange der Storage-Server Ihren Tang-Server erreichen kann. Erlauben Sie in Tangs Firewall nur die IP-Adresse des Storage-Servers. Laufwerke, die dieses Netzwerk verlassen, bleiben gesperrt.

# 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

Wie entsperre ich ein verschlüsseltes Root mit dropbear-initramfs?

Legen Sie einen kleinen SSH-Server, dropbear, in die initramfs. Er startet vor dem Root-Dateisystem, Sie melden sich mit Ihrem Schlüssel an, und cryptroot-unlock fragt nach der Passphrase. Debian's cryptsetup-Anleitung beschreibt dies für Headless-Systeme.

Die Debian-README legt die Regeln fest. Schlüssel kommen in /etc/dropbear/initramfs/authorized_keys, und Passwort-Logins sind aus. Optionen kommen in /etc/dropbear/initramfs/dropbear.conf. Der Netzwerktreiber muss in /etc/initramfs-tools/modules sein, und eine statische Adresse wird mit dem ip=-Parameter des Kernels gesetzt. Dieselben Pfade gelten auf Debian 12, Debian 13 und Ubuntu 24.04.

Die initramfs verwendet eigene Host-Schlüssel, daher warnt Ihr SSH-Client vor einem geänderten Schlüssel. Führen Sie dafür eine separate known_hosts-Datei, wie die README vorschlägt.

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]

Was schützt Verschlüsselung, und was nicht?

Sie schützt Laufwerke, die gesperrt sind: ausgeschaltet, zum Austausch ausgebaut oder nach einer Kündigung zurückgelassen. Dann hält der Host oder jemand anderes die Hardware ohne Ihren Schlüssel. Was nach Ihrem Weggang mit den Laufwerken passiert, steht auf Daten nach Kündigung.

Solange der Server entsperrt läuft, liegt der Schlüssel im Speicher. Wer sich anmeldet, kann Daten weiterhin löschen; dieses Risiko ist auf immutable Backups abgedeckt. Für Daten, die der Server nie lesen muss, verschlüsseln Sie auf Ihrer eigenen Maschine vor dem Upload; siehe clientseitig verschlüsselte Backups.

Von 23 Storage-Server-Anbietern, die Basalthold am 2 November 2026 geprüft hat, verlangten 2 vor der Lieferung einen Ausweis und 12 konnten ihn bei bestimmten Auslösern anfordern. Verschlüsselung schützt die Laufwerke; Kein KYC: keine ID, kein Selfie, keine Dokumente, keine Karte und keine Telefonnummer, zu keinem Zeitpunkt.