Verschlüsselte Festplatte (LUKS) mit USB-Stick bei Systemstart entschlüsseln

Oftmals werden auf dem PC oder Home-Server sensible Daten gespeichert. Hier sollte man immer überlegen, ob eine Verschlüsselung der Datenträger lohnt. Wenn der Server zu Hause steht, hat prinzipiell kein Dritter physischen Zugriff auf das System. Aber was passiert, wenn der Home-Server bei einem Einbruch gestohlen wird?. Auch wenn es der Dieb eher auf die Hardware abgesehen hat, bleibt ein ungutes Gefühl, wenn die Daten auf dem Server unverschlüsselt gespeichert wurden. In der Theorie haben dann Dritte Zugriff auf das System und alle darauf gespeicherten Daten.

Die Verschlüsselung von Datenträgern ist unter Linux schnell eingerichtet. Das Mittel der Wahl ist dabei meistens LUKS („Linux Unified Key Setup“). Hier kommt dann meist ein Passwort, oder auch ein sog. Key-File (Dateien mit beliebigem Inhalt – am besten eine zufällige Byte-Folge) zum Einsatz, mit dem eine Festplatte entschlüsselt werden kann.

Die Sicherheit erkauft man sich dann allerdings durch einen Mangel an Komfort: Nach dem Start des Systems müssen verschlüsselte Festplatten erst einmal mittels Passwort/Key-File entschlüsselt und anschließend gemountet werden. Das bedeutet nach jedem (Neu-)Start des Systems Handarbeit.

Um diese Einschränkungen zu umgehen, zeigt dieser Artikel, wie ein USB-Stick zum Entschlüsseln von Datenträgern beim Systemstart genutzt werden kann. Der Clou an der Sache: Wir speichern das Key-File nicht einfach auf dem USB-Stick selbst, sondern noch vor der ersten Partition. Auf diese Weise kann der Stick noch normal verwendet (und auch formatiert) werden. Ebenfalls ist es nicht ersichtlich, dass ein Key-File auf dem Stick enthalten ist, sollte dieser mal in falsche Hände geraten.

Update-Historie (letztes Update: 11.08.2019)
  • 11.08.2019:
    • Korrektur: Beim Erzeugen der Schlüssel-Datei wurden nur 8 statt 16 Sektoren genutzt.

Voraussetzungen

Der Artikel basiert auf Ubuntu Server 18.04 LTS, sollte allerdings auch auf andere Distributionen übertragbar sein.

Es wird nur ein beliebiger USB-Stick benötigt – die Speichergröße ist hierbei egal. Ich verwende beispielsweise einen USB-Stick von SanDisk (Affiliate-Link).

Die zu verschlüsselnde Festplatte ist in diesem Artikel beispielhaft eine zweite interne Festplatte (also nicht die System-Partition). Dadurch kann der ganze Workflow vom Verschlüsseln der Festplatte selbst, bis zum Entschlüsseln mittels USB-Stick bei Systemstart gezeigt werden.

Wichtig: Beim Verschlüsseln der Festplatte gehen dabei alle Daten verloren. Sind bereits Daten auf der Festplatte vorhanden, müssen diese vorher gesichert und nach dem Prozess wieder zurück gespielt werden.
Ebenfalls ist darauf zu achten, bei sämtlichen Befehlen die richtige Festplatte/Partition auszuwählen/anzugeben. Wird eine falsches Gerät adressiert, kann man schnell das komplette System lahm legen (weil z.B. die Daten der System-Partition überschrieben/gelöscht werden). Daher bitte die Befehle nicht einfach kopieren, sondern manuell in der Kommandozeile eingeben und am besten vor dem Ausführen nochmals kontrollieren.

Generell empfiehlt es sich, ein Backup des Systems anzufertigen, bevor die Schritte des Artikels durchgeführt werden.

Festplatte mit LUKS verschlüsseln

