[gelöst] Connect-Reihenfolge: CryptHDDevice+Key-USB-Stick

[TomL]

Moin

Im Moment kaue ich auf ner Frage rum (wie auf ner alten schuhsohle) und krieg das irgendwie nicht logisch auf die Reihe. Ich habe ne verschlüsselte externe Festplatte und das passende Keyfile auf einem USB-Stick. Rein logisch wird das prima funktionieren, wenn zuerst der Stick eingesteckt ist und sich via udev-rule in ein bestimmtes Verzeichnis mountet. Wenn ich danach die Platte verbinde schaut deren udev-Regel+Script nach diesem Key-mountpoint und entschlüsselt damit die Platte. Die udev-Regel für den Stick habe ich heute erstellt und getestet, und sie funktioniert bestens.... sogar mit 2 Partitionen auf dem Stick.

Aber wie regelt man das, wenn die Platte zuerst verbunden wurde und noch kein Key-Stick verfügbar ist. Dann läuft zunächst die udev-Regel+Script für die HD ins leere, weil der USB-Stick noch fehlt. Soweit auch ok. Aber wie regel ich das, wenn ich nun zur Laufzeit nachträglich die Platte entschlüsseln möchte... also der Key-Stick "nachgereicht" wird. Der Stickt mountet sich passend in das Verzeichnis, aber wissen von der Platte tut er nix.... und welches Device die HD ist... weiss er auch nicht. Eigentlich müsste ich jetzt das HD-Device von Hand raussuchen und das HD-Uncrypt-Mount-Script ebenfalls manuell starten.

Gibts da noch ne andere Möglichkeit oder muss ich immer die Reihenfolge einhalten: zuerst den Stick und dann die HD?

[NAB]

Öhm ... wenn, wie du so schön sagst, das HDD-Script ins Leere mountet, dann scheint es ja keinen Schaden anzurichten, wenn eine von beiden Komponenten fehlt.

Dann lagere den Teil, der mounted, doch einfach in ein eigenes Script aus, und das wird sowohl von der USB-Stick- als auch von der HDD-Regel ausgeführt. Eine von beiden wird schon treffen.

[TomL]

Öhm ... wenn, wie du so schön sagst, das HDD-Script ins Leere mountet, dann scheint es ja keinen Schaden anzurichten, wenn eine von beiden Komponenten fehlt.

Genau, es passiert schlichtweg gar nix. Das ist ok.

Dann lagere den Teil, der mounted, doch einfach in ein eigenes Script aus, und das wird sowohl von der USB-Stick- als auch von der HDD-Regel ausgeführt. Eine von beiden wird schon treffen.

Ist der Stick zuerst verbunden, heisst er sdb1, die Platte dann sdc1. In der Konstellation weiss zwar die udev-Regel für die HD, dass die Platte sdc1 heißt, das hat aber nur "interne" Bedeutung. Und da der Stick bereits gemountet ist, ist die Kenntnis von sdb1 nicht notwendig.

Das Problem besteht aber bei umgekehrter Konstellation.Das Problem ist: wurde die HD zuerst verbunden, muss der nachträglich verbundene Stick diese HD ermitteln oder identifizieren.Man könnte das auch einfach umgehen und fest unterstellen, das, wenn der Stick sdc1 ist, die HD sdb1 sein muss. Das funktioniert allerdings nur solange nicht noch irgendwas vergessenes via usb angeschlossen ist. Eine Lösung wäre vielleicht, wenn die udev-Regel für die Crypt-HD eine ID nach /tmp schreiben würde... und das uncrypt-script des Sticks danach sucht.

[JTH]

Du könntest an der Stelle zum Mounten UUIDs, Labels etc. [1] benutzen, die verändern sich nicht mit der Reihenfolge des Verbindens.

[1] https://wiki.debian.org/Part-UUID

[TomL]

Ja, das ist klar... aber das ändert nix an dem Problem, dass der nachträglich verbundene Key-Stick die Platte identifizieren muss, um deren UUID zu verwenden. Ich habe vier ältere und ansonsten überflüssige 2,5"-HDs, die ich heute (mangels anderer Verwendung) (zufällig zyklisch) rotierend zusätzlich zu den normalen Backups verwende. Immer eine davon befindet sich außerdem ausser Haus.

