debianforum.de

Hallo mal wieder!

Nachdem ich einerseits ein verschlüsseltes System will, andererseits aber auch eine faule Sau bin (hier nachzulesen), möchte ich die Festplatte mit einem USB-Stick, statt mit einem Passwort entschlüsseln.

Ich bin also zunächst dieser Anleitung gefolgt, um nach einigen Tagen und Fehlversuchen festzustellen, dass das seit systemd nicht mehr geht - das steht zumindest auf dieser vertrauenswürdigen Seite.

Also habe ich einen wilden Mix aus beiden Anleitungen probiert um schließlich diese /etc/crypttab zu erstellen: Zur Erklärung: der Key liegt auf dem USB-Stick in einem Bereich zwischen der Partitionstabelle und der ersten Partition, konkret in den Sektoren 51-54 (oder eben in den Bytes 50x512+1=25601 + 4x512=2048).

Danach habe ich mit die Initramfs neu erstellt. Das steht komischerweise gar nicht in der Anleitung, ist aber ziemlich sicher trotzdem notwendig.

Dabei kamen ein paar Warnungen: Die AMD-GPU-Warnungen sind wohl eher egal. Die anderen eher nicht, weil nach einem Reboot war ich froh, vorher von der initramfs ein Backup angelegt zu haben. Das System hat nicht mehr gebootet. Offenbar bin ich in dieses Problem gelaufen.

Aber wie mach ich es denn nun richtig, mit dem USB-Stick als "Schlüssel" für den PC? Bzw. was habe ich falsch gemacht?

Bonusfragen (derzeit keine wirklichen Probleme, nur andere Sachen, die mich verwundern):

• Die Warnung "/dev/disk/by-id/usb-Generic_Flash_Disk_23456bcde-0:0 has insecure ownership" kann ich ignorieren, oder? Weil Der Schlüssel liegt ja nicht in einem Dateisystem drinnen. Nichtmal in einer Datei eigentlich. Oder könnte ich da irgendwas besser machen?
• Wie könnte man - theoretisch - ein zweites Key-File in der /etc/crypttab für dieselbe verschlüsselte Partition angeben (etwa, wenn man einen zweiten USB-Stick als Schlüssel verwenden will)? Mit einer zweiten Zeile mit den gleichen Angaben für volume-name und encrypted-device?
• Was ist mir hier schiefgelaufen:

  Code: Alles auswählen

  $ lsblk --fs
  NAME                                FSTYPE      FSVER            LABEL                 UUID                                   FSAVAIL FSUSE% MOUNTPOINT
  sda                                                                                                                                          
  └─sda1                              crypto_LUKS 2                                      abcd1234                  
    └─sdb1_crypt                      LVM2_member LVM2 001                               defg2345                
      └─[...]
  [...]
  

  Also, wieso liegt auf sda1 sdb1_crypt? Irgendwie verwirrend. Kann man das ändern?

Vielen Dank schon jetzt für Eure Hilfe!

Wie ich sehe, haben auch schon andere Leute sich mit diesem Problem beschäftigt:
viewtopic.php?t=164245

Kenne mich nicht ganz aus, aber die debianforum-Wiki-Seite dürfte jedenfalls eher falsch sein... :/

Ich bekomme von dm-crypt langsam Albträume.

Meine Anforderungen habe ich inzwischen geändert - ich bin genügsam geworden.

Ich wäre schon glücklich, wenn beim Boot

1. zuerst nach einem Keyfile auf einer ext4-Partition auf meinem USB-Stick gesucht wird
2. wenn keine gefunden wird, soll die Passwortaufforderung kommen
3. weil 2020 ist, soll das ganze (auch mit) Plymouth funktionieren.

Leider will mir offenbar nichtmal der erste Punkt gelingen.

Der Reihe nach:

Mein System läuft mit Debian Bullseye mit systemd. Ich bin nach dieser Anleitung (https://www.arminpech.de/2018/11/18/unl ... n-usb-key/) vorgegangen, weil das die aktuellste war, die ich im Netz finden konnte.

Meine /etc/crypttab sieht nun so aus:
wenn ich damit eine initramfs erstelle, wird mein System unbootbar - passdev scheint immer und immer wieder nach dem File zu suchen, findet es aber nicht. Was der Timeout (:5) genau macht, verstehe ich noch nicht ganz. Eine Passwortaufforderung kommt nicht.

Als weiteren Schritt bin ich diese Liste hier durchgegangen: https://cryptsetup-team.pages.debian.ne ... scue-shell
Die Resultate hab ich leider nur als Foto vom Screen:


Sieht so aus, als hätte der Kernel im initramfs

• keinen Device-Mapper-Support
• kein dm-crypt Kernel-Modul
• /cryptoot/crypttab scheint da zu sein , das mit dem lsmod laut Anleitung funktioniert nicht (fehlt da eine Pipe?)
• der USB-Stick scheint konsequenter Weise unter /dev/disk/by-uuid/ auch nicht auf

Diesen Forenbeitrag (viewtopic.php?t=164245) kenne ich fast schon auswendig, aber auch der hat mir nicht weitergeholfen...

Jetzt weiß ich irgendwie nicht mehr, was ich probieren soll, um wenigstens das Problem zu verstehen. Habt ihr einen Tipp für mich?

Genau darum bin ich rüber zu Devuan. Da geht noch heute (Buster-like) genau das was ich damals unter Wheezy zur automatischen Entschlüsselung gemacht hab.

Rolf

Danke, Rolf!

Aber soweit ich das nachvollziehen kann (und das ist leider nicht sehr weit) scheitert es ja schon vor systemd, oder?

Für mich sieht es so aus, als würden initramfs die "Werkzeuge" (Treiber?) fehlen, um auf den USB-Stick zuzugreifen. Oder verstehe ich was falsch?

Falls meine Angaben noch zu unklar sind, lasst es mich wissen. Ich poste gerne weitere Infos.

Spindoctor hat geschrieben:

25.07.2020 09:52:56

Für mich sieht es so aus, als würden initramfs die "Werkzeuge" (Treiber?) fehlen, um auf den USB-Stick zuzugreifen.

Such mal als Einstiegshilfe nach "initramfs read usb-stick", da gibs mehrere Lösungsansätze für dieses Problem.

Spindoctor hat geschrieben:

23.07.2020 00:54:05

... Ich bin also zunächst dieser Anleitung gefolgt, um nach einigen Tagen und Fehlversuchen festzustellen, dass das seit systemd nicht mehr geht - ...

Ich habe schon vor systemd meine verschlüsselten Datenpartitionen mittels (verstecktem) Keyfile auf einem USB-Stick entschlüsselt. Das funktioniert bei mir nach wie vor - sogar mit bullseye und systemd. Allerdings habe ich nur die Datenpartitionen verschlüsselt, also nicht das System.

Mit der Einführung von systemd stellte ich unter stretch fest, daß zwar der cryptsetup-Befehl erfolgreich war, aber das anschließende Mounten nicht gelang. Ich mußte dieses Mounten über systemd-Dienste durchführen.

Ich habe eine Unit crypt-mounten.service folgenden Inhalts in /etc/systemd/system angelegt: Dann noch eine Timer-Datei crypt-mounten.timer angelegt: Damit der Dienst und der Timer starten können, müssen sie noch aktiviert werden: Das in der Service-Unit unter ExecStart eingetragene Skript prüft, ob der cryptsetup-Befehl
erfolgreich gelaufen ist und führt dann das nachträgliche Mounten durch.

Wie schon eingangs angemerkt funktioniert dies für meine reinen Datenpartitionen. Was ein verschlüsseltes System angeht, kann ich nichts beitragen. Aber vielleicht hilfts ja doch.

Gruss H.

Ich kann außer den in meinem alten Thread dokumentierten Dingen nichts weiter dazu beitragen. Nachdem ich zwar das Bootlaufwerk per versteckten Key in Stretch entschlüsselt gekriegt hab, aber ein weiteres unabhängiges zusätzliches Laufwerk nicht, hab ich es mit Debian und systemd aufgegeben und bin in dem Sommer zu Devuan gewechselt.

Heuer hab ich aber auf eine ganz aktuellen HW mal Arch Linux installiert. Auch in einem verschlüsselten LVM, und da hab ich auf Anhieb eine Entschlüsselung von einem versteckten Schlüssel auf einem USB-Stick hinbekommen.

Siehe dazu:
https://wiki.archlinux.de/title/Moderne ... %BCsselung
https://wiki.archlinux.de/title/Systemv ... t_dm-crypt

Schau Dir das mal an, vielleicht hilfts weiter.

Rolf

TomL hat geschrieben:

25.07.2020 10:20:43

Spindoctor hat geschrieben:

25.07.2020 09:52:56

Für mich sieht es so aus, als würden initramfs die "Werkzeuge" (Treiber?) fehlen, um auf den USB-Stick zuzugreifen.

Such mal als Einstiegshilfe nach "initramfs read usb-stick", da gibs mehrere Lösungsansätze für dieses Problem.

Danke für den Hinweis. Habe jetzt schon auf mehreren Rechnern genau diesen Suchstring in Google verwendet aber finde nur Lösungen für Probleme von einem bootbaren USB-Stick ins Initramfs zu kommen. Bei mir läuft das initramfs ja aber regulär auf der Platte, trotzdem geht es nicht :/

Vielleicht bist du ja in Google anders "gebubbelt". Könntest Du mir eine konkrete Seite nennen, wo Lösungsansätze diskutiert werden?

Überhaupt nochmals danke an alle, für Eure Antworten. Irgendwie komm ich trotzdem nicht viel weiter, was mich etwas verwirrt. Ich hätte nicht gedacht, dass meine Anforderung so ein "Nischenprogramm" ist - insbesondere nachdem der Debian-Installer die UserInnen ja regelrecht auffordert, das System zu verschlüsseln. Dafür ist die standardmäßig implementierte Lösung relativ unausgegoren, finde ich...

Hab seit gestern eine neue Idee, die unabhängig vom init-System funktionieren sollte. Mal sehen, ob das klappt...

Ich habe hier ein Debian 10, eine verschlüsselte Home-Partition und einen Key, der auf einem USB-Stick zwischen zwei Partitionen liegt.
Mit den Parametern keyfile-offset und keyfile-size funktioniert bei mir das automatische Entschlüsseln.

Danke @Tintom!

Ich hab mich vom Installer und vom Forum hier überzeugen lassen, dass eine verschlüsselte Home-Partition nicht reicht. Daher ist bei mir alles außer /boot verschlüsselt. Und initramfs scheint mit USB-Speichermedien (oder mit meinen USB-3.0/3.1-Anschlüssen) Probleme zu haben...

Nein, ich glaube nicht, dass Debian damit ein wirkliches Problem hat. Soweit ich das verstanden habe, wird zu dem Zeitpunkt ein Mini-Debian geladen.... zwar Mini, aber eben doch ein Debian. Das heißt, man kann viel von dem tun, was später auch mit Debian möglich ist. Für USB müssen also die gleichen "Treiber" geladen werden, die später auch in der realen Installation werkeln. Bei mir sind das scheinbar diese: Diese Treiber werden dann in /etc/initramfs-tools/modules eingetragen. Zusätzlich kann man "hooks" einbinden, also eingehängte Funktionen... eben dafür, den Stick zu mounten. Abschließend wird die initramfs neu erzeugt. Ich denke, dass man dafür unter den von mir genannten Stichworten Anhaltspunkte findet, wie man das umsetzen kann. Ich kann Dir aber sagen, was ich im Moment als größeres Problem sehe... und zwar die Fehlerbehandlung, wenn kein Stick enthalten ist ... also die vorherige Prüfung "stick drin? ja oder nein". Soweit ich weiß, gibts an der Stelle nämlich noch kein UDEV.

Aber ich muss zugeben.... ich habe nur mal aus Neugier im Web recheriert und kam dann auf diesen Lösungsansatz... damit würde ich einsteigen... ob das allerdings wirklich funktioniert...?... keine Ahnung. Fakt ist, man kann spezielle Treiber in der initramfs laden und eigene Funktionen einbinden... das geht. Wenn Du die Lösung hast, bitte hier nachvollziehbar posten.

Du kannst dem Befehl update-initramfs noch den Schalter -v mitgeben, dann siehst du, was alles in die Datei gepackt wird.

Hi,

hast du es denn nun hinbekommen?
Ich habe mich auch fast verrückt gesucht - am Ende gabs dann keine Fehler mehr - aber auch keine Entschlüsselung.
Ich nutze allerdings auch OMV - das hat dann mit der FS Tab noch ein paar Abhängigkeiten, damit die Laufwerke in OMV weiterhin zu verwalten sind.

Ich habe es jetzt wie halo44 vorher geschrieben hat auch über systemd dienst umgesetzt und das funktioniert ganz passabel und für meinen privaten Einsatz ausreichend.
Was ich noch gefunden hatte, war eine Lösung das KeyFile über MS Azure Blob zu ziehen - aber mangels Zeit nicht umgesetzt:

Falls es Wayne interessiert:
https://withblue.ink/2020/01/19/auto-mo ... linux.html#

Gruß

Also, ich drehe mich hier auch seit einiger Zeit im Kreis, rund um das Bullseye. Das zusätzliche, nicht verschlüsselte ext2-Device wird nicht gemountet:
-----------------------------------------------
Failed to mount /dev/disk/by-label/GuidedGrub
Nothing to read on input.
cryptsetup: ERROR: vda5_crypt: cryptsetup failed, bad password or options?
cryptsetup: ERROR: vda5_crypt: maximum number of tries exceeded
Volume group "vm01-vg" not found
Cannot process volume group vm01-vg
[...]
BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) mount /dev/disk/by-label/ExtDev /tmp
(initramfs) cryptsetup luksOpen -d /tmp/luks.key.file /dev/vda5 vda5_crypt
(initramfs) vgchange -ay
2 logical volume(s) in volume group "vm01-vg" now active
(initramfs) exit ==> boot ins System...

