Raspberry Pi mit Ubuntu 20.04 LTS, Btrfs und Luks Verschlüsselung des Root Dateisystems + Remote Login [Kommentar]
Worum geht es?
Aktuell ist der Blog recht Linux- und wenig buchlastig. Ggf. muss ich das doch irgendwann mal trennen.
Der Post hat zwei Komponenten. Erstens den Raspberry Pi mit Ubuntu 20.04 und Btrfs betreiben. Das ist eher noch in der Kategorie einfach anzusiedeln. Einen allgemeinen Beitrag zum Thema Btrfs und Backups hatte ich bereits hier veröffentlicht.
Der zweite Teil betrifft die Verschlüsselung des Root Laufwerks mit Ubuntu 20.04 und dem Pi. Der Teil ist aus meiner Sicht schon nicht mehr für Fortgeschrittene, sondern eher für Profis.
Btrfs (Dateisystem) und Luks (Verschlüsselung) sind vollkommen unabhängig, man sollte aber nicht den Fehler begehen und erst Btrfs einrichten und dann davon ausgehen, dass man im nachhinein einfach die Verschlüsselung aktiviert. Das Motto bei Linux Verschlüsselung ist da eher Grüne Wiese und von vorne.
Aber der Reihe nach – warum Verschlüsselung?
Wenn man einen Rechner zu Hause stehen hat, denken viele ich habe nichts zu verbergen und warum verschlüsseln. Es braucht es aus meiner Sicht keine Geheimdienstszenarien um gute Gründe für Verschlüsselung von Daten zu finden.
Beispielszenario: Ein Einbrecher nimmt den ganzen Technikkram mit, er ist selbst kein IT Profi aber irgendwo verkaufen geht immer. Die Datenträger oder Computer werden also weiterverkauft. Jemand mit IT Kenntnissen bekommt die Datenträger in die Hände und je nachdem was man so alles auf dem Rechner hat (Emails, Rechnungen, Chatverläufe, Pincodes, Sexfotos, …) usw. kann das höchst spannend und ggf. schädlich werden, auch für Leute die vermeintlich nichts zu verbergen haben.
Es reicht ja schon, wenn die Person lustig bei Amazon bestellt, auf die Rechnung des Opfers.
Andere Szenarien lassen sich beliebig generieren. Die unachtsam entsorgte SSD Karte / Festplatte, die vermeintlich nicht mehr ging usw.
Da ich zuerst Btrfs aufgesetzt hatte und alle meine Mails (über einen Zeitrum von 15 Jahren und Rechnungen, Versicherungsunterlagen, …) auf dem Pi sind, fand ich die Idee der Verschlüsselung recht angeraten, zumal ich das bei allen Windows Rechnern auch so handhabe. Der Pi hätte ansonsten die Verschlüsselung auf dem Windows Rechnern und Backups quasi ad absurdum geführt und wäre das schwächste Glied in der Kette gewesen.
Verschlüsselung bei Linux
Vorab möchte ich zu dem Verschlüsselungsthema anmerken, dass ich zum ersten Mal im Linux Kontext den Eindruck hatte, dass Dinge extrem schlecht ineinander greifen und unnötig kompliziert sind. Ich bin mit der Erwartungshaltung eines Windows Bitlocker Nutzers an das Thema herangegangen.
Wie funktioniert es bei Bitlocker? Im Prinzip drückt man in Windows auf den Button mit Bitlocker verschlüsseln, bekommt einen Key zur Wiederherstellung den man irgendwo speichern kann und zusätzlich kann man auch einen eigenen verkürzten Key vergeben. Die Verschlüsselung lässt sich auf ein bestehendes Laufwerk anwenden und auch wieder rückgängig machen. Anschließend kann man in Bitlocker mit der regulären Windows Anmeldung alle Laufwerke entsperren.
Die Einrichtung ist für Anfänger geeignet. So muss es auch sein, wenn man Themen wie Verschlüsselung voran bringen will.
Wer mit dieser Erwartungshaltung in Linux startet fällt ganz Böse auf die Nase. Es gibt bei Linux verschiedene Verschlüsselungsvarianten aber der Tenor ist im Prinzip, die einzig sinnvolle ist eine Vollverschlüsselung. Gerade bei einem Server findet sich irgendwo doch mal ein Passwort, dass in einer Datei eingetragen wurde und das einem ggf. Zugriff auf andere Bereiche ermöglicht.
Es gibt Varianten, die nicht mehr unterstützt werden oder sehr langsam sind aber mein Fazit nach etwas Recherche ist zum aktuellen Zeitpunkt, dass Luks / Luks2 die am meisten verbreitete und unterstützte Variante ist, die auch weiterentwickelt wird.
Erwartungshaltung – und tschüss!
Was geht und was geht nicht bei Linux?
- Entschlüsseln mit der Standardanmeldung (wie in Windows) – das geht soweit ich das bisher herausgefunden habe über pam_mount aber nicht für ROOT Laufwerke. Das Konzept ist, dass man das Anmeldepasswort und das Entschlüsselungspasswort des Laufwerks analog vergibt. Über eine entsprechende Konfiguration kann dann das Laufwerk durch die Anmeldung entsperren.
- Entschlüsseln mehrerer Laufwerke gleichzeitig? Fehlanzeige. Zumindest nicht automatisch. Es gibt verschiedene mehr oder weniger schlechte Ansätze.
- Mit einem Key aus einer Datei ein oder mehrere Laufwerke entsperren – das ist nicht gut, weil der Key zumindest zwangsweise ins die initramfs muss und das dazu führt, dass man ihn auslesen kann (zumindest bei Ubuntu auf dem Pi, weil boot nicht verschlüsselt ist. Theoretisch gillt das nur für Root Laufwerke aber bei mir hat es selbst dann nicht ohne Fehlermeldung bei der initramfs Erstellung funktioniert, wenn es sich nicht um ein root laufwerk handelt)
- Abgeleitete Keys (derived keys) – die Variante leitet aus dem Key des Root Laufwerks weitere ab, das ist auch nachteilig, weil man an nichts mehr dran kommt, wenn der Root Key beschädigt wird. Richtig zum Laufen bekommen habe ich diese Variante auch nicht. Beim Start wurde trotzdem ein Key abgefragt.
- Man nutzt überall denselben Key. Mit einem Zusatzprogramm (separates Paket)! kann man den dann laufwerksübergreifend nutzen. Dafür sind aber einige Voraussetzungen zu beachten. Das ist aber auch meiner Sicht die beste schlechte Variante.
- Nativer Kernel Support? Nö, man muss sich initramfs Images bauen, damit man es ans Laufen bekommt. Das ist ziemliche Bastelei und fehleranfällig. Alles was man an Programmen benötigt muss in das Image und zumindest bei meinen bisherigen Versuchen war es so, dass sogar das Root Laufwerk in der Ramdisk verdrahtet wird. D.h. das Image läuft bereits bei einem Laufwerkswechsel nicht mehr. Wenn man was falsch macht, schaut man nach dem nächsten Boot ggf. in die Röhre.
- Vergrößern und Verkleinern von Partitionen mit Verschlüsselung. Theoretisch soll das funktionieren. Das ging bei mir mit Gparted nicht (das liegt wohl daran, dass cryptsetup ein PW verlangt und Gparted keine Eingabe vorsieht). Die Btrfs Partition in Luks wurde verkleinert. Der Luks Teil nicht. Ich habe das auch manuell nicht hinbekommen die Partition zu verkleinern bzw. wie ich später raus gefunden habe, vergrößert Luks ganz automatisch bei der nächsten Anmeldung auf das Maximum.
- Das Verschieben von Luks Partitionen funktioniert mit Gparted, der KDE Partition Manager hat dabei die Partition geschrottet. Von dem kann ich also nur abraten.
- Nachträgliches Umwandeln von vorhandenen Partitionen in verschlüsselte Partitionen oder andersrum. Nö, geht nicht.
- Der Einzige Vorteil ist aus meiner Sicht, dass man aufgrund der Trennung von Anmeldung und Entsperrung der Laufwerke zwei unterschiedliche Kennwörter nutzen kann.
Besonderheit Ubuntu 20.04 LTS mit Raspberry Pi
Ubuntu 20.04 ist recht neu und der Raspberry Pi 4b auch noch verhältnismäßig. Dazu kommt, dass die meisten Raspberry Pi Benutzer Raspian oder Arch benutzen (zumindest findet man dazu in der Regel Guides). Mein Ansatz an der Stelle war, da ich auf meinem x86 Server auch Ubuntu nutze, wollte ich beim Pi nichts anderes. Ob das wirklich die beste Idee war sei dahingestellt, weil man auf Ubuntu 20.04 + Pi 4 viel Pionierarbeit macht und nie so genau weiß in wie weit die Guides für andere Linux Derivate sich übertragen lassen.
Wenn es um Umbuntu geht, dann ist in der Regel auch die Rede von Grub, der wiederum mit dem Pi nicht funktioniert. Insofern muss man versuchen bei jedem Guide die Versatzstücke zu finden, die für die Kombination Pi + Ubuntu 20.04 passen bzw. übertragbar sind.
Das fällt anfangs enorm schwer, wenn man noch kein (tieferes) Verständnis der Materie hat.
Ich finde es allerdings schon etwas arm (wie doppeldeutig), dass es im Standard kein simples Bootmenü gibt (per Text reicht ja), mit dem man verschiedene Konfigurationen auswählen kann (Eintrag 1 cmdfile1.txt, Eintrag 2 cmdfile2.txt usw.) und ggf. die dazu passende initramfs.
Btrfs
Ich geben den Teil etwas verkürzt wieder. Unter anderem auch deshalb, weil ich die Konfiguration jetzt nicht mehr habe uns somit nicht alles 1:1 darstellen kann.
Es gibt recht viele Guides zu btrfs. Ich denke es ist an der Stelle hilfreich einfach einige Screenshots zu sehen bei denen man erkennt was in den Konfigurationsdateien steht bzw. passend dazu was die IDs der Laufwerke sind. Genau das sparen die meisten Guides leider aus. Es ist eine ziemlich blöde Idee mit /dev/sdax zu arbeiten, weil das Anstecken einer externen Platte dazu führen kann, das die Bezeichnungen nicht mehr passen. Keine Ahnung warum viele Guides das so handhaben.
Die Hauptvorteile von Btrfs sind, dass es komprimiert (on the fly) und vor allem die Snapshotfunktionalität im Kombination mit Copy on write. D.h. es werden ggf. mit Zusatztools (snapper) automatisch Snapshots in bestimmten Zeitabständen oder nach Aktionen (Boot, apt install) vorgehalten. Diese lassen sich vollständig oder auch beliebige Dateien daraus zurückspielen.
Die Komprimierung bringt bereits Vorteile, richtig gut wird es dann aber in Kombination mit den Snapshots. Ohne Snapshots sieht man, dass lediglich die Komprimierung greift. Durch die Snapshots steigt das Verhältnis und das Referenced Total liegt mit grob 20 Scnapshots bei 900GB. Soll heißen, wenn ich mit der Häufigkeit Snapshots erstellen würde, wie Snapper das macht, dann würde ich ein 900GB ext4 Volume benötigen. Das gleiche auf 200GB unterzubringen ist schon praktisch. Man bekommt also sehr viel mehr Komfort und Sicherheit fast ohne Kosten.
Der wesentliche Unterschied zur Konfiguration mit Luks ist, dass man statt mit den Mappern direkt mit den UUIDs arbeitet. Sonst ist alles gleich.
Beispiel aus der fstab:
LABEL=writable /sd ext4 defaults 0 0 LABEL=system-boot /boot/firmware vfat defaults 0 1 UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /btrfs btrfs defaults,ssd,compress=zstd:1 0 0 UUID=cbb8245c-32ae-4800-9730-b17f9479b00d / btrfs defaults,ssd,compress=zstd:1,subvolid=258,subvol=/ROOT 0 0 UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=260,subvol=/snapshots/ROOT_snaps 0 0 UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /btrfs/sync1/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=552,subvol=/snapshots/sync1_snaps 0 0 UUID=cbb8245c-32ae-4800-9730-b17f9479b00d /btrfs/sync2/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=553,subvol=/snapshots/sync2_snaps 0 0 UUID=863579b2-5411-4f2f-bba4-f675a21f6fd4 none swap sw 0 0
SSD darf natürlich nur an sein, wenn es sich um eine SSD handelt. Die Subvolume ID sollte bei euch identisch sein,wenn ihr ROOT oder wie auch immer ihr es nennt als erstes anlegt.
Die crypttab wird nicht benutzt und die cmdline.txt sieht entsprechend so aus:
net.ifnames=0 dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=UUID=cbb8245c-32ae-4800-9730-b17f9479b00d rootflags=subvol=ROOT rootfstype=btrfs elevator=deadline fsck.repair=no rootwait fixrtc
Leider habe ich keinen Screenshot der blkid gemacht. Die oben sichtbare ID entspricht der ID, die links angezeigt wird und nicht der ID des Subvolumes, die rechts gezeigt wird (die heißt auch nicht UUID, sondern UUID_SUB).
Luks (Verschlüsselung) mit Btrfs (Komprimierung / Snapshots)
Ich hatte es bereits oben geschrieben: Alles neu macht der Mai. Es macht keinen Sinn erst btrfs aufzusetzen und dann Luks, sondern nur andersrum, wenn man beides nutzen möchte.
Wie sieht das Minimalsetup aus:
Luks
—Btrfs
——Subvol 1
———Subvol 3
——Subvol 2
——Subvol 4
Luks beinhaltet also Btrfs (es können natürlich auch andere Dateisysteme genutzt werden). Das heißt die Partition wird zuerst mit Luks vorbereitet, sobald das erfolgt ist, kann man die Partition mit Btrfs formatieren und anschließend Volumes anlegen.
Im Gegensatz zu einem reinen Btrfs Setup, bei dem man nur mit der /etc/fstab arbeitet, kommt bei dem Luks Setup noch die /etc/crypttab hinzu, die etwas biestig ist. Man kann da gerne schon mal etwas Zeit verplempern, wenn man zum Beispiel oben eine Kommentarzeile hat (das war bei mir im Standard so), und dann Folgeeinträge schlicht ignoriert werden.
Performance:
Das Raspberry Pi hat keine Hardwareunterstützung für Verschlüsselung. Das kennt man von anderen Prozessoren heute nicht mehr. Um die zu erwartende Leistung abzuschätzen kann man zwei Benchmarks nutzen:
Variante 1: Standard
Anmerkung: Pi auf 1650 / 600 mit einem kompletten Webserver Apache, Nginx, Elasticsearch mit MysqlDB, Postfix, Dovecot usw. im Hintergrund
Falls cyptsetup nicht installiert ist, müsst ihr das Paket installieren (ich bin mir gerade nicht ganz sicher, ob es im Standard drauf war aber ich meine schon)
cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 437636 iterations per second for 256-bit key
PBKDF2-sha256 696265 iterations per second for 256-bit key
PBKDF2-sha512 550144 iterations per second for 256-bit key
PBKDF2-ripemd160 358120 iterations per second for 256-bit key
PBKDF2-whirlpool 136249 iterations per second for 256-bit key
argon2i 4 iterations, 273064 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 4 iterations, 260490 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 24.8 MiB/s 83.6 MiB/s
serpent-cbc 128b 37.8 MiB/s 39.4 MiB/s
twofish-cbc 128b 61.2 MiB/s 62.1 MiB/s
aes-cbc 256b 19.0 MiB/s 63.6 MiB/s
serpent-cbc 256b 39.3 MiB/s 39.6 MiB/s
twofish-cbc 256b 62.7 MiB/s 62.6 MiB/s
aes-xts 256b 91.3 MiB/s 80.5 MiB/s
serpent-xts 256b 39.6 MiB/s 40.0 MiB/s
twofish-xts 256b 64.5 MiB/s 65.6 MiB/s
aes-xts 512b 71.1 MiB/s 62.3 MiB/s
serpent-xts 512b 40.9 MiB/s 39.3 MiB/s
twofish-xts 512b 66.0 MiB/s 64.1 MiB/sVariante 2: Das ist ein Cipher von Google, der speziell für Prozessoren mit geringer Leistung entwickelt wurde. Eigentlich wird der von Google nur bei Übertragungsraten von 50 MB/s empfohlen. So ganz traut man der Sicherheit wohl nicht.
[root@pi ~]# cryptsetup benchmark -c xchacha12,aes-adiantum # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption xchacha12,aes-adiantum 256b 170.5 MiB/s 179.7 MiB/s
Ohne Verschlüsselung und Komprimierung wären lesend theoretisch um die 380MB/s möglich. Praktisch muss der Pi die aber auch erst mal verarbeiten. Fakt ist: Schneller wird der Pi nicht durch Verschlüsselung und Komprimierung (zumindest nicht bei einer SSD – bei einer micro SD kann sich durch die deutlich geringeren Datenraten die Komprimierung sogar positiv auswirken).
Mit Verschlüsselung und Komprimierung und BTRFS Dateisystem wird es schon weniger aber die Werte sind trotzdem gut:
Sysbench mit Btrfs schreibend (ZSTD:1 Komprimierung ohne Luks – zu dem Zeitpunkt lief auf dem Pi auch im Hintergrund noch etwas weniger als beim folgenden Test mit Luks):
Sysbench mit Btrfs schreibend (ZSTD:1 Komprimierung und Luks):
sysbench --test=fileio --file-test-mode=seqwr run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Initializing worker threads...
Threads started!
File operations:
reads/s: 0.00
writes/s: 7730.45
fsyncs/s: 9902.57
Throughput:
Throughput:
read, MiB/s: 0.00
written, MiB/s: 120.79
General statistics:
total time: 10.0090s
total number of events: 176420
Latency (ms):
min: 0.00
avg: 0.06
max: 25.59
95th percentile: 0.04
sum: 9886.92
Threads fairness:
events (avg/stddev): 176420.0000/0.00
execution time (avg/stddev): 9.8869/0.00
Das entspricht ca. 15% Einbruch.
Selbst wenn man das mit einem x86 VPServer vergleicht, der 15€ im Monat kostet kommt der Pi sehr gut weg und gewinnt in dieser Disziplin ziemlich locker.
Ans Werk:
Zuerst: Macht ein Backup oder auch zwei. Ich bin so gerade um einen Vollcrash drum rum gekommen, das letzte Werk der microSD war das überspielen der Daten auf die SSD. Zum Glück hatte ich noch ein Image auf dem Windows PC und das Überspielen hat noch funktioniert. Das Image war auf einem älteren Stand.
Die Partitionen selbst sind ggf. vorhanden oder können mit Gparted erstellt werden. Dafür in die grafische Oberfläche Wechseln (z.B. Ubuntu Desktop, x2go, xrdp) was auch immer ihr nutzt. Ich verwende bei einem Remotezugang in der Regel x2go. Bei xrdp hatte ich teilweise probleme grafische Tools per Remotezugang zu starten und die volle Desktopumbebung auf dem Pi schluckt noch mal mehr Ressourcen und ist auch unpraktisch, weil ich alle Unterlagen auf meinem Windows Rechner habe.
sudo gparted
Anschließend eine Partitionsgröße vorgeben und als Dateisystem keins auswählen. Wenn die Partition vorhanden ist das Dateisystem ggf. löschen. Wenn ihr auch eine Swappartition erstellen wollt ist jetzt der richtige Zeitpunkt. Später Luks Partitionen zu verändern kann ziemlich ekelig sein. Auch die Swap Partition muss verschlüsselt werden, da sich dort alle Daten befinden können, die man bearbeitet hat.
Achtung: Da der PI 4 bald von externen Medien booten können wird, sollte man am Beginn des Mediums 256MB frei lassen für einen Bootbereich (also nicht so wie ich im folgenden Screenshot!).
Zuerst aushängen, dann formatieren als ohne Formatierung (Luks mit Btrfs ist in Gparted leider nicht verfügbar, also per Kommandozeile). Auf obigem Screenshot ist schon alles fertig.
Theoretisch kann man auch ohne separate Partition mit Swap arbeiten aber bei btrfs finden sich diverse (vermutlich alles veraltete) Informationen, dass es ggf. Probleme damit geben kann. Da ich aber auch keinen Vorteil darin sehe die Swap Datei in der Root Konfiguration zu haben und auch btrfs keine Vorteile dafür bringt, habe ich eine separate Partition mit 6GB erstellt um später ggf. auch Hibernation nutzen zu können.
Vorbereiten Partition mit Luks:
sudo cryptsetup luksFormat --type=luks2 -c xchacha12,aes-adiantum-plain64 -s 256 -h sha512 --use-urandom /dev/sda1
sda1 ggf. anpassen. Ich habe ein externes Laufwerk genommen, man kann das natürlich auch mit der SSD Karte machen. Faktisch braucht man aber eh ein externes Laufwerk oder ein bootbaren USB Stick um das Setup aufzusetzen, da man natürlich nicht das laufende Rootlaufwerk im Betrieb neu aufsetzten kann und man vermutlich auch die Daten überspielen möchte.
ACHTUNG: Der folgende Schritt löscht den Inhalt der Partition vollständig. Ihr werdet vorher gewarnt. Wenn ihr die Warnung übergeht, sind die Daten weg, wenn ihr vorher bereits das Dateisystem gelöscht habt, hat sich das aber eh schon erledigt.
Den Schritt muss man mit YES bestätigen und anschließend muss man das PW vergeben.
sudo cryptsetup luksOpen /dev/sda1 cryptrootssd
Öffnen des Luks Devices. Anschließend kommt die Passwortabfrage. Den Bezeichner cryptrootssd könnt ihr beliebig vergeben. Der wird aber im folgenden immer wieder benötigt.
Nun könnte man weitere Keyfiles oder Passwörter zum Luks Header hinzufügen, wenn Bedarf vorhanden ist.
Erstellung des Btrfs Dateisystems innerhalb des geöffneten Luks devices.
sudo mkfs.btrfs -L btrfs /dev/mapper/cryptrootssd
Hier seht ihr einen entscheidenden Unterschied zur bisherigen Handhabung Btrfs ohne Luks. Ab jetzt wird ausschließlich mit Mapper devices und dem soeben vergebenen Namen gearbeitet. L ist das Label (das ist Optional aber ich fand es relativ praktisch für die spätere Adressierbarkeit – wie das Label heißt ist auch wieder euch überlassen).
Es wird ein Verzeichnis für einen Mountpunkt erstellt.
Mkdir /btrfs
Einhängen der btrfs Partition unter btrfs.
sudo mount -o compress=zstd:1 /dev/mapper/cryptrootssd /btrfs
Volumes erstellen
Die Volumes sind im Wesentlichen für Snapshots relevant, weil sie sich später einzeln zurücksetzen lassen. Wie detailliert man das macht ist jedem selber überlassen. Theoretisch kann man für jedes Verzeichnis ein Volume erstellen, sinnvoll ist das aber meiner Meinung nach nicht. Ggf. macht jeweils ein Volume für /var/ /etc/ /home/ Sinn.
Das ist letztendlich eine Geschmacksfrage. Ein definitiv konsistenter Snapshot entspricht dem gesamten Root Laufwerk.
Das Verzeichnis /etc/ (alle Konfigurationen) lässt ich ggf. konsistent separat zurückspielen, wenn keine Programme dazu gekommen sind oder entfernt wurden. /var/ beinhaltet oft Logs, Mysql Datenbanken, Webseiten und /home/ ist zumindest dafür gedacht Benutzerdaten abzulegen.
Ich habe mich für folgendes Setup entschieden:
btrfs (label und Einhägepunkt)
—ROOT
—sync1 (Backup von einem Server Root)
—sync2 (Backup von zweitem Server Root)
—snapshots
——ROOT_snaps
——sync1_snaps
——sync2_snaps
Ob man die Snapshots direkt nutzt oder nicht ist erst mal nicht relevant. Mit dem Layout sind sie aber zumindest vorbereitet.
Volumes anlegen
sudo btrfs subvolume create /btrfs/ROOT sudo btrfs subvolume create /btrfs/sync1 sudo btrfs subvolume create /btrfs/sync2 sudo btrfs subvolume create /btrfs/snapshots sudo btrfs subvolume create /btrfs/snapshots/ROOT_snaps sudo btrfs subvolume create /btrfs/snapshots/sync1_snaps sudo btrfs subvolume create /btrfs/snapshots/sync2_snaps
Und das Ergebnis bewundern:
sudo btrfs subvolume list -p /btrfs/ ID 256 gen 15306 parent 5 top level 5 path ROOT ID 258 gen 15286 parent 5 top level 5 path sync1 ID 259 gen 15287 parent 5 top level 5 path sync2 ID 260 gen 14645 parent 5 top level 5 path snapshots ID 261 gen 15290 parent 260 top level 260 path snapshots/ROOT_snaps ID 262 gen 15290 parent 260 top level 260 path snapshots/sync1_snaps ID 263 gen 15290 parent 260 top level 260 path snapshots/sync2_snaps
Wichtig dabei sind vor allem die IDs vorne. Die benötigt man in der /etc/fstab
Nun fehlt noch die Swap Partition.
sda2 ggf. wieder anpassen. Der Prozess ist der gleiche wie oben.
sudo cryptsetup luksFormat --type=luks2 -c xchacha12,aes-adiantum-plain64 -s 256 -h sha512 --use-urandom /dev/sda2
Öffnen
sudo cryptsetup luksOpen /dev/sda2 swap
Und als Typ Swap einrichten.
mkswap /dev/mapper/swap
Nun könnt ihr per rsync alle Datein von dem vorhandenen root Datenträger auf das root btrfs Subvolume kopieren.
Zwischenstand:
Die Vorbereitungen sind durch, nun geht es ans Eingemachte. Wie sieht blkid aus?
blkid /dev/mapper/cryptrootssd: LABEL="btrfs" UUID="282cba41-e894-4938-9b66-76b75dfb7f6d" UUID_SUB="ca8842b1-7159-45c1-b686-fc3bcadb5631" TYPE="btrfs" /dev/mapper/swap: UUID="c1f33a48-6a76-4fc9-9b39-b8298a7a7ca6" TYPE="swap" /dev/mapper/cryptrootsd: LABEL="writable" UUID="cace300f-31e8-498c-8134-b6ba9dac5d12" UUID_SUB="4e539ec9-271e-4f8b-9a96-7b78035ce67a" TYPE="btrfs" /dev/mmcblk0p1: LABEL_FATBOOT="system-boot" LABEL="system-boot" UUID="0468-A52F" TYPE="vfat" PARTUUID="87c6153d-01" /dev/mmcblk0p2: UUID="71f6f452-8efe-4d0f-8a65-01bd18237e6d" TYPE="crypto_LUKS" PARTUUID="87c6153d-02" /dev/sda1: UUID="87455e48-dae8-4e8d-8683-acc6ad6e8225" TYPE="crypto_LUKS" PARTUUID="99329026-01" /dev/sda2: UUID="8459a5c7-9b08-4e4e-b76c-f0cdb5caf4e9" TYPE="crypto_LUKS" PARTUUID="99329026-02"
- /dev/mmcblk0p1 = Boot Partition der microSD (250MB – ich würde eher 500 empfehlen um ggf. mehr Sicherheit für initramfs Images zu haben)
- /dev/mmcblk0p2 = verschlüsselte Root microSD (Kopie von der SSD mit abweichender /etc/fstab und /etc/crypttab – ca. 128GB)
- /dev/sda1 = Entspricht Luks 1 – Root Btrfs
- /dev/sda2 = Entspricht Luks 2 – Swap
- /dev/mapper/cryptrootssd = btrfs auf / in /dev/sda1
- /dev/mapper/cryptrootsd = btrfs auf / in /dev/mmcblk0p2
- /dev/mapper/swap = swap auf / in /dev/sda2
Bei euch sieht das zu dem Zeitpunkt natürlich anders aus, weil ihr maximal die SSD oder ein externes Laufwerk verschlüsselt habt und somit ggf. ein Mappereintrag weniger vorhanden ist.
Wie sieht die passende /etc/fstab dazu aus?
LABEL=system-boot /boot/firmware/ vfat defaults 0 1 /dev/mapper/cryptrootssd / btrfs defaults,ssd,compress=zstd:1,subvolid=256,subvol=/ROOT 0 0 /dev/mapper/cryptrootssd /btrfs btrfs defaults,ssd,compress=zstd:1 0 0 /dev/mapper/cryptrootssd /.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=261,subvol=/snapshots/ROOT_snaps 0 0 /dev/mapper/cryptrootssd /btrfs/sync1/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=262,subvol=/snapshots/sync1_snaps 0 0 /dev/mapper/cryptrootssd /btrfs/sync2/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=263,subvol=/snapshots/sync2_snaps 0 0 /dev/mapper/cryptrootsd /sd btrfs defaults,ssd,compress=zstd:1 0 0 /dev/mapper/swap none swap sw 0 0
Der Reihe nach:
- Ganz oben das Boot Firmware Verzeichnis, dass unter Boot eingehängt wird und die Startdateien beinhaltet.
- Dann kommt das Root Verzeichnis
- Der nächste Eintrag hängt den kompletten btrfs Baum in das Verzeichnis btrfs ein. Das ist ziemlich praktisch, auch wenn man später ggf. mit chroot arbeiten muss / möchte, um die initramfs zu erstellen.
- .snapshots wird als Volume unter Root angelegt. Da sich damit dann aber auch die Snapshots selbst unterhalb des Volumes Root, gibt es die Empfehlung die Snapshots woanders unterzubringen. Dafür habe ich also ein separates Volume angelegt. Damit Snapper damit arbeiten kann, muss es aber z.B. unter ROOT eingebunden werden, wenn man für ROOT snapshots erstellen möchte.
- Sync 1 Snapshots (analog vorheriger Punkt)
- Sync 2 Snapshots (analog vorherige beide Punkte)
- SD Laufwerk unter SD (gleiches Konzept wie bei Btrfs der ganze Baum wird eingehängt auch hier Vorteilhaft für chroot / initramfs
- Swap Partition
Und passend dazu die /etc/crypttab
cryptrootssd UUID=87455e48-dae8-4e8d-8683-acc6ad6e8225 key1 luks,initramfs,keyscript=decrypt_keyctl swap UUID=8459a5c7-9b08-4e4e-b76c-f0cdb5caf4e9 key1 luks,initramfs,keyscript=decrypt_keyctl cryptrootsd UUID=71f6f452-8efe-4d0f-8a65-01bd18237e6d key1 luks,initramfs,keyscript=decrypt_keyctl # <target name> <source device> <key file> <options>
Achtung: Als bei mir der Kommentar in der ersten Zeile stand wurden Folgeeinträge nicht erkannt. Das merkt ihr spätestens beim erstellen der initramfs
Wichtig hier die UUIDs nicht /dev/sda1 verwenden,weil letzteres nicht eindeutig ist. Die UUIDs sind die von den Luks Devices und nicht die von den Mappern. key1 ist ein Platzhalter der dafür sorgt, dass alle Laufwerke mit einem Key entschlüsselt werden können (also letztlich einer Eingabe – wenn man das nicht macht darf man beim Start 3x das Passwort eingeben – Remotelogin geht dann überhaupt nicht!). Dafür ist auch der initramfs und der keyscript Eintrag notwendig.
Die Vorbereitung ist durch. Nun fehlt noch die Initramfs. Das decrypt_key script ist nicht Ubuntu Standard, sondern muss nachinstalliert werden.
sudo apt install keyutils
Weiterhin lässt sich das Entschlüsseln nur vornehmen, wenn man direkten Zugriff auf das Pi hat (Keyboard, Bildschirm). Wenn man das auch Remote machen möchte, muss man zusätzlich Dropbear installieren.
sudo apt install dropbear
Jetzt steht noch ein wenig Konfigurationsarbeit an. Dropbear kann auf einem anderen Port laufen als der Standard SSH Login. Der Vorteil ist, dass man dann keine Sicherheitswarnungen bekommt. Faktisch war ich aber schlicht zu faul einen separaten Port in der Firewall zu öffnen und immer dran zu denken welcher Port denn nun wohl der Loginport ist. Ich bin also bei Port 22 geblieben.
Ich greife von Putty (Windows) auf das Pi zu. Somit habe ich den key mit dem Puttygen erstellt. Dafür einfach mit dem Puttygen einen Key erzeugen, den privaten Teil speichern und anschließend den öffentlichen Teil über die Zwischenablage auf den Server bringen. Der öffentliche Teil muss unter /etc/dropbear-initramfs/authorized_keys abgelegt werden.
Das Schema ist z.B. Typ, Key, Bezeichnung – also ssh-rsa key123ganzviele blabla
In der /etc/dropbear-initramfs/config
DROPBEAR_OPTIONS="-p 22"
Ich vermute das ist Standard aber schaden kann es ja nicht.
Ansonsten noch in etc/default/dropbear
NO_START=1 auf NO_START=0
Da ihr in der Regel den Dropbear nicht als SSH Zugang nach dem Boot verwenden möchtet, könnt ihr den Start des Dienstes deaktivieren:
sudo systemctl disable dropbear
Nun noch die Konfiguration der initramfs und schon kann es los gehen.
/etc/initramfs-tools/initramfs.conf
BUSYBOX=y CRYPTSETUP=y DROPBEAR=y DECRYPT_KEYCTL=y
Ich weiß nicht, ob das alles nötig ist (speziell bei dem letzten Eintrag habe ich Zweifel, ob der korrekt ist bzw. die Initramfs Erstellung erkennt eigentlich auch von alleine was benötigt wird aber doppelt hält besser.
/etc/initramfs-tools/modules
btrfs cryptsetup decrypt_keyctl busybox
Doppelt hält besser sagte ich ja schon. 😉
Nun geht es an das eigentliche Erstellen der initramfs. Bei dem ersten Laufwerk habe ich es ohne chroot gemacht. Das hat in dem Fall auch funktioniert. Beim Boot wurde das Laufwerk nicht automatisch entschlüsselt. Ich konnte aber die entsprechenden Befehle sudo cryptsetup luksOpen /dev/sda1 cryptrootssd und den Mount (siehe oben) manuell einfügen. Anschließend habe ich per exit die Busybox verlassen und konnte ganz normal ins Betriebssystem booten und dort eine initramfs erstellen.
Beim zweiten Laufwerk ist mir das nicht gelungen. Dort musste ich explizit über Chroot die initramfs erstellen, da offensichtlich das Laufwerk in der initramfs verdrahted wird. Die Guides, die ich gelesen habe hörten sich alle eher so an, als wenn das nicht der Fall ist. Zumindest sollte der Pi die cryprootssd entsperren, obwohl ich alle Configdateien vorher auf die microSD um gestellt hatte
Bevor nun neu gebootet werden kann muss noch die cmdline.txt angepasst werden (vorher Kopie erstellen):
net.ifnames=0 dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mapper/cryptrootssd rootflags=subvol=ROOT rootfstype=btrfs elevator=deadline fsck.repair=no rootwait fixrtc cryptdevice=UUID=87455e48-dae8-4e8d-8683-acc6ad6e8225:cryptrootssd
Auch dieser Eintrag bezieht sich auf die Luks ID. Wenn man wie im meinen Fall zwischen zwei Laufwerken wechselt benötigt man also zwei cmdline.txt Files und zwei initramfs (initrd.img). Einen komfortableren Weg habe ich noch nicht gefunden. Sobald der Pi 4 echten Boot von USB beherrscht kann man die SD von dem USB Laufwerk trennen und das Rumgehampel entfällt.
Das hebt auch die Wechselwirkungen im Kontext initramfs auf.
Weiterhin muss man den Raspi noch davon überzeugen die Initramfs zu nutzen. Dazu unter boot/firmware die Datei config.txt um folgenden Text ergänzen:
initramfs initrd.img followkernel
Nun noch die initramfs erstellen. Die alte initramfs wird als bakup erzeugt. Falls also irgendwas schief geht, funktioniert die noch. Wenn ihr also mit eurem ursprünglichen Bootvolume starten wollt, müsst ihr das Backup zurück kopieren. Wenn ihr mehrfach die Initramfs erstellt (siehe unten), dann macht vorher eine Sicherheitskopie, sonst hilft das Backup auch nichts mehr.
Chroot Umgebung vervollständigen:
mount /dev/mmcblk0p1 /btrfs/boot/firmware
(ggf vorher mit mkdir Verzeichnis anlegen, wenn nicht vorhanden)
mount -t proc none /btrfs/ROOT/proc
mount -t sysfs none /btrfs/ROOT/sys
Mit Root Nutzer (sicherheitshalber):
chroot /btrfs/ROOT/
Und jetzt noch eine Runde beten:
update-initramfs -u -k all
Bei der Erstellung der initramfs sollte man tunlichst darauf achten, ob Fehler ausgeworfen werden. Der einzige Fehler, den ich ignoriert habe war, dass das Root Volume nicht erkannt wurde (Sicherheitshalber hatte ich beim ersten Boot alle anderen Volumes in fstab / crypttab auskommentiert. Trotzdem kam die Meldung, obwohl nur noch ein Volume vorhanden war und das offensichtlich Root war). Wenn ich das richtig sehe, dann prüft cryptsetup nicht gegen das chroot Dateisystem, sondern gegen das System mit dem gebootet wurde. Dementsprechend können auch mehr Fehler auftreten.
Bei einem Folgeversuch habe ich dann nichts mehr auskommentiert. Geändert hat sich sowohl am Ergebnis als auch an der Fehlermeldung nichts. Das Root Volume sollte in der crypttab an erster Stelle stehen. Theoretisch ist es ja ganz leicht zu erkennen welches das Bootvolume ist – so viele Einträge, die auf / mounten gibt es in der fstab ja nun nicht. Zusätzlich steht auch in der cmdline.txt eindeutig drin wo die Reise hingeht.
Wenn man also keine Fehler sehen will muss man ggf. im Boot etc Ordner die fstab / crypttab temporär anpassen. Ich würde davon aber abraten. Wenn euch das Raspi dann abschmiert, müsst ihr in der initramfs die Werte mit cat zurückstellen. Das macht keinen Spaß.
Wenn der Raspi nicht Bootet könnt ihr entweder warten bis die initramfs auftaucht und dann versuchen das Problem zu korrigieren oder ihr steckt die microSD Karte in einen beliebigen Lauffähigen Rechner und kopiert die alte initrd.img.bak und euer cmdline.txt.bak (oder wie auch immer ihr es genannt habt) zurück. Dann startet der Pi wieder von microSD.
Wie sieht die Anmeldung aus:
Am System:
Das Timing ist etwas blöd. Oben sieht man Caching Passphrase for cryptrootssd, dann pfuscht Dropbear mit seinen Netzwerkmeldungen dazwischen. Das zweite Caching passphrase for cryptrootssd sieht man zuerst nicht. Ein simpler Druck auf die Spacetaste oder eine beliebiege andere Taste löst das Problem aber. Danach kann man das Kennwort eingeben und der Boot erfolgt. Die weiteren Laufwerke werden freigeschaltet (Achtung, die erste gedrückte Taste wird schon als erstes Zeichen im Kennwort ausgelegt).
Über Putty
Wie oben nur in dem Fall die microSD als Bootmedium
Der Bereich Auth ist für die Keyübergabe des private Key relevant.
Anmerkungen:
Ich habe sowohl mit abgeleiteten Schlüsseln als auch mit Schlüsseln in Datein experimentiert. Beides ist aus meiner Sicht nicht sinnvoll.
In einigen Konfigurationen wird für Dropbear eine feste IP vergeben. Das hat bei mir im Kontext des Cloudsetup in Ubuntu 20.04 dazu geführt, dass die Netzwerkverbindungen nicht mehr korrekt funktionierten, obwohl die Einstellungen sich nach meinem Verständnis nur auf die Startumgebung auswirken sollten. Faktisch konnten Namen aufgelöst werden zu IPs. Direkte Verbindungen zu Ips gingen aber nicht. Das hatte sich so noch nie und ergibt für mich auch keinen Sinn.
Teilweise werden in Guides externen Scripts abgelegt (hooks). Die sind nach meinen bisherigen Tests nicht erforderlich.
Spaß ist anders.
Wenn ihr das nicht nur für einen externen Datenträger wie zum Beispiel eine SSD machen wollt ist das Prozedere weitestgehend identisch. Lediglich die /etc/crypttab und die /etc/fstab unterscheiden sich. Um zwischen beiden Systemen zu wechseln müsst ihr die cmdline.txt und die initrd.img tauschen. Der Einzige Bereich wo sich die beiden Systeme unterscheiden ist die Bootpartition und dort speziell in denen beiden Datein. Bei Kernelupdates muss man entsprechend daran denken zwei neue initramds zu erstellen.
Sobald das Pi sauber von einem externen Medium bootet, kann man das ggf. etwas besser trennen. Allerdings weiß ich auch nicht was für Effekte entstehen, wenn der init auf einem älteren Kernel erfolgt als der Rest.
Der Effekt würde zum Beispiel entstehen, wenn man standardmäßig mit der SSD bootet und dort ein Kernelupdate durchführt (apt update / apt upgrade). Die initrd.img wird durch das Update auf den neusten Stand gebracht. Die zweite initrd.img für den microSD Boot aber nicht. Wenn man nun noch per rsync das Root Dateisysetem von der SSD auf die microSD synchronisiert, dann hat man bzgl. der initrd.img für die SD einen Schiefstand im Vergleich zu dem restlichen System.
Das käme wohl auf einen Versuch an, könnte aber ziemlich unschön Enden. Also besser beide Images erneuern bei einem Kernelwechsel oder ein Komplettimage der micro SD erstellen und dann testen.
Der Dropbear Remotezugang hat übrigens auch Vorteile, wenn ihr nicht wirklich “remote” seid. Erstens ist es ziemlich blöd, wenn man auf der Console ohne Nano und co arbeiten muss, dann auch noch Texte zu kopieren. Wenn sich über SSH anmeldet hat man eine Maus und copy & paste, wenn man zum Beispiel Putty nutzt.
Zweitens benötigt man dann auch immer eine angeschlossene Tastatur / einen Bildschirm.
Fazit:
Luks mit Btrfs und so einfach! Die Windows Benutzer, die sowas mit ein paar einfachen Klicks machen sind doch nur verweichlicht oder einfach vernünftiger?
Auf jeden Fall fehlt in dem Linux Luks Kontext ganz viel Liebe. Für mich ist es unverständlich, dass solche essentiellen Dinge nicht out of the Box gehen. Die Remoteöffnung ok das ist sicher ein spezieller Anwendungsfall aber Anmelden mit gleichzeitigem Freischalten von einem oder mehreren Laufwerken gehört in den Kernel und zwar ohne rumgehampel mit zusätzlichen Tools oder initramfs und zwar auch und gerade für das root Dateisystem.
Mit allen Schritten hat mich die ganze Aktion mehrere Tage gekostet und das Lesen von grob 20 Guides und versuchen darin die Versatzstücke und Zusammenhänge zu finden. Jeder hat in seinen Guides (ich sicher auch) Schritte, die nicht erforderlich sind, nicht zu Ubuntu passen oder veraltet sind. Daraus halbwegs sinnvolle Zusammenhänge zu erkennen ist nicht so einfach.
Da ich den Guide aus dem Gedächtnis zusammen geschrieben habe, gebe ich keine Garantie auf Vollständigkeit, habe aber hoffentlich alles erwischt was relevant ist und die diversen Sackgassen ausgelassen.
Ich habe jetzt folgendes Setup:
- SSD 1TB (BTRFS, Bootpartition vorbereitet, aktuell ungenutzt), Datenpartition Verschlüsselt mit Backups von 2 Servern, Swap verschlüsselt)
- microSD 128GB (BTRFS, Bootpartition geteilt, Datenparition verschlüsselt und enthält keine Backups) – wird regelmäßig per rsync aktualisiert, ist also nahe an dem Stand der SSD)
- microSD2 128GB (wie die vorherige SD per DD als 1:1 Image angelegt. Anschließend UUID, PARTUUID geändert, dev mapper von cryptrootsd auf cryptrootsd2 geändert (fstab,cmdline.txt,crypttab). Keine Aktualisierung per rsync. Liegt neben dem Pi als Notfallboot, falls ich mir die erste microSD beschädige und ich per default auf microSD Boot konfiguriert, kann aber leicht auf SSD umgestellt werden.
- Raspian (16GB microSD reicht vollig) unverschlüsselt für Firmwareupgrades
D.h. ca. 50€ für microSDs aber das Geld ist gut angelegt. Der Zeitbedarf einer evtl. Neuinstallation + Konfiguration ist sehr viel größer.
Update: 20.05.2020
Es gibt jetzt ganz frisch die ersten Beta Versionen für direkten Boot von einem USB Gerät. An dem Guide ändert das wenig. Lediglich der fstab Mount für die Firmware ändert sich von der microSD auf das entsprechende Device. Man benötigt aber die aktuell Firmware (die lässt sich nur über ein Raspian Image installieren) und dann die neuen startelf dateien. Wie und wann die nach Ubuntu kommen ist noch offen. Das kann man sich vermutlich auch manuell zusammen basteln aber ggf. macht es durchaus Sinn noch etwas zu warten.
