Manjaro mit LUKS2 neu installieren und Benutzerdaten migrieren
Bei der Neuinstallation eines Manjaro Linux Systems mit verschlüsselter Systempartition bestimmen zwei Eigenschaften der beteiligten Werkzeuge vor, wie die Installation mit modernem LUKS2 umgesetzt werden kann. Calamares, der grafische Installer von Manjaro, legt bei aktivierter Verschlüsselung lediglich einen Container im alten LUKS1 Format an. Der Bootloader GRUB kann dazu einen LUKS2 Container mit den heute üblichen Parametern nicht aufschließen.
Aus beidem folgt ein Ablauf, der von der Standardinstallation von Manjaro abweicht und effektiv auf ein Design herausläuft, wie es auch beispielsweise Ubuntu umsetzt:
/boot liegt unverschlüsselt auf einer eigenen Partition und bringt eine Ramdisk mit, die alles notwendige zur Unterstützung von LUKS2 beinhaltet.
Dazu wird die Partitionierung wird von Hand vorgenommen, und der Container wird bei der Installation auf LUKS2 konfiguriert.
Der Beitrag zeigt diesen Ablauf und anschließend die Übernahme der Benutzerdaten vom alten Rechner über das Netz. Alle Schritte sind in einer KVM VM mit emulierter NVMe Platte nachgestellt, das Skript dazu steht am Ende des Beitrags.
Warum LUKS2 und warum /boot unverschlüsselt
LUKS2 unterscheidet sich von LUKS1 vor allem bei der Ableitung des Schlüssels aus der Passphrase. LUKS1 verwendet PBKDF2, LUKS2 standardmäßig Argon2id. Argon2id ist so ausgelegt, dass jeder Entsperrversuch nicht nur Rechenzeit, sondern auch viel Arbeitsspeicher benötigt, was Angriffe mit GPUs oder Spezialhardware deutlich verteuert. Dazu kommen ein redundanter Header und Metadaten im JSON Format.
Genau diese Eigenschaft ist für GRUB ein Problem. Liegen Kernel und initrd innerhalb der verschlüsselten Partition, muss GRUB den Container selbst öffnen, bevor überhaupt ein Linux-Kernel läuft. Die LUKS2 Unterstützung in GRUB beherrscht dabei nur PBKDF2, mit Argon2id kann sie nichts anfangen. Ein so verschlüsselter Datenträger ist für GRUB nicht zu öffnen und der Rechner bleibt beim Start stehen.
Der Ausweg ist eine eigene, unverschlüsselte Partition für /boot.
GRUB liest Kernel und initrd dann im Klartext und muss den Container gar nicht anfassen.
Das Entsperren übernimmt der encrypt Hook in der initrd, und dort steht das vollständige cryptsetup zur Verfügung.
Argon2id ist an dieser Stelle unproblematisch.
Der Preis dafür sollte bewusst in Kauf genommen werden: Kernel und initrd liegen unverschlüsselt auf der Platte und lassen sich mit physischem Zugriff austauschen. Wer das ausschließen möchte, braucht Secure Boot mit eigenen Schlüsseln oder ein per TPM gemessenes Unified Kernel Image. Für den üblichen Grund einer Festplattenverschlüsselung, den Schutz der Daten bei Verlust oder Diebstahl des Geräts, ist die Aufteilung ausreichend.
Vorbereitung im BIOS
Auf Lenovo Geräten wird das Setup mit F2 beim Start geöffnet, das Bootmenü mit F12.
Zwei Einstellungen sind relevant:
-
Secure Boot auf Disabled, da Manjaro keine signierten Kernel mitbringt.
-
Der Storage Controller auf AHCI beziehungsweise NVMe statt RAID oder VMD.
Der zweite Punkt wird gerne übersehen.
Steht der Controller im RAID- oder VMD-Modus, taucht die interne NVMe im Live-System gar nicht erst als /dev/nvme0n1 auf.
Partitionierung mit gdisk
Die automatische Partitionierung von Calamares legt /boot innerhalb des verschlüsselten Bereichs an.
Deshalb wird die Platte vor der Installation von Hand partitioniert.
Nach dem Start vom Live-Medium wird dazu ein Terminal geöffnet:
$ sudo gdisk /dev/nvme0n1In gdisk legt o eine neue, leere GPT an, bestehende Partitionen werden damit verworfen.
Danach folgen drei Mal n für die neuen Partitionen.
Partitionsnummer und Startsektor werden jeweils mit Enter bestätigt, anzugeben sind nur Größe und Typ:
| Nr. | Größe | Typ | Verwendung |
|---|---|---|---|
1 |
|
|
EFI System Partition, später |
2 |
|
|
unverschlüsseltes |
3 |
|
|
verschlüsseltes |
Ein Gigabyte für /boot ist großzügig bemessen, aber praktisch.
Manjaro hält mehrere Kernel parallel vor, und jeder davon belegt mit initrd und Fallback-Image gut 100 MB.
Geschrieben wird die Partitionstabelle mit w und der Bestätigung Y.
Erst dieser Schritt verändert die Platte.
Installation mit Calamares
Der Installer wird über "Install Manjaro" gestartet. Bei der Partitionierung wird Manual partitioning gewählt, damit die eben angelegte Aufteilung erhalten bleibt.
Die dritte Partition wird gelöscht und im freien Bereich neu angelegt. Der Umweg ist nötig, weil die Option zur Verschlüsselung nur im Dialog Create a Partition angeboten wird, nicht beim Bearbeiten einer bestehenden Partition.
Im Dialog werden ext4 als Dateisystem gewählt, Encrypt aktiviert, die Passphrase zweimal eingegeben und / als Mount Point gesetzt.
Für die beiden anderen Partitionen genügt es, den Mount Point zu setzen. Sie behalten ihre Dateisysteme, formatiert wird nichts.
-
/dev/nvme0n1p1auf/boot/efi, dasbootFlag setzt Calamares wegen des Partitionstyps selbst -
/dev/nvme0n1p2auf/boot
Entscheidend ist, dass nur die Wurzelpartition als LUKS geführt wird.
/boot bleibt ein normales ext4 Dateisystem.
Der Rest der Installation läuft wie gewohnt. Beim Anlegen des Benutzers sollte derselbe Benutzername wie auf dem alten Rechner vergeben werden, das vereinfacht die spätere Datenübernahme.
Was Calamares tatsächlich angelegt hat
Nach der Installation lohnt ein Blick auf den Header, noch bevor das neue System zum ersten Mal gestartet wird. Dazu genügt das Live-System, in dem der Installer gerade gelaufen ist:
$ sudo cryptsetup luksDump /dev/nvme0n1p3 | head -5
LUKS header information for /dev/nvme0n1p3
Version: 1
Cipher name: aes
Cipher mode: xts-plain64Version: 1 ist hier das Ergebnis:
Calamares legt einen LUKS1 Container an, obwohl dasselbe Live-System ein cryptsetup mitbringt, das bei einem Aufruf von Hand LUKS2 als Vorgabe verwendet.
Die Verschlüsselung der Daten selbst ist mit aes-xts-plain64 in Ordnung, die Passphrase wird aber über PBKDF2 abgeleitet und nicht über Argon2id.
Umstellung auf LUKS2 mit Argon2id
Ein bestehender Container lässt sich in beide Richtungen konvertieren, solange er nicht aktiv ist. Calamares lässt das Mapper-Gerät nach der Installation offen, es muss also zuerst geschlossen werden:
$ sudo umount -R /tmp/calamares-root-*
$ sudo cryptsetup close $(ls /dev/mapper | grep luks)Danach folgen die beiden eigentlichen Schritte.
convert tauscht das Header-Format aus, luksConvertKey stellt den vorhandenen Keyslot von PBKDF2 auf Argon2id um:
$ sudo cryptsetup convert /dev/nvme0n1p3 --type luks2
WARNING!
========
This operation will convert /dev/nvme0n1p3 to LUKS2 format.
Are you sure? (Type 'yes' in capital letters): YES
$ sudo cryptsetup luksConvertKey --pbkdf argon2id /dev/nvme0n1p3
Enter passphrase for keyslot to be converted:Beide Schritte fassen die Nutzdaten nicht an. Verändert wird ausschließlich der Header am Anfang der Partition, das installierte System bleibt unberührt.
Wichtig ist dabei die UUID:
Sie bleibt bei der Konvertierung erhalten.
Der Eintrag cryptdevice=UUID=…, den Calamares in die GRUB-Konfiguration geschrieben hat, bleibt damit gültig und muss nicht angepasst werden.
Die Argon2id Parameter im Keyslot ermittelt cryptsetup dabei durch eine Messung auf der jeweiligen Maschine. Auf einem Notebook mit ausreichend RAM fallen sie deutlich höher aus als in einer knapp bemessenen VM.
Kontrolle nach dem ersten Start
Beim Start fragt die initrd nach der Passphrase. Der Dialog kommt von Plymouth und damit aus der initrd, GRUB hat seine Arbeit an dieser Stelle bereits erledigt.
Nach der Anmeldung lässt sich die Aufteilung prüfen:
nvme0n1p3 wird als crypto_LUKS geführt, darunter hängt das entsperrte Gerät mit dem Wurzeldateisystem.
nvme0n1p2 ist ein gewöhnliches ext4 auf /boot, genau wie beabsichtigt.
Ein Blick auf die Konfiguration zeigt, wie die Teile zusammenspielen:
Drei Punkte sind dabei relevant:
-
In der
fstabsteht als Wurzeldateisystem das Mapper-Gerät, nicht die Partition. -
Die
HOOKSinmkinitcpio.confenthaltenencryptvorfilesystems, sonst gäbe es beim Start kein entsperrtes Gerät zum Einhängen. -
Auf der Kernel-Kommandozeile steht
cryptdevice=UUID=…, womit die initrd weiß, welche Partition sie öffnen soll.
Ein Neubau der initrd ist nach der Konvertierung nicht nötig.
Der encrypt Hook liest das Format beim Start aus dem Header und kommt mit LUKS1 wie LUKS2 zurecht.
Warum der Container nicht vorab angelegt wird
Naheliegend wäre, den LUKS2 Container gleich von Hand anzulegen und Calamares nur noch hineininstallieren zu lassen:
$ sudo cryptsetup luksFormat --type luks2 /dev/nvme0n1p3
$ sudo cryptsetup open /dev/nvme0n1p3 cryptroot
$ sudo mkfs.ext4 -L MANJARO_ROOT /dev/mapper/cryptrootDas funktioniert mit Calamares nicht.
Der Installer bietet in der Geräteauswahl der manuellen Partitionierung ausschließlich physische Datenträger an, ein Eintrag /dev/mapper/cryptroot taucht dort nicht auf.
Ist der Container geöffnet, sieht Calamares durch die Zuordnung hindurch und führt die Partition als gewöhnliches ext4.
Die LUKS-Schicht ist in der Oberfläche schlicht nicht sichtbar:
Ein Mount Point lässt sich so zwar setzen, die Installation scheitert aber trotzdem. Calamares räumt zu Beginn der Installation die Zielplatte frei und schließt dabei auch bestehende LUKS-Zuordnungen. Eine Passphrase für einen fremden Container kennt der Installer nicht, also bleibt das Gerät zu:
In /dev/mapper liegt nur noch control, und es ist kein Zieldateisystem eingehängt.
Calamares entpackt das Systemabbild daraufhin in ein Verzeichnis unterhalb von /tmp, das im Live-System ein tmpfs im Arbeitsspeicher ist.
Dieses läuft nach wenigen Gigabyte voll und die Installation bricht mit rsync failed with error code 11 ab.
Der Weg über die Verschlüsselung durch Calamares und die anschließende Konvertierung vermeidet dieses Problem, weil der Installer den Container selbst anlegt und die Passphrase kennt.
Benutzerdaten über das Netz übernehmen
Steht das neue System, folgt der Umzug der Benutzerdaten.
Über das Netz mit rsync ist das deutlich bequemer als der Umweg über eine externe Platte und bei einer Kabelverbindung auch schnell genug.
Voraussetzung ist der gleiche Benutzername auf beiden Geräten.
Dann stimmen die Pfade unterhalb von /home überein und die Zuordnung der Rechte bleibt einfach.
Auf dem neuen Rechner wird ein SSH Server installiert und gestartet:
$ sudo pacman -S openssh
$ sudo systemctl start sshd
$ ip -brief address
lo UNKNOWN 127.0.0.1/8
enp0s31f6 UP 192.168.1.150/24systemctl start startet den Dienst nur für diese Sitzung.
Das reicht für den Umzug und vermeidet, dass auf dem Notebook dauerhaft ein SSH Server läuft.
Auf dem alten Rechner wird zuerst die Verbindung getestet und der Fingerprint bestätigt:
$ ssh [email protected]Danach folgt ein Probelauf.
--dry-run überträgt nichts, listet aber auf, was übertragen würde:
$ rsync -avzP --dry-run \
--exclude='.cache' \
--exclude='.local/share/Trash' \
/home/benutzer/ [email protected]:/home/benutzer/Der abschließende Schrägstrich hinter /home/benutzer/ ist entscheidend.
Ohne ihn legt rsync auf der Gegenseite ein Verzeichnis /home/benutzer/benutzer an.
Sieht die Liste plausibel aus, wird derselbe Aufruf ohne --dry-run wiederholt.
-P sorgt dafür, dass ein abgebrochener Lauf fortgesetzt werden kann, ein erneuter Aufruf überträgt dann nur die fehlenden Dateien.
Neben .cache und dem Papierkorb lohnt ein Blick auf weitere Verzeichnisse, die auf dem neuen Gerät eher stören als nützen:
Container- und VM-Abbilder unter .local/share/containers oder .local/share/libvirt, Browser-Caches sowie die Build-Verzeichnisse von Entwicklungsumgebungen.
Diese Daten sind entweder groß, reproduzierbar oder beides.
Da die Übertragung als der Zielbenutzer über SSH läuft, gehören die Dateien anschließend bereits dem richtigen Konto.
Falls doch etwas verrutscht ist, etwa weil Teile als root kopiert wurden, hilft:
$ sudo chown -R $USER:$USER /home/$USEREin Neustart danach ist sinnvoll, damit Desktop-Konfiguration und Anwendungsprofile sauber eingelesen werden.
Der SSH Server auf dem neuen Gerät ist danach automatisch wieder aus, da er nicht per systemctl enable dauerhaft aktiviert wurde.
Nachstellen in einer VM
Die Screenshots dieses Beitrags stammen aus einer KVM VM, die dem beschriebenen Notebook nachempfunden ist:
UEFI Firmware ohne Secure Boot und eine emulierte NVMe Platte, damit der Gast tatsächlich /dev/nvme0n1 sieht und nicht /dev/vda.
Das verwendete Skript legt diese VM an und erzeugt Screenshots und Eingaben über libvirt, ein Viewer-Fenster wird dafür nicht gebraucht: manjaro-luks-vm.sh.
$ ./manjaro-luks-vm.sh create # Platte anlegen, VM definieren und starten
$ ./manjaro-luks-vm.sh shot 01-gdisk # Screenshot ablegen
$ ./manjaro-luks-vm.sh type 'lsblk -f' # Text in den Gast tippen
$ ./manjaro-luks-vm.sh destroy # wieder aufräumenDie VM läuft in der Session-Instanz von libvirt und braucht keine root-Rechte. Wer den Ablauf einmal gefahrlos durchspielen möchte, bevor die Platte des Notebooks gelöscht wird, hat damit eine Umgebung, in der auch ein Fehlversuch nichts kostet.
Fazit
Die Kombination aus verschlüsselter Wurzelpartition und unverschlüsseltem /boot ist bei Manjaro nicht in wenigen Klicks zu haben, aber der Mehraufwand hält sich in Grenzen.
Drei Punkte tragen den Ablauf:
Die Partitionierung erfolgt vor der Installation von Hand, damit /boot außerhalb des Containers liegt.
Die Verschlüsselung legt Calamares an, weil nur der Installer die Passphrase kennt und den Container beim Einrichten offen halten kann.
Und die Umstellung auf LUKS2 mit Argon2id erfolgt danach mit cryptsetup convert und luksConvertKey, was Header-Änderungen sind und die Daten nicht berührt.
Dass das überhaupt geht, liegt am unverschlüsselten /boot:
GRUB fasst den Container nicht an und muss LUKS2 daher auch nicht verstehen.
Der einzige Bestandteil, der den Header liest, ist der encrypt Hook der initrd, und der bringt das vollständige cryptsetup mit.
Zu den Themen Linux, Automatisierung und Betrieb bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:
Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.