Mehrere luks-Container automatisch öffnen

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
rhHeini
Beiträge: 2260
Registriert: 20.04.2006 20:44:10

Mehrere luks-Container automatisch öffnen

Beitrag von rhHeini » 01.11.2017 17:42:43

Ich versuche seit Wochen unter Jessie/Stretch während des Bootens 2 oder mehr luks-Container automatisch entschlüsseln zu lassen, wie es bis Wheezy einwandfrei ging. Die Container sind unabhängig voneinander verschlüsselt. Jeder Container hat eine eigene Zeile in der crypttab und ein eigenes Keyscript zum Entschlüsseln.

Der erste Container ist in der Regel /root und swap in einem LVM, der zweite ist ein auf eine zweite Platte verlegtes /home. Das muss sofort mit eingebunden werden.

Bis Wheezy hat das einwandfrei funktioniert. War egal ob nach der ursprünglichen Methode von Janssen/Weijn mit einem Keyfile auf einem USB-Stick, oder später frei nach der Methode die in https://wiki.ubuntuusers.de/System_vers ... C3%BCssel/ beschrieben wird.
Ich verwende nicht die Skripte aus dem Artikel, sondern habe das Conf-File und die notwendigen Aktionen in einem Skript zusammengefasst.

Mit Jessie und Stretch klappt das auch mit dem ersten Eintrag in der crypttab, für weitere wird aber immer ein Key auf der Konsole abgefragt. Ich habe an der Ecke ewig rumgebastelt und kriege es nicht zum Laufen. Gibt es für dieses Problem eine Lösung?

Sogern ich meinen Hauptrechner auf Stretch upgraden würde, ohne das Feature mehrerer Container automatisch zu öffnen mache ich das nicht.

Schönen Restfeiertag, Rolf

wanne
Moderator
Beiträge: 7448
Registriert: 24.05.2010 12:39:42

Re: Mehrere luks-Container automatisch öffnen

Beitrag von wanne » 01.11.2017 20:40:21

Seit jessie werden fstab und crypttab von systemd (systemd-mount) und nicht mehr von mount und cryptsetup abgearbeitet.
Aber mit systemd sind keine Keyscripts mehr möglich. Und systemd hält das auch für ein Feature, weil man keine Scripte mehr im Bootvorgang sehen will. Da wird sich also nichts ändern.
Du hast folgende Möglichkeiten:
a) Umstieg auf System V-init
b) Umstieg auf Keyfiles statt Keyscripten.
c) Das öffnen/schlißen und mounten/unmounten der Platten als eigenen Dienst nach local-fs.target einbauen und auf fstab und crypttab zu verzichten.

b) Dürfte die einfachste Variante sein. Und die beste Wahl wenn das möglich ist. c) die universellste, die auch in recht unkonventionellen Installationen noch funktioniert. a) ist zumindest unter debian defakto nicht mehr möglich.

Willst du Hilfe zu einem der Punkte brauchst melde dich einfach nochmal.
rot: Moderator wanne spricht, default: User wanne spricht.

rhHeini
Beiträge: 2260
Registriert: 20.04.2006 20:44:10

Re: Mehrere luks-Container automatisch öffnen

Beitrag von rhHeini » 03.11.2017 21:09:06

@wanne: Danke für den Denkanstoss, ich bin jetzt einen grossen Schritt weiter, der Container meiner Datenplatte wird automatisch laut Option b) mit einem Keyfile geöffnet.

Ich habe wohl 2 Fehler gemacht:
1.) Keyfile war bei mir immer gleichbedeutend mit dem Öffnen und Ausgeben des Keyfiles per cat nach Janssen/Weijn.
2.) Ich habe dann auch nicht den kompletten Pfad für den Keyfile verwendet, sondern nur den Namen. Nachdem ich das korrigiert hatte, läuft die Entschlüsselung.
Habe da noch mal einige Threads zur Schlüsselableitung gelesen und endlich ein für mich näherungsweise passendes Beispiel gefunden das den Kronleuchter angeworfen hat.

