Einen VPS zu verschlüsseln wirkt wie ein Einzeiler – cryptsetup luksFormat, fertig – und liefert dann still und leise nicht das, was die meisten erwartet hatten. Auf einer gemieteten Maschine sitzt ein Hypervisor unterhalb Ihres Kernels, das Bedrohungsmodell ist also nicht dasselbe, für das Festplattenverschlüsselung ursprünglich entworfen wurde. Dieser Guide ist die ehrliche Version: was LUKS auf einem VPS wirklich abwehrt, was nicht, die zwei Bereitstellungswege, die funktionieren, und wie Sie ein verschlüsseltes Root-Dateisystem über SSH entsperren, damit Sie nie aus Ihrem eigenen Server ausgesperrt sind.
Was Verschlüsselung auf einem gemieteten Server wirklich bringt
Festplattenverschlüsselung schützt Daten im Ruhezustand. Diese Formulierung steckt voller Annahmen, und bei einem VPS lohnt es sich, genau zu klären, welche Momente als Ruhezustand zählen und welche nicht – genau in dieser Lücke zerbrechen die meisten Erwartungen.
Ausgemusterte Hardware
Laufwerke fallen aus, werden ersetzt und verlassen das Rack. Ein LUKS-Volume auf einer toten Festplatte ist für jeden, der sie als Nächstes in die Hand nimmt, nur ein Block aus Rauschen. Verschlüsselung löst diesen Fall vollständig.
Ein abgetrenntes oder kopiertes Volume
Wird ein Volume von Ihrer Instanz getrennt, geklont oder bei ausgeschalteter Maschine als Image gesichert, ist das Ergebnis Chiffretext und ein Header – nicht Ihre Dateien.
Eine laufende Maschine
Sobald das Volume geöffnet ist, liegt der Master-Key im Kernel-Speicher. Zugriff auf Hypervisor-Ebene kann ihn prinzipiell erreichen. Verschlüsselung erhöht hier die Kosten, verschließt aber nicht die Tür.
Ihre eigenen Fehler
Unverschlüsselter Swap, Klartext-Backups und Logs, die vor dem Mount geschrieben werden, liegen alle außerhalb des Containers. Die meisten echten Lecks bei verschlüsselten Servern passieren hier, nicht über die Chiffre.
Sprechen Sie die Grenze offen aus, damit Sie darum herum planen können: Solange das Volume entsperrt ist, liegt der Schlüssel im RAM auf Hardware, die Ihnen nicht gehört. LUKS auf einem VPS ist eine starke Antwort auf Offline-Zugriff und nur eine teilweise auf Live-Zugriff. Kombinieren Sie es mit einer Jurisdiktion, der Sie wirklich vertrauen — siehe /offshore-hosting — statt es als Ersatz dafür zu behandeln.
Die Form wählen, bevor Sie einen Befehl eintippen
Vier Anordnungen decken fast jede reale Anforderung ab. Die falsche zu wählen kostet eine Neuinstallation – entscheiden Sie sich also hier und nicht erst auf halbem Weg.
Weg A — ein Datenvolume auf einem bereits laufenden Server verschlüsseln
Das ist die Version, die die meisten eigentlich wollen: zehn Minuten Arbeit, keine Neuinstallation, und alles Wichtige landet am Ende im Container. Hängen Sie zuerst ein zweites Volume an — bei einem Plan auf /storage ist das die große Festplatte, bei einem gewöhnlichen /vps können Sie beim Deployment eines hinzufügen.
- 1
Zielgerät identifizieren
Führen Sie lsblk aus und bestätigen Sie, dass das Gerät, das Sie gleich formatieren, das leere ist. luksFormat zerstört alles darauf, und es gibt kein Zurück.
- 2
Den LUKS2-Container anlegen
cryptsetup luksFormat --type luks2 /dev/vdb verlangt, dass Sie YES in Großbuchstaben eintippen, und dann eine Passphrase festlegen. Wählen Sie eine, die Sie auch auf einer Konsole ohne History und ohne Echo fehlerfrei erneut eintippen können.
- 3
Öffnen und ein Dateisystem anlegen
cryptsetup open /dev/vdb cryptdata legt /dev/mapper/cryptdata an. Dann mkfs.ext4 /dev/mapper/cryptdata, und mounten Sie es dort, wo die Daten liegen sollen, zum Beispiel unter /srv/data.
- 4
Entscheiden, wie beim Boot entsperrt wird
Entweder geben Sie die Passphrase nach jedem Neustart ein, oder Sie fügen mit cryptsetup luksAddKey eine Keyfile hinzu und lagern sie auf Root. Die Keyfile ist bequem und strikt schwächer — machen Sie sich klar, welchen Kompromiss Sie eingehen.
- 5
crypttab und fstab verdrahten
Tragen Sie die Zuordnung mit UUID= statt eines Gerätenamens in /etc/crypttab ein, und mounten Sie dann über /etc/fstab mit nofail, damit ein fehlgeschlagenes Entsperren den Boot nie blockiert.
Liegt die Keyfile auf dem unverschlüsselten Root, seien Sie präzise darin, was Sie tatsächlich haben: Das Volume ist gegen eine Festplatte geschützt, die das Rack verlässt oder von Ihrer Instanz getrennt wird — nicht aber gegen eine Kopie der gesamten VM, denn diese Kopie enthält den Schlüssel gleich mit. Alles Stärkere verlangt, dass die Passphrase von außerhalb des Servers kommt.
Weg B — ein verschlüsseltes Root von einem eigenen ISO
Wenn die Anforderung lautet, dass bei ausgeschalteter Maschine nichts Lesbares existieren darf, muss Root selbst innerhalb von LUKS liegen. Das bedeutet eine Neuinstallation über die Konsole, bei einem Anbieter, der das Booten eines eigenen ISO erlaubt.
- 1
Den Installer über die Konsole booten
Hängen Sie ein Debian- oder Ubuntu-netinst-ISO als eigenes ISO ein und führen Sie die Installation über VNC oder Serial durch. Nichts davon funktioniert über SSH — es gibt noch kein System, mit dem Sie sich verbinden könnten.
- 2
Geführte Partitionierung mit verschlüsseltem LVM verwenden
Der Installer lässt ein kleines /boot unverschlüsselt, weil etwas laufen muss, bevor das Volume sich öffnet, und legt Root und Swap gemeinsam in einen LUKS-Container.
- 3
Eine Passphrase wählen, die Sie blind tippen können
Sie geben sie bei jedem Neustart über SSH erneut ein, ohne Echo und ohne Autovervollständigung. Eine Passphrase aus fünf Wörtern schlägt hier jeden Zeichensalat.
- 4
Remote-Entsperren einrichten, bevor Sie sich ausloggen
Ein frisch verschlüsseltes Root bleibt nach dem nächsten Neustart auf unbestimmte Zeit an der Passphrase-Eingabe hängen. Richten Sie das Remote-Entsperren noch in derselben Sitzung ein, solange die Konsole noch vor Ihnen liegt.
Bei Plänen mit 1–2 GB RAM kann die standardmäßige Argon2id-Schlüsselableitung mehr Speicher anfordern, als die initramfs hat, sodass das Entsperren beim Boot scheitert, obwohl die Passphrase stimmt. Begrenzen Sie das bereits beim Formatieren mit cryptsetup luksFormat --pbkdf-memory 262144, oder prüfen Sie einen bestehenden Header mit cryptsetup luksDump, bevor Sie einer kleinen Instanz einen unbeaufsichtigten Neustart zutrauen.
Remote-Entsperren über SSH mit dropbear-initramfs
Ein verschlüsseltes Root braucht eine Passphrase, bevor das Betriebssystem überhaupt existiert. dropbear-initramfs steckt einen winzigen SSH-Server in die initramfs, sodass Sie die Passphrase von überall liefern können — der Unterschied zwischen einem verschlüsselten Server und einem verschlüsselten Ziegelstein.
- 1
Das Paket installieren
apt install dropbear-initramfs. Es klinkt sich in die initramfs-Erzeugung ein und wird automatisch in jedes künftige Kernel-Image eingebaut.
- 2
Einen Key autorisieren, und nur einen Befehl
Tragen Sie Ihren Public Key in /etc/dropbear/initramfs/authorized_keys ein — unter Debian 11 und älter in /etc/dropbear-initramfs/authorized_keys. Stellen Sie der Zeile no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="cryptroot-unlock" voran, damit ein gestohlener Key nichts weiter als einen Prompt einbringt.
- 3
Der initramfs ein Netzwerk geben
DHCP funktioniert dort, wo der Anbieter es anbietet; andernfalls fügen Sie GRUB_CMDLINE_LINUX einen statischen Parameter ip=ADDRESS::GATEWAY:NETMASK::eth0:off hinzu und führen update-grub aus. Schließen Sie mit update-initramfs -u -k all ab, damit die Änderung im Image landet.
- 4
Einen vollständigen Neustart testen, bevor Sie sich darauf verlassen
Starten Sie neu, während die Konsole des Anbieters in einem anderen Fenster offen ist, verbinden Sie sich, geben Sie die Passphrase ein und beobachten Sie, wie der Boot weiterläuft. Ein ungetesteter Entsperrpfad ist kein Feature, sondern ein zukünftiger Ausfall.
Die initramfs trägt einen eigenen SSH-Host-Key, verschieden von dem, den das gebootete System vorzeigt, sodass Ihr Client bei jedem Neustart vor einem geänderten Host-Key warnt. Betreiben Sie dropbear über DROPBEAR_OPTIONS in /etc/dropbear/initramfs/dropbear.conf auf einem eigenen Port, oder verbinden Sie sich mit ssh -o HostKeyAlias=box-initramfs, und notieren Sie sich beide Fingerabdrücke.
Schlüsselverwaltung ist der Punkt, an dem Festplattenverschlüsselung meist scheitert
Die Chiffre ist nicht die Schwachstelle und war es nie. Jede Katastrophe mit LUKS, die sich noch beheben lässt, läuft am Ende auf einen Schlüssel oder einen Header hinaus — behandeln Sie beide als Infrastruktur.
- Sichern Sie den Header sofort — cryptsetup luksHeaderBackup /dev/vdb --header-backup-file luks-header.img — und bewahren Sie ihn abseits des Servers auf. Ein durch ein unachtsames dd beschädigter Header bedeutet endgültigen Datenverlust, selbst bei perfekter Passphrase.
- Verwenden Sie zwei Slots. LUKS2 stellt Ihnen 32 zur Verfügung: Ihre Passphrase in einem, ein langer zufälliger Recovery-Key in einem anderen, aufbewahrt in einem Passwort-Manager. Ein einzelner Slot ist ein selbstverschuldeter Single Point of Failure.
- Rotieren Sie auf einer entfernten Maschine in der richtigen Reihenfolge — fügen Sie den neuen Key mit luksAddKey hinzu, bestätigen Sie, dass er das Volume öffnet, und entfernen Sie erst dann den alten mit luksKillSlot. Niemals umgekehrt.
- Bewahren Sie die Passphrase und die Verbindungsdaten des Servers an getrennten Orten auf. Eine kompromittierte Notiz sollte nicht gleichzeitig die Adresse und den Schlüssel preisgeben.
Was Verschlüsselung an Leistung kostet
Der Overhead ist real, aber meist unsichtbar. Messen Sie ihn auf der Maschine, die Sie tatsächlich haben, statt einem Benchmark aus einem anderen Jahrzehnt zu vertrauen.
Die Teile, die man vergisst
Ein verschlüsseltes Volume, an dessen Rändern Klartext austritt, gibt ein falsches Sicherheitsgefühl — und das ist schlimmer als keines. Schließen Sie diese fünf Lücken, bevor Sie die Aufgabe für erledigt erklären.
- Swap. Eine unverschlüsselte Swap-Partition kann Fragmente von allem enthalten, was je durch den Speicher gelaufen ist. Verschlüsseln Sie sie bei jedem Boot mit einem frischen Zufallsschlüssel über einen /dev/urandom-Eintrag in /etc/crypttab.
- Logs, die vor dem Mount geschrieben werden. Alles, was protokolliert wird, solange das verschlüsselte Volume noch geschlossen ist, landet auf dem unverschlüsselten Root. Richten Sie Anwendungs- und Datenbank-Logs auf einen Pfad innerhalb des Containers.
- Backups. Den Inhalt eines verschlüsselten Volumes im Klartext in einen Object Storage zu kopieren, macht die ganze Übung zunichte. Verschlüsseln Sie das Backup unabhängig mit restic, borg oder age, und bewahren Sie diese Schlüssel woanders auf.
- Snapshots. Ein Snapshot des Anbieters erfasst die Festplatte, nicht Ihr RAM, sodass das LUKS-Volume darin Chiffretext bleibt — aber alles, was auf dem unverschlüsselten Root liegt, wird exakt so festgehalten, wie es war.
- Discard. Die discard-Option durch LUKS durchzureichen, hält TRIM auf NVMe funktionsfähig, verrät dabei aber, welche Blöcke ungenutzt sind — und damit ungefähr, wie voll das Dateisystem ist und wie es aufgebaut ist. Entscheiden Sie sich bewusst dafür, nicht weil eine Beispielkonfiguration es so vormacht.
Wo der Host weiterhin eine Rolle spielt
Verschlüsselung ist die Schicht, die Sie kontrollieren: Sie entscheidet, wie teuer es ist, Ihre Daten zu lesen, sobald eine Maschine aus ist oder eine Festplatte das Gebäude verlässt. Die Schicht darum herum — wer Zugriff auf die Hardware erzwingen kann, und welche Aufzeichnungen den Server mit Ihnen verknüpfen — liegt beim Anbieter und dessen Jurisdiktion. Sechs unserer fünfzehn Regionen sind Privacy-Tier-Jurisdiktionen; /locations listet sie auf, und /offshore-hosting erklärt, was das konkret ändert.
Drei Fähigkeiten des Anbieters entscheiden, ob die obigen Wege überhaupt zur Verfügung stehen: das Booten von einem eigenen ISO, ohne das Weg B unmöglich ist; Out-of-Band-Konsolenzugriff für den Neustart, bei dem das Remote-Entsperren einmal nicht zurückkommt; und eine Anmeldung, die die Maschine von Anfang an nie mit Ihrer Identität verknüpft hat. Jeder Plan auf /offshore-vps und /storage hier bootet von einem eigenen ISO, bringt Konsolenzugriff mit und wird aus einem vorausbezahlten Krypto-Guthaben ohne KYC beglichen — ein verschlüsselter Datenträger liegt hier also nicht auf einer Papierspur, die Sie bereits nennt. /guides bietet einen ehrlichen Überblick darüber, was ein Host sehen kann und was nicht.
Die Checkliste für die Bereitstellung
- Benennen Sie zuerst die Bedrohung: Ausgemusterte Laufwerke, abgetrennte Volumes und Offline-Images sind das, worauf Verschlüsselung antwortet — ein laufender Hypervisor nicht.
- Verschlüsseln Sie ein Datenvolume (Weg A), wenn der Server bereits läuft; installieren Sie von einem eigenen ISO neu (Weg B), nur wenn Root selbst verschlüsselt sein muss.
- LUKS2 mit aes-xts-plain64, und begrenzen Sie den Argon2id-Speicher bei jedem Plan unter 2 GB RAM.
- Passphrase in einem Key-Slot, ein langer zufälliger Recovery-Key in einem anderen, beide abseits des Servers aufbewahrt.
- Erstellen Sie ein LUKS-Header-Backup, bevor Sie das erste Byte echter Daten schreiben.
- dropbear-initramfs auf einem nicht standardmäßigen Port, nur mit Key-Login, beschränkt auf den Befehl cryptroot-unlock.
- Testen Sie einen vollständigen Neustart-und-Entsperren-Zyklus, während die Konsole des Anbieters noch neben Ihnen offen ist.
- Verschlüsselte Offsite-Backups, plus eine Wiederherstellungsübung — ein ungetestetes Backup ist eine Hoffnung, kein Backup.
Hält Festplattenverschlüsselung meinen Hosting-Anbieter davon ab, meine Daten zu lesen?
Im Ruhezustand ja: Sobald die Maschine ausgeschaltet ist, ist das Volume Chiffretext, und die Passphrase hat nie Ihren Kopf verlassen. Während der Server läuft und das Volume geöffnet ist, liegt der Master-Key im RAM auf Hardware, die der Anbieter betreibt. Verschlüsselung schließt jeden Offline-Weg — ausgemusterte Laufwerke, abgetrennte Volumes, kalte Images — und erhöht die Kosten für den Rest. Sie ergänzt eine vertrauenswürdige Jurisdiktion, ersetzt aber keine.
Kann ich einen bestehenden VPS verschlüsseln, ohne neu zu installieren?
Ein separates Datenvolume, ja, in etwa zehn Minuten — das ist Weg A oben. Das Root-Dateisystem, realistisch betrachtet, nein. cryptsetup reencrypt kann ein Dateisystem an Ort und Stelle umwandeln, aber eine abgebrochene Verbindung oder ein Stromausfall mitten im Vorgang hinterlässt auf einer entfernten Maschine einen nicht startfähigen Server und eine lange Nacht. Eine Neuinstallation von einem eigenen ISO ist schneller und deutlich sicherer.
Wie viel Leistung kostet LUKS?
Weniger, als die meisten erwarten. Mit AES-NI kostet AES-XTS bei typischen gemischten Workloads nur wenige Prozent, und cryptsetup benchmark meldet auf einem modernen EPYC-Kern mehrere GB/s. Sichtbar wird es bei sequenzieller Ein-/Ausgabe mit einem einzigen Thread gegen schnelles NVMe, wo ein Kern eher an seine Grenze stößt als das Laufwerk. Benchmarken Sie Ihre eigene Instanz, statt zu raten.
Was passiert, wenn ich die Passphrase vergesse?
Die Daten sind weg. Es gibt keinen Wiederherstellungsmechanismus, keinen Master-Key beim Anbieter und kein Support-Ticket, das das rückgängig macht — genau das ist der Sinn dieses Designs. Schützen Sie sich mit einem zweiten Key-Slot, der einen zufälligen Recovery-Key enthält, und mit einem LUKS-Header-Backup, das nicht auf dem Server liegt.
Ist es riskant, SSH innerhalb der initramfs laufen zu lassen?
Es ist eine kleine, gut verstandene Angriffsfläche. dropbear läuft nur für die paar Sekunden, bevor Ihr Root-Dateisystem existiert, akzeptiert ausschließlich Public Keys und lässt sich auf einen einzigen erzwungenen Befehl beschränken, der nichts weiter tut, als nach einer Passphrase zu fragen. Auf einem nicht standardmäßigen Port, mit separat notiertem initramfs-Host-Key, ist das praktische Risiko minimal – verglichen mit der Gewissheit, ohne all das ausgesperrt zu sein.