Ich gehe im folgenden davon aus, dass die zweite Festplatte im System unter /dev/sdb erkannt wird. Ebenfalls kommt im Setup weder LVM, noch RAID zum Einsatz. Bei LUKS in Verbindung mit LVM bzw. RAID gibt es einige zusätzliche Dinge zu beachten (siehe LUKS FAQ).

Bei der Verschlüsselung mittels LUKS hat man die Wahl, ob man die Festplatte direkt („Raw Device“), oder eine auf der Festplatte zuvor angelegte Partition verschlüsseln möchte. In diesem Beispiel wird die Festplatte (ohne Partition) verschlüsselt, da ich keine Aufteilung in unterschiedliche Partitionen benötige. Wer lieber eine Partition verschlüsseln möchte, muss dies in den entsprechenden Befehlen beachten. Hier ist dann nicht das Device an sich (/dev/sdb), sondern die Partition anzugeben (z.B. /dev/sdb1).

Zunächst wird die benötigte Software installiert:

apt-get update && apt-get install crypsteup dosfstools

Mit folgendem Befehl wird kontrolliert, ob die Festplatte richtig angeschlossen ist und ob die Gerätedatei (/dev/sdb) auch korrekt ist:

fdisk -l

Am besten achtet man hier auf die Größenangaben der Festplatte. Der Output des Programms sieht dann für /dev/sdb beispielhaft so aus:

Disk /dev/sdb: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Wenn es sich um eine Festplatte handelt, die bereits vorher in Benutzung war, sollte diese vor der Verschlüsselung nochmals mit zufälligen Daten überschrieben werden. Dies macht die Verschlüsselung dann etwas sicherer, da keine unverschlüsselten Daten mehr auf der Festplatte vorliegen.

dd if=/dev/urandom of=/dev/sdb

Achtung: Dieser Vorgang kann gerade bei größeren Festplatten sehr lange dauern!

Anschließend wird ein evtl. vorhandenes Dateisystem auf der Festplatte gelöscht:

wipefs -a /dev/sdb

Nun kann auch schon das interaktive Setup von LUKS aufgerufen werden:

cryptsetup luksFormat /dev/sdb

Hier ist ein Passwort einzugeben, mit dem das Laufwerk entschlüsselt werden kann. Das Passwort sollte dabei eine ausreichende Länge haben.

Tipp: Ein Passwort-Manager (z.B. KeePassXC) hilft nicht nur dabei, Passwörter sicher aufzubewahren, sondern kann auch bei der Generierung sicherer Passwörter helfen.

Um anschließend Zugriff auf die Festplatte zu erlangen, muss diese durch einen Device-Mapper als Geräte-Datei bereit gestellt werden:

cryptsetup luksOpen /dev/sdb crypt_hdd1

crypt_hdd1 ist anschließend der Name der entschlüsselten Festplatte. Diese kann nun wie eine normale Festplatte gemountet werden:

mkdir -p /media/hdd1 
mount /dev/mapper/crypt_hdd1 /media/hdd1

Der Zugriff auf die Festplatte erfolgt in diesem Beispiel dann über den Ordner /media/hdd1.

Nun kann auf der Festplatte ein Dateisystem erzeugt werden (in diesem Fall ext4):

mkfs.ext4 /dev/mapper/crypt_hdd1

Zusammenfassend nochmals die Befehle zum Einhängen/Aushängen der verschlüsselten Festplatte.

Einhängen/Mounten: 

cryptsetup luksOpen /dev/sdb crypt_hdd1 
mount /dev/mapper/crypt_hdd1 /media/hdd1

Hier wird man nach dem ersten Befehl nach dem Passwort gefragt. Ohne dieses lässt sich die Platte nicht mehr entschlüsseln.

Aushängen/Unmounten: 

umount /mnt/crypt_hdd1 
cryptsetup luksClose crypt_hdd1

Durch luksClose wird die Verschlüsselung der Festplatte wieder aktiv, so dass ohne vorheriges Entschlüsseln/Mounten kein Zugriff mehr erfolgen kann.

USB-Stick zum Entschlüsseln einrichten