Stand:
- Die OS-SSD wird nach der Ubuntu-Methode per Keyscript über diese Debian-spezifische Sonderlocke geöffnet.
- Der Keyfile liegt im entschlüsselten root in einem Directory versteckt.
- Die Datenplatte wird beim Boot soweit ich das bis jetzt beurteilen kann zuverlässig entschlüsselt und in /dev/mapper gelistet.

Aber ab da hängt es jetzt wieder:
- Das LVM auf der Datenplatte wird nicht erkannt/eingebunden. Es müsste da automatisch ein vgscan/vgchange angeschmissen werden.
- Dann möchte ich eigentlich automatisch ein fs-check vor dem Mounten laufen haben.

Wie kriege das möglichst einfach gebacken?

Danke, Rolf

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Mehrere luks-Container automatisch öffnen

Beitrag von rendegast » 04.11.2017 11:38:51

rhHeini hat geschrieben: Aber ab da hängt es jetzt wieder:
- Das LVM auf der Datenplatte wird nicht erkannt/eingebunden. Es müsste da automatisch ein vgscan/vgchange angeschmissen werden.
Ich habe da einen walkaround,
ausgehend von beim Start verbleibenden Prozessen 'lvm pvscan --activate ...' aus der udev-Regel.

/etc/udev/rules.d/69-lvm-metad.rules

Code: Alles auswählen

...
#RUN+="/sbin/lvm pvscan --cache --activate ay --major $major --minor $minor", ENV{LVM_SCANNED}="1"

# 20170604, stretch, Problem lvmetad <->? pvscan --cache [--activate] <->? systemd-udevd
#   Auswirkung: boot-timeout, verbleibende udevd-pvscan-Prozesse
RUN+="/bin/echo DUMMY /sbin/lvm pvscan --cache --activate ay --major $major --minor $minor"
...
Diese ersetzt durch ihren Namen die Originaldatei, welche ich per Link danach(!) verfügbar mache:
/lib/udev/rules.d/69-lvm-metad_ORIGINAL.rules -> 69-lvm-metad.rules

Der zweite Teil ist eine Ergänzung eines für den Zweck hinreichenden service
/etc/systemd/system/lvm2-lvmetad.service.d/lokal_walkaround.conf

Code: Alles auswählen

[Service]

# Cache-Laden:
#	mehrere ExecStart= nur bei Type=oneshot, also:

ExecStartPost=/bin/sleep 2
#ExecStartPost=/sbin/lvm pvscan --cache --activate ay		STARKE Probleme hiermit!! (in der Boot-Phase)
ExecStartPost=/sbin/lvm pvscan --cache
#ExecStartPost=/sbin/lvm vgscan --cache				unnoetig

Dadurch erreiche ich ein konfliktfreies Einlesen der PV und das Aktivieren klappt insgesamt flott,
nicht nur beim Booten.



- Dann möchte ich eigentlich automatisch ein fs-check vor dem Mounten laufen haben.
Du könntest bei einem ext-Dateisystem 'tune2fs -c max-mount-counts -C mount-counts' ensprechend setzen.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

rhHeini
Beiträge: 2260
Registriert: 20.04.2006 20:44:10

Re: Mehrere luks-Container automatisch öffnen

Beitrag von rhHeini » 05.11.2017 14:00:51

Hallo rendegast,

diese Regel existiert bei meinem Stretch nicht:
rendegast hat geschrieben: ↑ zum Beitrag ↑
04.11.2017 11:38:51
/etc/udev/rules.d/69-lvm-metad.rules
, wohl die
rendegast hat geschrieben: ↑ zum Beitrag ↑
04.11.2017 11:38:51
/lib/udev/rules.d/69-lvm-metad(_ORIGINAL).rules
Also die aktivieren per Link?

Warum ein pvscan? Wenn ich ein LVM manuell einbinde, mache ich immer ein vgscan.

Nachtrag: habe gerade in /dev/mapper nachgesehen, diesmal sind die LVs der Datenplatte beide da, ohne das ich da eingegriffen habe? :?:

Gruss, Rolf

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Mehrere luks-Container automatisch öffnen

Beitrag von rendegast » 05.11.2017 14:59:47

rhHeini hat geschrieben: diese Regel existiert bei meinem Stretch nicht:
/etc/udev/rules.d/69-lvm-metad.rules
Es ist eine Kopie der Origianldatei, nur halt mit einer dummy-Aktion.
Warum ein pvscan? Wenn ich ein LVM manuell einbinde, mache ich immer ein vgscan.
Das blanke pvscan dient dazu, dem Cache des lvm-Dienstes die vorhandenen pv bekannt zu machen.
Das 'sleep' ist eine für mein System austarierte Verzögerung.

Der Link
/lib/udev/rules.d/69-lvm-metad_ORIGINAL.rules -> 69-lvm-metad.rules
kommt bei Erstellung/Löschung eines pv während des Betriebs zum Einsatz.

Ich habe hier eine Umgebung mit einem Dateisystem auf mehr als einem Dutzend hintereinanderliegenden PV auf einer HDD.
Bei einem Starten des Systems habe ich einen mehrere Minuten langen Hänger,
danach verbleiben etliche Prozesse 'lvm pvscan --activate ...' (imo resultierend aus der udev-Regel).

Der ganze walkaround dient zur Umgehung dieses Verhaltens,
wohl irgendein Verschlucken durch den Versuch der parallelen Verarbeitung.




Der im TO geschilderte Fehler schien mir meinem Grundproblem ähnlich.
Zudem steckt einige Zeit in der Erarbeitung des walkarounds, sodaß ich ihn einfach mal posten wollte.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

rhHeini
Beiträge: 2260
Registriert: 20.04.2006 20:44:10

Re: Mehrere luks-Container automatisch öffnen

Beitrag von rhHeini » 05.11.2017 18:22:08

@rendegast: Danke für den Hinweis auf den walkaround, ich will aber erst mal versuchen zu verstehen ob/wie ich das mit systemd-Units hinkriegen kann, da meine Konfiguration deutlich einfacher zu sein scheint als Deine.
rhHeini hat geschrieben: ↑ zum Beitrag ↑
05.11.2017 14:00:51
Nachtrag: habe gerade in /dev/mapper nachgesehen, diesmal sind die LVs der Datenplatte beide da, ohne das ich da eingegriffen habe?
Stimmt nicht ganz, hatte vergessen das ich mit

Code: Alles auswählen

systemctl --system daemon-reload
eine Unit erstellt und nach Wiki-Artikel https://wiki.debianforum.de/Cryptsetup_ ... _USB-Stick nach /etc/systemd/system kopiert habe.

Aus irgendeinem Grunde hat das erst beim erneuten Boot heute funktioniert, oder ich habe da was übersehen. Jedenfalls wird das LVM auf der grossen Platte wiederholt auch geöffnet.

Daraufhin habe ich mal die Bootmeldungen durchgeschaut ob ich da was von einem fsck der logischen Datenträger sehe, da ist aber nichts. Kann man das nicht auch durch die gleiche Unit erreichen? Hier ist die eingefügte Unit:

Code: Alles auswählen

# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
RequiresMountsFor=/..........key
BindsTo=dev-disk-by\x2duuid-abcdef.....device
After=dev-disk-by\x2duuid-abcdef.....device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
ExecStart=/lib/systemd/systemd-cryptsetup attach 'bigdrive_crypt' '/dev/disk/by-uuid/abcdef....' '/..........key' 'luks,discard'
ExecStop=/lib/systemd/systemd-cryptsetup detach 'bigdrive_crypt'
Gruss, Rolf

Antworten