The same with disk/by-uuid:

Failed to mount /dev/disk/by-uuid/777F-F1D9
Nothing to read on input.
cryptsetup: ERROR: vda5_crypt: cryptsetup failed, bad password or options?
Volume group "vm01-vg" not found
Cannot process volume group vm01-vg
Gave up waiting for root file system device. [...]

BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) ls /dev/mapper/
control
(initramfs) mount /dev/disk/by-uuid/777F-F1D9 /tmp
(initramfs) cryptsetup luksOpen -d /tmp/luks.key.file /dev/vda5 vda5_crypt
(initramfs) vgchange -ay
2 logical volume(s) in volume group "vm01-vg" now active
(initramfs) ls /dev/mapper/
control vda5_crypt vm01--vg-root vm01--vg-swap_1
(initramfs) exit ==> boot ins System möglich...

Vielleicht hilft das ja: das initramfs schafft das Mounten (wohin auch immer) nicht, manuell geht es.

Die /etc/crypttab, hier mit disk/by-uuid:
vda5_crypt UUID=4ad51b9a-b500-47e1-8c55-04a10c850ba2 /dev/disk/by-uuid/777F-F1D9:/luks.key.file luks,keyscript=/lib/cryptsetup/scripts/passdev

Es kommen noch folgende Meldungen beim boot via "exit" aus der initramfs-Shell ("Mini-Debian"):

[ 170.711425] systemd[1]: Failed to mount /run/systemd/cryptsetup/keydev-vda5_crypt.
[...]
[ 170.737135] systemd[1]: Dependency failed for Cryptography Setup for vda5_crypt.
[ 170.738624] systemd[1]: Dependency failed for Local Encrypted Volumes.
[ 170.745008] systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
[ 170.745016] systemd[1]: systemd-cryptsetup@vda5_crypt.service: Job systemd-cryptsetup@vda5_crypt.service/start failed with result 'dependency'.
[ 170.745061] systemd[1]: Unnecessary job for /dev/disk/by-uuid/4ad51b9a-b500-47e1-8c55-04a10c850ba2 was removed.
[...]
[ 170.979321] /luks.key.file: Can't open blockdev
[...]

Also, irgendwas ist da faul...