Als nächstes wird der USB-Stick vorbereitet, so dass dieser zum Entschlüsseln der Festplatte genutzt werden kann.

Achtung: Auch hier gehen wieder alle Daten verloren, die auf dem USB-Stick gespeichert sind. Wie schon zuvor ist darauf zu achten, dass man das richtige Gerät wählt. In diesem Beispiel erfolgt der Zugriff auf den USB-Stick über /dev/sdc.

Zum Einrichten des USB-Sticks benutzen wir wieder fdisk:

fdisk /dev/sdc

Mit folgenden Eingaben wird der Stick vorbereitet:

  • d: Bestehende Partition löschen.
  • o: Partitionstabelle neu erstellen.
  • n: Neue Partition erstellen. Dies sollte eine primäre Partition sein (p). Beginn der Partition sollte Sektor 2048 sein, dies ist die Standard-Einstellung.
  • w: Speichern und beenden.
Der USB-Stick wird mittels fdisk vorbereitet

Nun kann auf dem USB-Stick ein Dateisystem angelegt werden. Ich nehme hier ein FAT32-Dateisystem, damit der Stick sowohl unter Linux, als auch unter Windows verwendet werden kann. Wenn der Stick ausschließlich unter Linux verwendet werden soll, kann natürlich auch ein ext2/3/4-Dateisystem verwendet werden.

sudo mkfs.vfat -F 32 /dev/sdc1

Nun wird auf dem USB-Stick vor der ersten Partition (also in den ersten 2048 Sektoren) eine zufällige Byte-Folge erzeugt, die nachher als Schlüssel für die verschlüsselte Festplatte dienen wird:

dd if=/dev/urandom of=/dev/sdc bs=512 seek=1 count=2046

Schlüssel zur verschlüsselten Festplatte hinzufügen

Als nächstes speichern wir den soeben erzeugten Schlüssel in einer Datei ab:

dd if=/dev/sdc bs=512 skip=1 count=16 > tempKeyFile.bin

Hier nehmen wir die ersten 16 Sektoren des USB-Sticks, somit haben wir hier eine Schlüssellänge 8192 Bytes.

Diese (temporär) erzeugte Datei wird nun über LUKS als neuer Key der Festplatte hinzugefügt:

cryptsetup luksAddKey /dev/sdb tempKeyFile.bin

Anschließend kann die Festplatte auf zwei verschiedene Weisen entschlüsselt werden:

  • Mit dem Passwort, welches bei der Verschlüsselung der Festplatte angegeben wurde.
  • Mit dem soeben erzeugten Key-File, welches auch auf dem Stick vor der ersten Partition gespeichert ist.

Das Key-File (tempKeyFile.bin) wird anschließend nicht mehr benötigt. Jedoch sollte man dies ebenfalls sicher verwahren, falls man z.B. zukünftig einen anderen USB-Stick zum entschlüsseln verwenden möchte. Das Key-File kann z.B. neben dem Passwort zum Entschlüsseln ebenfalls in einem Passwort-Manager (als Anhang) gespeichert werden.

Anschließend wird das Key-File vom System entfernt:

rm tempKeyFile.bin

Festplatte automatisch bei Systemstart entschlüsseln

Nun fehlt nur noch ein entscheidender Bestandteil der Lösung: Wir wollen die Festplatte nicht per Passwort oder Key-File, sondern mit dem Schlüssel entschlüsseln, der auf dem USB-Stick hinterlegt ist. Das ganze soll auch transparent bei Systemstart ohne weiteres Zutun den Users passieren.

UUIDs der Geräte ermitteln

Damit dies umgesetzt werden kann, müssen die UUIDs der entsprechenden Geräte ermittelt werden.
Für den USB-Stick kann dies durch folgenden Befehl geschehen:

ls /dev/disk/by-id/

Hier sollte der USB-Stick mit zwei Einträgen gelistet werden.

usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0
usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0-part1

Hier brauchen wir die UUID des Sticks selbst und nicht jene von der ersten Partition (zu erkennen an -part1 am Ende). Die gesuchte UUID ist in diesem Beispiel also 4C530000100xxxxxxxxx-0:0.