Je mehr ich überlege, komme ich auf die Lösung, dass die udev-Regeln für diese HDs immer eine ID (entweder die UUID oder besser die Serial-ID) nach /tmp schreiben. Ist der Stick bereits drin, wird das Uncrypt-Script von der HD-udev-Regel gestartet, welches diese ID auswertet. Wird der Stick nachgereicht, startet dessen udev-Regel das Uncrypt-Script.... welches dann die ID findet und auswertet.... *hmmm*

Damit die Connect-Reihenfolge der beiden Geräte (Crypt-HD und Key-Stick) beliebig bleiben kann, braucht es eine gemeinsame Schnittstelle.... möglicherweise dieses /tmp-File. Ich weiss nicht, obs noch andere Möglichkeiten gibt.

[JTH]

Wenn nie mehrere der Festplatten zu selben Zeit an dem Rechner angehängt sind, könntest du auch den Festplatten das selbe Label oder sogar die selbe UUID geben (ob das so schön ist, ist eine andere Frage). Oder du hast in deinem Skript eine Liste der möglichen UUIDs und guckst, ob eine davon gerade angehängt ist.

[TomL]

Was mir daran nicht gefällt, ist der Umstand, dass es ein Glückspiel ist... die HD kann (als erster verbunden) sdb1 heissen. War aber der Stick vorher drin, kann sie auch sdc1 heissen. Hängt auf der Rückseite noch ein vergessener anderer Stick könnte sie auch sdd1 heissen.

Mir kommt gerade in den Sinn, dass ich momentan auch noch nicht weiss, ob cryptsetup überhaupt die UUID versteht oder will es das Device? Im Moment schwebt mir ne Referenztabelle als Lösung vor... zwischen Serial-ID (bekannt in der udev-Regel) der HD und der UUID .... muss mal sehen, wie ich das so einfach wie möglich umsetze.

[NAB]

Nachdem es jetzt auf einmal um mehrere Festplatten geht, stellt sich natürlich die Frage, ob es auch mehrere USB-Sticks gibt.

Aber prinzipiell könnte sich das Script ganz doof stellen und einfach jede beliebige Partition zu entschlüsseln versuchen ... sdc1 nach /dev/mapper/sdc1_crypt ... sdd1 nach sdd1_crypt ... und nachher nachgucken, ob das entschlüsselte Gerät auf einmal existiert. Dann müsstest du dich nur noch entscheiden, wo du es hinmounten möchtest.

Ansonsten schau dir mal
ls -la /dev/disk/by-id/
an. Damit müsstest du eine Zuordnung basteln können. Die /dev/-Pfade schluckt auch cryptsetup.

[halo44]

Kann man nicht mit ungefähr einer solchen udev-Regel die Geräteadresse selbst festlegen :

Code: Alles auswählen

SUBSYSTEM==“block“, ACTION==“add“,ENV{ID_MODEL}==“Modellbezeichnung“, ENV{ID_VENDOR}==“Anbieter“,ENV{ID_SERIAL_SHORT}==“12345678“,SYMLINK+=“usbstick“

Der Stick steht in diesem Beispiel anschließend unter /dev/usbstick und nicht /dev/sdxy zur Verfügung.

Bei mir funktionierts so.

Gruss H.

P.S. Edit, wegen einer Leerstelle zuviel, die ich trotzdem nicht entfernen kann

[TomL]

Kann man nicht mit ungefähr einer solchen udev-Regel die Geräteadresse selbst festlegen :

Code: Alles auswählen

SUBSYSTEM==“block“, ACTION==“add“,ENV{ID_MODEL}==“Modellbezeichnung“, ENV{ID_VENDOR}==“Anbieter“,ENV{ID_SERIAL_SHORT}==“12345678“,SYMLINK+=“usbstick“

Der Stick steht in diesem Beispiel anschließend unter /dev/usbstick und nicht /dev/sdxy zur Verfügung.

Maaaaanomann... das ich da nicht selber drauf gekommen bin, zumal ich das mit anderen USB-Sticks schon genau so gemacht habe Manchmal steht man sich mit zu komplizierten Überlegungen echt selber im Weg. Ich glaube, das ist die Lösung.... das muss ich jetzt nur mal zu Ende denken....

Danke!

[dirk11]

Dann aber bitte auch die entgültige Lösung hier vorstellen!