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 werden Partitionierung, LUKS2 Container und Dateisysteme einmalig von Hand vorbereitet, bevor der grafische Installer die eigentliche Installation übernimmt.
Der Beitrag zeigt den Ablauf der Installation und anschließend auch, wie die Übernahme der Benutzerdaten vom alten Rechner via Netzwerk erfolgen kann.
Der Rechner wird dabei wie gewohnt mit einem Manjaro Installationsmedium, z.B. USB Stick, gestartet.
Motivation LUKS2 und unverschlüsselte Ramdisk
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. Zusätzlich liefert LUKS2 einen redundanter Header und Metadaten im JSON Format.
Für GRUB ist das ein Problem: Liegen Kernel und initrd innerhalb der verschlüsselten Partition, muss GRUB den Container selbst öffnen, bevor überhaupt ein Linux-Kernel gestartet werden kann. Die LUKS2 Unterstützung in GRUB beherrscht dabei nur PBKDF2, mit Argon2id kann GRUB nicht umgehen und damit auch nicht Booten.
Die Lösung ist eine eigene, unverschlüsselte Partition für /boot:
GRUB referenziert Kernel und initrd dann im Klartext und muss mit dem verschlüsselten Container gar nicht arbeiten.
Das Entsperren übernimmt der encrypt Hook in der initrd Ramdisk.
Dort steht das vollständige cryptsetup zur Verfügung und entsprechend ist auch Argon2id an dieser Stelle unproblematisch.
Der Tradeoff liegt aber auch auf der Hand: Kernel und initrd liegen unverschlüsselt auf der Festplatte und lassen sich bei physischem Zugriff auf den Rechner verhältnismäßig einfach manipulieren. Wer sich auch dagegen schützen möchte, braucht Secure Boot mit eigenen Schlüsseln oder ein per TPM geschütztes Unified Kernel Image.
Partitionierung mit gdisk
Die automatische Partitionierung von Calamares unterstützt Verschlüsselung (LUKS1) und legt /boot innerhalb der verschlüsselten Partition an.
Um das zu verhindern wird die Festplatte vor der Installation von Hand partitioniert.
Dazu wird nach dem Start vom Installations-Medium ein Terminal geöffnet und der gdisk Partitionierer gestartet.
$ sudo gdisk /dev/nvme0n1Innerhalb von gdisk legt o eine neue, leere GPT Partitionstabelle an.
Bestehende Partitionen werden damit entfernt.
Danach folgen drei Mal der Ablauf für neue Partitionen.
Mittels n wird eine Partition angelegt.
Partitionsnummer und Startsektor werden jeweils mit Enter bestätigt, anzugeben sind dann nur noch Größe und Typ, wie in der folgenden Tabelle zu sehen.
| Nr. | Größe | Typ | Verwendung |
|---|---|---|---|
1 |
|
|
EFI System Partition, später |
2 |
|
|
unverschlüsseltes |
3 |
|
|
LUKS2 Container, später |
Das Ergebnis kann man sich mit p anschließend ausgeben lassen.
Ein Gigabyte für /boot ist großzügig bemessen und zukunftssicher, auch für wachsende Ramdisks und parallele Versionn.
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 an dieser Stelle werden die Änderungen tatsächlich auf die Festplatte geschrieben.
LUKS2 Container anlegen
Der Crypto-Container wird auf der dritten Partition angelegt.
--type luks2 ist bei aktuellen cryptsetup Versionen bereits die Vorgabe, die explizite Angabe macht die Intention aber nochmals deutlich sichtbar:
$ sudo cryptsetup luksFormat --type luks2 /dev/nvme0n1p3Die Sicherheitsabfrage muss mit YES (in Großbuchstaben) bestätigt werden, danach wird die Passphrase festgelegt und zur Bestätigung nochmals wiederholt.
Der Vorgang dauert einen Moment, weil cryptsetup die Argon2id Parameter an der vorhandenen Hardware ausmisst. Dabei wird eine gute Balance zwischen Komfort, also schnellem Aufschließen mit korrekter Passphrase, und Robustheit gegen Angriffe gewählt. Was dabei konkret ausgewält wurde, zeigt der LUKS2 Header:
$ sudo cryptsetup luksDump /dev/nvme0n1p3
Version: 2 zeigt nochmals das Format, cipher: aes-xts-plain64 die Verschlüsselung des Datenbereichs und PBKDF: argon2id das Verfahren zur Schlüsselableitung.
Die Speichervorgabe im Keyslot bedeutet, dass ein Entsperrversuch entsprechend viel Arbeitsspeicher belegt.
Dateisysteme anlegen
Als nächstes sollen die Dateisysteme vorbereitet werden.
Da das /-Root-Filesystem in dem Crypto-Container liegt, muss dieser zunächst aufgeschlossen werden.
$ sudo cryptsetup open /dev/nvme0n1p3 cryptroot
$ sudo mkfs.ext4 -L MANJARO_ROOT /dev/mapper/cryptroot
$ sudo mkfs.ext4 -L MANJARO_BOOT /dev/nvme0n1p2
$ sudo mkfs.fat -F 32 -n EFI /dev/nvme0n1p1Zu beachten ist hier, dass mkfs.ext4 für das Root-Filesystem auf /dev/mapper/cryptroot angewandt wird und nicht auf /dev/nvme0n1p3.
Alles, was in das Mapper-Device geschrieben wird, landet verschlüsselt auf der Partition.
Der Name cryptroot ist frei gewählt und wird später an mehreren Stellen referenziert:
In /etc/fstab, auf der Kernel-Kommandozeile und in der Passphrase-Abfrage beim Start.
nvme0n1p3 wird als crypto_LUKS geführt, darunter hängt das geöffnete Gerät cryptroot mit dem eigentlichen ext4 Dateisystem.
Partitionen mounten
Vor dem Start des Installers wird die zukünftige Partitionsstruktur in der richtigen Reihenfolge gemounted:
$ sudo mount /dev/mapper/cryptroot /mnt
$ sudo mkdir -p /mnt/boot
$ sudo mount /dev/nvme0n1p2 /mnt/boot
$ sudo mkdir -p /mnt/boot/efi
$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
Dieser Schritt ist für das richtige Verhalten des Installers wichtig: Solange die Dateisysteme eingehängt sind, ist der Datenträger in Verwendung und der Installer belässt die vorbereitete Aufteilung. Ohne die Mounts löscht Calamares die Zielplatte zu Beginn der Installation und schließt dabei auch den vorbereiteten LUKS-Container. Danach kann der Container nicht genutzt werden und die Installation bleibt stecken. Diese Probleme werden somit vermieden.
Installation mit Calamares
Der Calamares Installer wird über den grafischen Punkt "Launch Installer" gestartet.
Hier kann vorher noch, falls notwendig, eine Internetverbindung hergestellt werden.
Bei der Partitionierung steht nur noch Manual partitioning zur Auswahl, die automatischen Verfahren bietet Calamares wegen der verwendeten Partionen gar nicht erst an.
Die "encrypt" Option wird hier nicht aktiviert.
In der Partitionsliste wird für jede der drei Partitionen der Mountpoint manuell gesetzt, ohne etwas zu formatieren:
-
/dev/nvme0n1p3auf/ -
/dev/nvme0n1p2auf/boot -
/dev/nvme0n1p1auf/boot/efi, dasbootFlag setzt Calamares wegen des Partitionstyps selbst
Dass /dev/nvme0n1p3 in der Liste als ext4 erscheint und nicht als LUKS, ist an dieser Stelle richtig so.
Calamares sieht in dem geöffneten Container direkt das Dateisystem, das sich darin befindet.
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.
Kontrolle nach dem ersten Start
Beim Start fordert die initrd Ramdisk zur Eingabe der Passphrase auf.
Der Dialog kommt von Plymouth, GRUB hat seine Arbeit an dieser Stelle bereits erledigt.
Abgefragt wird das Passwort für cryptroot, also genau der Name, der beim Öffnen des Containers vergeben wurde.
Nach der Anmeldung lässt sich die Aufteilung prüfen:
nvme0n1p3 wird als crypto_LUKS geführt, darunter hängt cryptroot mit dem Wurzeldateisystem.
nvme0n1p2 ist ein gewöhnliches ext4 auf /boot, genau wie beabsichtigt.
Ein cryptsetup luksDump auf dem laufenden System zeigt weiterhin Version: 2 und argon2id unter derselben UUID wie beim Anlegen.
Der Installer hat den Container also nicht verändert.
Ein Blick auf die Konfiguration zeigt, wie die einzelnen Elemente zusammenspielen:
-
In der
fstabsteht als Wurzeldateisystem/dev/mapper/cryptroot, nicht die Partition. -
Die
HOOKSinmkinitcpio.confenthaltenencryptvorfilesystems, sonst gäbe es beim Start kein aufgeschlossenes Device zum mounten. -
Auf der Kernel-Kommandozeile steht
cryptdevice=UUID=…:cryptroot, womit die initrd weiß, welche Partition sie unter welchem Namen öffnen soll.
Variante: Verschlüsselung durch Calamares
Wer mehr Schritte im grafischen Werkzeug erledigen möchte, kann die Verschlüsselung auch von Calamares anlegen lassen.
In der manuellen Partitionierung wird die Wurzelpartition dazu gelöscht und über Create a Partition neu angelegt, dort steht eine Option Encrypt mit Passphrase zur Verfügung.
Die Partitionierung von Hand bleibt trotzdem nötig, damit /boot außerhalb des Containers landet.
Das Ergebnis ist allerdings ein LUKS1 Container. Dies lässt sich nachträglich umstellen, solange er nicht aktiv ist. (Also aus dem Live-System heraus.)
$ sudo cryptsetup convert /dev/nvme0n1p3 --type luks2
$ sudo cryptsetup luksConvertKey --pbkdf argon2id /dev/nvme0n1p3Beide Aufrufe verändern nur den Header und lassen die UUID unverändert, der Eintrag cryptdevice=UUID=… bleibt also identisch.
Ein Neubau der initrd Ramdisk ist nicht nötig, der encrypt Hook liest das Format beim Start aus dem Header.
Verglichen mit dem direkten Weg sind das zwei zusätzliche Schritte, zudem ist die Passphrase zwischenzeitlich nur über PBKDF2 geschützt.
Migration von Benutzerdaten
Steht das neue System, folgt der Umzug der Benutzerdaten.
Das kann via Netzwerk mittels rsync erfolgen.
Das deutlich bequemer als der Umweg über eine externe Platte und bei einer Kabelverbindung auch hinreichend schnell.
Über WiFi - je nach Verbindung und Datenmenge - kann das auch über Nacht oder noch länger dauern.
Voraussetzung für den rsync-Ansatz ist der gleiche Benutzername und User-ID auf beiden Geräten:
Dann nämlich 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 lediglich für diese Sitzung und nicht automatisch bei jedem Start.
Das reicht für den Umzug und vermeidet, dass ungewollt auf dem System dauerhaft ein SSH Server läuft.
Auf dem alten Rechner wird zuerst die Verbindung getestet und der Fingerprint bestätigt, anschließend erfolgt ein Logout.
$ ssh [email protected]Danach folgt ein Probelauf mit rsync vom alten System aus..
--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 wichtig.
Ohne ihn legt rsync auf der Gegenseite ein zusätzliches 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, deren Übertragung ggf. unerwünscht ist:
Container- und VM-Abbilder unter .local/share/containers oder .local/share/libvirt, Browser-Caches sowie die Build-Verzeichnisse von Entwicklungsumgebungen.
Diese Daten sind meist groß und sowieso lokal reproduzierbar.
Da die Übertragung als der Zielbenutzer über SSH läuft, gehören die Dateien anschließend bereits dem richtigen Konto.
Falls doch etwas schief hängt, etwa weil Teile als root kopiert wurden, muss dies anschließend behoben werden.
Ein Neustart ist nach der Migration sinnvoll, damit Desktop-Konfiguration und Anwendungsprofile frisch eingelesen werden.
(Der SSH Server auf dem neuen Gerät ist danach automatisch wieder aus, da er nicht per systemctl enable dauerhaft aktiviert wurde.)
Fazit
Eine verschlüsselte Wurzelpartition mit LUKS2 und unverschlüsseltem /boot ist bei Manjaro nicht in wenigen Klicks zu haben, der Mehraufwand hält sich aber in Grenzen und die Schritte sind an sich relativ simpel.
Partitionierung, LUKS2 Container und Dateisysteme entstehen vorab mit gdisk und cryptsetup.
Werden die Zieldateisysteme danach unter /mnt eingehängt, übernimmt Calamares den vorbereiteten Aufbau und installiert dort hin, ohne an der Verschlüsselung etwas zu ändern.
Im Ergebnis findet sich ein gut gesicherter Container, der von Anfang an LUKS2 mit Argon2id nutzt.
Möglich ist das allerdings nur, solange /boot unverschlüsselt bleibt:
GRUB wird so von der Verantwortung entbunden, mit LUKS2 und dem modernen Argon2id umzugehen.
Das erledigt dann 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.