Nun brauchen wir nur noch die UUID der LUKS-verschlüsselten Festplatte. Hier hilft folgender Befehl:

blkid

Hier sollte man nun folgende Zeile finden (die verschlüsselte Festplatte ist ja unter /dev/sdb zu erreichen):

/dev/sdb: UUID=“10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx“ TYPE=“crypto_LUKS“

Die UUID ist hier dementsprechend 10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx.

crypttab/fstab editieren

Damit die Festplatte bei Systemstart entschlüsselt wird, wird nun die crypttab (Anweisungen zum Einhängen verschlüsselter Geräte) bearbeitet:

nano /etc/crypttab

Hier fügen wir am Ende folgende Zeile ein:

crypt_hdd1 UUID=10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx /dev/disk/by-id/usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0 luks,tries=3,keyfile-size=8192,keyfile-offset=512

Bei der UUID handelt es sich um jene der verschlüsselten Festplatte. Daraufhin folgen Angaben zum USB-Stick, der zum entschlüsseln verwendet werden soll. Am Schluss wird angegeben, wo der entsprechende Schlüssel zu finden ist.

Damit wird die Festplatte beim Systemstart entschlüsselt. Was nun noch fehlt ist das Einhängen der entschlüsselten Festplatte, so dass diese nach dem Systemstart sofort zur Verfügung steht. Dazu wird noch die fstab editiert:

nano /etc/fstab

Am Ende fügen wir folgende Zeile hinzu:

/dev/mapper/crypt_hdd1       /media/hdd1     ext4    defaults        0       2

Beim Systemstart werden nun erst einmal die Inhalte der crypttab abgearbeitet. Damit wird die Festplatte entschlüsselt und steht per Mapper (/dev/mapper/crypt_hdd1) zur Verfügung. Erst im Anschluss werden die Laufwerke per fstab gemountet. Hier wird der Mapper dann unter /media/hdd1 eingehängt.

Nach einem Neustart des Systems (mit angeschlossenem USB-Stick) sollte die Festplatte nun direkt unter /media/hdd1 zur Verfügung stehen. Es wird kein Passwort mehr benötigt und das Key-File ist auch nicht mehr manuell anzugeben.

Fazit

Die Einrichtung von verschlüsselten Festplatten, die beim Systemstart automatisch per USB-Stick entschlüsselt werden, ist mit einigem Aufwand verbunden. Jedoch muss man sich nach der Konfiguration nicht weiter um die Ver-/Entschlüsselung der Festplatte sorgen, da dies nun vollkommen transparent geschieht

Wichtig ist ab nun nur, dass man den USB-Stick einstecken muss, wenn die Maschine (neu) gestartet werden soll. Sollte man dies vergessen, bleibt das System schon beim Booten hängen, da die Anweisungen in der crypttab nicht abgearbeitet werden können und der Mount per fstab fehlschlägt.

Ebenso benötigt es etwas Disziplin: Wenn die Maschine erst einmal läuft, sollte der USB-Stick auf jeden Fall entfernt und sicher aufbewahrt werden (z.B. am Schlüsselbund). Im Falle eines Diebstahls der Hardware ist es nun praktisch gesehen unmöglich, auf die Daten des Systems zuzugreifen, wenn man nicht den passenden USB-Stick zur Hand hat.

Links

36 Kommentare zu „Verschlüsselte Festplatte (LUKS) mit USB-Stick bei Systemstart entschlüsseln“

  1. Interessanter Artikel, aber mich würde folgendes noch viel mehr Interessieren:
    Entschlüsseln der LUKS-Festplatte über den privaten GPG Schlüssel auf einer Smartcard des Nitrokey.

    1. Hallo Johnny,

      leider habe ich keinen Nitrokey zur Hand. Sollte sich dies mal ändern, würde ich sicher einen derartigen Artikel in Angriff nehmen.
      Das Reizvolle an dieser Lösung ist aber in meinen Augen auch gerade die Tatsache, dass man keine spezielle Hardware, sondern nur irgendeinen USB-Stick benötigt.

      Gruß,
      Jan

  2. Hallo, super Artikel, habe diese für mein Projekt LUKS öffnen beim anschließen eines bestimmten USB-Stickts. Leider gibt es einen Tippfehler in der Zeile „dd if=/dev/sdc bs=512 skip=1 count=8 > tempKeyFile.bin“ In der Beschreibung steht 16 Sectoren und beim Öffnen auch 8196. Leider sind beim export nur 8 Sectoren verwendet. Ansonsten sehr gut beschrieben.
    Gruß Lukas

  3. ok-erstmal vielen Dank für Deine Arbeit!
    Wie geht das mit mehreren (LUKS-)verschlüsselten Partitionen (/home;/temp;/var zum Bsp.)?

    1. Hi,

      mittels LUKS kannst du ja ganze Festplatten (also RAW-Device) verschlüsseln, das ist in diesem Artikel erläutert.
      LUKS kennt allerdings auch eine Verschlüsselung auf Partitions-Ebene. Hier sollte sich das Vorgehen nicht von dem gezeigten unterscheiden, nur dass mehrere Partitionen auf die gleiche Art und Weise behandelt werden müssen.

      Gruß,
      Jan

  4. Hallo,

    sehr interessanter Artikel. Ich habe bereits drei verschlüsselte Partitionen und für zwei auch bereits eine Entschlüsselungsdatei. Kann ich auch drei solcher Dateien auf den Stick packen? Wenn ja, wie beschreibe ich das in der crypttab?

    1. Hallo Peter,

      sollte kein Problem sein, da du ja 2048 Bytes „frei“ hast. Bei einer Sektor-Größe von 512 Bytes kannst du also 127 Keys speichern (eigentlich 128, aber hier besteht ja ein gewisser Overhead).
      In der crypttab musst du dann nur den richtigen Bereich durch folgende Anweisungen auswählen: keyfile-size=8192,keyfile-offset=512 (das wäre nun der erste Key, wie im Tutorial).
      Für den zweiten Key wäre das dann z.B. keyfile-size=8192,keyfile-offset=8704.
      Die „8704“ ist dann der „kombinierte“ Offset (512 + 8192).

      Das ist aber nur ein Beispiel: Du kannst die Keys in den den ersten 2048 Bytes auch beliebig „mischen“. Wichtig ist nur, dass die Byte-Folge korrekt über die crypttab adressiert wird.

      Gruß,
      Jan

  5. Hallo Jan,

    Danke für den sensationellen Artikel. Bei mir hat es aber (aus welchem Grund auch immer) erst funktioniert, nachdem ich – bei sonst identischer Vorgehensweise zu deinem Artikel – „update-initramfs -u -k all“ am Ende „hinterhergeschickt habe…!? Macht das irgendwie Sinn?? (Raspian Buster Lite) –
    Frage unabhängig von dem vorherig gesagten: wie kann ich eine exakte Kopie des vorhandenen USB-Sticks machen, sodass ich eine Ausfallreserve habe? Bzw. alternativ, wie kann ich aus der (verschlüsselt gesichtern) temp. Keyfile einen x-beliebigen USB-Sticke wiederherstellen, damit ich dann mit ihm das System booten kann? Falls mir der ursprüngliche USB-Stick mal abhanden kommt…

    Grüße,
    Thom

    1. Hi Thom,

      das „update-initramfs“ kann schon nötig sein, bei mir hat es bisher immer auch ohne funktioniert.

      Einen Stick kannst du vermutlich am einfachsten über dd clonen.
      Viel einfacher ist es jedoch, wenn du dir das Key-File (welches du auf den Stick schreibst) irgendwo sicherst (ich speichere das z.B. als Anhang in einem KeePass-Eintrag). Wenn du nun einen zweiten Stick präparieren möchtest, dann kannst du das Key-File einfach wie im Artikel beschrieben auf einen zweiten Stick aufspielen.
      Ganz wichtig dabei ist, dass du (wenn du einen anderen Stick verwendest) die UUID in der crypttab ebenfalls anpassen musst. Der Eintrag ist ja immer spezifisch auf einen Stick festgelegt.

      Gruß,
      Jan

  6. Hallo Jan,
    ich habe mein Debian 10 Buster mit cryptLVM verschlüsselt.
    Meine externe USB-Festplatte ist ebenfalls verschlüsselt.
    Da bin ich nach Deiner Anleitung mit der Entschlüsselung mit USB-Stick vorgegangen.
    Beim booten werde nach der Entschlüsselungs-Passphrase der LVM auch nach der Entschlüsselungspassphrase der verschlüsselten USB-Festplatte gefragt.
    Nachdem ich dann auf dem Desktop angelangt bin, kann ich ohne Passwort auf meine Festplatte zugreifen. Habe ich etwas übersehen? USB-Stick steckt übrigens.

    LG aus Wien
    Andreas

    1. Hi Andreas,

      wenn er trotz gestecktem USB-Stick nach der Passphrase verlangt, stimmt meistens etwas mit der Konfiguration nicht. Leider kann man hier nicht genau sagen, was da schief läuft. Deshalb geh das Tutorial einfach noch einmal Schritt für Schritt durch. Nimm für den Anfang auch erst die externe HDD und versuch es damit. Erst, wenn das klappt, dann kommt die nächste Platte dran.
      Für ein verschlüsseltes LVM sieht die Sache auch übrigens etwas anders aus. Hier ist ein wenig mehr notwendig, siehe hier.

      Gruß,
      Jan

  7. Hi, danke für die tolle Anleitung.
    Was ich bei mir abgeändert habe, ich nutze nicht „/dev/disk/by-id/..“ sondern „by-path“. Das macht’s meiner Ansicht nach noch ein bisschen sicherer da nun nicht mehr klar ist welcher USB Stick den schlüssel enthält sondern lediglich an welchen Port der Stick stecken muss.

    Eine nachfrage hätte ich aber noch, durch dein verfahren kann nun die Platte beim Boot entschlüsselt werden. Was mache ich nun aber wenn das System schon läuft, mir ist nicht ganz klar was ich wo ausführen / einstellen muss damit die platte auch zur Laufzeit mit dem Stick entschlüsselt werden kann? Bzw. wie der Befehl dazu lautet. Über die GUI klappts ja mit dem PW aber wie nutze ich dafür dann auch den stick?

    Danke und Gruß

    1. Hi Pascal,

      wenn du mit „by-path“ vorgehst, dann musst du den Stick aber immer in den gleichen Port stecken. Kann man natürlich auch machen – muss man aber nur dran denken.

      Manuelle habe ich das noch gar nicht gemountet. Das müsste dann aber über luksopen gehen. Hier kannst du ebenfalls ein Keyfile angeben (siehe hier). Allerdings bin ich mir nicht sicher, ob du hier ein Offset für das Keyfile angeben kannst.
      Andere Möglichkeit wäre, per Mount-Script die /etc/fstab zu modifizieren und dann ein „mount -a“ hinterher zu schieben. Ein Unmount-Skript löscht den Eintrag dann wieder aus der /etc/fstab. Ist vielleicht die einfachere Variante.

      Gruß,
      Jan

        1. Hi Dirk,

          bei mir brauche ich den Befehl nicht und habe das ganze schon mit mehreren Systemen umgesetzt.
          Auf welcher Distribution bist du unterwegs?

          Gruß,
          Jan

  8. Mit dem automatischen Start klappt es wunderbar, allerdings habe ich eine externe HD und somit kommt es zu unterschiedlichen Szenarien: USB Stick abgezogen, HD nicht angeschlossen oder beides unplugged/plugged.

    Wenn ich das per udev – Regel dynamisch lösen möchte

    ACTION==“add“, SUBSYSTEM==“usb“, ENV{ID_VENDOR_ID}==“0xyz“, ENV{ID_MODEL_ID}==“1xyz“, GROUP=“users“, MODE=“0660″,RUN+=“/usr/local/sbin/plug_external_hdd“

    script plug_external_hdd :

    #!/bin/bash
    dd if=/dev/disk/by-id/usb-0xyz_1xyz_T1408020000721-0:0 bs=512 skip=1 count=16 | cryptsetup luksOpen /dev/disk/by-id/ata-WD3000BQ002-2N2101_WSD14F2L crypt_device && systemd-mount /dev/mapper/crypt_device /mnt/3TB

    Das Lw wird allerdings nicht gemountet.

    Wie müsste ich das entschlüsselte Lw als standard-user dynamisch (also nicht bei systemstart) mounten ?

    1. Hi Ronald,

      das Skript sieht auf den ersten Blick gut aus. Warum hier der Mount nicht funktioniert, kann ich dir allerdings nicht sagen. Kommt hier eine Fehlermeldung o.ä.?
      Was passiert, wenn du nach dem Skript den Befehl mount /dev/mapper/crypt_device /mnt/3TB auf der Kommandozeile ausführst?

      Gruß,
      Jan

      1. Als regulärer user:
        /usr/local/sbin/plug_external_hdd

        dd: konnte ‚/dev/disk/by-id/usb-0xyz_1xyz_T1408020000721-0:0‘ nicht öffnen: Keine Berechtigung
        Gerät »/dev/disk/by-id/ata-ST8000VN004-2M2101_WKD15M4K« existiert nicht oder Zugriff verweigert.

        führe ich das script mit sudo aus erhalte ich:
        16+0 Datensätze ein
        16+0 Datensätze aus
        8192 Bytes (8,2 kB, 8,0 KiB) kopiert, 0,00203801 s, 4,0 MB/s
        Kein Schlüssel mit dieser Passphrase verfügbar.

        Somit wird auch kein cryptdevice angelegt unter /dev/mapper/..

        1. Hi,

          ich denke, dass hier die Passphrase (also der Key, den du aus dem ersten USB-Device ausließt) nicht korrekt ist. Funktioniert dies (mit sudo), wenn du den richtigen Key (also den original erzeugten, den du dann auf dem USB-Stick geschrieben hast) angibst?

          Gruß,
          Jan

          1. Hm, nachdem ich jetzt wieder auf die crypttab+fstab – Variante umgestiegen bin habe ich derzeit ein ganz anderes Problem:

            wenn man den Schlüssel(Stick) nach dem hochfahren abzieht und das System später (ohne cryptsetup close) herunterfährt, und dann wieder ohne Stick startet, dann ist das device (/dev/sdb) entschlüsselt vorhanden – es gibt allerdings kein device unter /dev/mapper und für gparted ist das /dev/sdb verschlüsselt und ich muss die Passphrase eingeben..

            Sehr merkwürdig und inkonsistent in meiner derzeitigen Konfiguration :-/

          2. Hi Ronald,

            OK, die Platte ist nach dem Reboot also wieder entschlüsselt vorhanden? Was passiert, wenn du nach dem Reboot ein „cryptsetup luksClose …“ absetzt?
            Ich denke, dass die Platte vor dem Reboot immer „ordentlich“ ungemountet werden muss. Das ist dann leider wie das „Hardware sicher entfernen“ unter Windows.

            Gruß,
            Jan

  9. hm.. das hatte ich natürlich auch probiert, aber dann erhalte ich die Meldung das keine cryptdevice vorhanden ist bzw beim umount bekomme ich die Nachricht, dass unter /mnt/[device-mntpoint] nichts eingehängt ist obwohl ich im thunar ganz normal darauf zugreifen kann.
    Heute habe ich die eingeschaltete Festplatte wieder mit dem Schlüssel am Stick hochgefahren und auf der Festplatte ist plötzlich wieder ein alter Datenstand vorhanden – die knapp 11 GB vom Borg-Backup gestern sind verschwunden. Als ob da 2 unterschiedliche OS die gleiche Festplatte handhaben wollten..

    Oje, oje.. mir war das bis dato nicht bewusst dass das luks-Verschlüsseln und Einbinden einer externen Festplatte unter Thunar bzw. Linux immer noch so eine unbrauchbare Baustelle bzw. Katastrophe ist..

  10. Nach Neustart „ohne Stick“ hab ich wieder den Zustand B, also eine andere Belegung und die 11GB backups ..
    Irgendwie konkurrieren da Thunar und das crypt-device-mgmnt ums gleiche device..

    1. Hi,

      ich kann leider nichts dazu sagen, wie sich das ganze in Verbindung mit einem File-Manager wie Thunar verhält. Mein einziger Usecase ist hier die Verschlüsselung ganze ohne Desktop – daher auch kein File-Manager.
      Kannst du vielleicht irgendwie den File-Manager hier ausschließen?

      Gruß,
      Jan

  11. Hallo und danke für den Artikel!
    Wäre toll wenn ich eine Anleitung für das Szenario „anderen Server (RasPi) im Heimnetz statt USB-Stick“ bekäme. Also der Verschlüsselte Rechner holt sich den Schlüssel dort ab … aber wie?
    Vorab schon mal vielen Dank!
    Gruß Markus

    1. Hi Markus,

      also spontan fällt mir hier leider keine Lösung ein. Müsste ja dann quasi eine Rest-API o.ö. auf dem Raspi sein, der den Schlüssel dann im Netz verteilen kann.

      Gruß,
      Jan

  12. Hat bei mir auf Anhieb funktioniert. Nur ein Problem stellt sich mir ohne USB Stick bootet der PI nicht. Ich nutze OpenMediaVault und falls der Stick mal nicht funktioniert oder verloren gegangen ist, kann ich den PI und OVM nicht mehr starten. Gibt es eine Moglichkeit wahlweise mit oder ohne ohne Stick zu booten? Ich dachte evtl. an ein Script welches feststellt dass der Stick nicht vorhanden ist und dann diesen Step uberspringt.

    1. Hi,

      normalerweise verlangt er hier nach dem vergebenen Passwort, wenn der Stick beim Booten mal nicht gesteckt sein sollte.
      Hast du die Systemplatte verschlüsselt, oder eine weitere (externe) Festplatte? Wenn es die Systemplatte war, dann kann dieser Artikel vielleicht hilfreich sein.

      Gruß,
      Jan

  13. Guten Tag,

    super Anleitung, hat bei mir sofort unter Ubuntu 20.04 funktioniert.
    Ich habe aber null Ahnung wie ich via DD das tempKeyFile.bin zurück an die richtige Stelle eines USB Sticks bringe. Könnte man das noch an den Artikel anhängen, habe nicht die Zeit mich in DD einzuarbeiten.
    Danke und viele Grüße
    Jörg

    1. Hi Jörg,

      das geht dann mit folgendem Befehl: dd if=tempKeyFile.bin of=/dev/sdb bs=512 seek=1 count=2046
      Also genau so wie beim Erzeugen des Keys, nur dass das tempKeyFile.bin hier die Quelle darstellt.

      Gruß,
      Jan

  14. Hallo Jan,

    vielen lieben Dank, das hat funktioniert. Habe damit das Thema Security-Key für die Verschlüsselung der LUKS hinten an gestellt – die Lösung mit den Sticks erscheint mir für meine Bedürfnisse deutlich praktikabler als irgendwelche GunPG Keys zu erstellen und bei Yubi irgendwelchen Anleitungen zu folgen die mir als nicht ausgegoren erscheinen.
    Viele Grüße
    Jörg

    PS: bin gerade dabei meine Nextcloud in eine Docker Installation zu überführen, weil mir die Kombi mit TRAEFIK die Arbeit vereinfachen soll. Für meine Bedürfnisse gibt es da aber noch einige Baustellen, insbesondere das Fail2Ban Thema gefällt mir noch gar nicht. Falls mal ein neues Thema benötigt wird.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert