Bash: cryptsetup, kein Laufwerkszugriff

[mrserious]

Hallo,

habe mir vor Jahren mal ein ganz plumpes Skript geschrieben, das mir einen verschlüsselten USB-Stick einbindet.
Seit Debian 11 habe ich Probleme damit, bekomme den unten stehenden Fehler.
Was mache ich falsch?

Code: Alles auswählen

cryptsetup luksOpen /dev/disk/by-id/usb-.... stick

Code: Alles auswählen

Gerät »/dev/disk/by-id/usb-...« existiert nicht oder Zugriff verweigert.

[DeletedUserReAsG]

Was mache ich falsch?

Vermutlich benutzt du eine ID, die nicht (mehr) existiert. Die Meldung ist eigentlich recht eindeutig, und viele Leute schauen dann zunächst mit einem ls -l /dev/disk/by-id/, ob der Link zum Device tatsächlich nicht (mehr) vorhanden ist. Dann schreiben sie ihr Script auf einen Bezeichner um, der sich nicht von sich aus (bzw. von udev aus) ändert; üblich wäre da beispielsweise die UUID.

[mrserious]

Das habe ich auch zuerst gedacht.
Jedoch: Copy-Paste ich den Befehl händisch auf die Shell... funktioniert er einwandfrei.

[DeletedUserReAsG]

Ich warte dann mal, bis alle Salamischeiben auf dem Tisch liegen …

[chrbr]

Gerät »/dev/disk/by-id/usb-...« existiert nicht oder Zugriff verweigert.

Lass mich raten - Der Aufruf funktioniert in einer root shell, das Script läuft aber unter einem user account? Fehlt vielleicht eine früher existierende Berechtigung über sudo für das Kommando?

[mrserious]

Welche Infos fehlen euch denn?
Das Skript besteht tatsächlich nur aus 3 Zeilen:

Code: Alles auswählen

#!/bin/bash
cryptsetup luksOpen /dev/disk/by-id/usb-.... stick
mount /dev/mapper/stick /mnt/temp

Und nein, das Skript wird auf "der selben" (im Hintergrund wird bei einem Skript ja eine weitere Shell geöffnet) root-Shell ausgeführt wie auch der händische Befehl.
Mit anderen Worten: Tippe ich die beiden Zeilen nacheinander - inkl. des Passwortes für das Volume - ein, funktioniert alles.

[chrbr]

Wie sitzen halt nicht vor deinem Rechner und die Meinung von Selbstverständlichkeiten können dann sehr schnell zu Missverständnissen führen. Deshalb sollte man bei der ersten Frage eher zu viel angeben.

Lesen solltest Du man 5 crypttab und man 8 cryptsetup. Im letzteren bin ich auf eine mögliche Ursache gestoßen.

Code: Alles auswählen

NOTES ON PASSPHRASE PROCESSING FOR LUKS

LUKS uses PBKDF2 to protect against dictionary attacks and
 to give some protection to low-entropy passphrases 
 (see RFC 2898 and the cryptsetup FAQ).

From a terminal: The passphrase is read until the first 
newline and then processed by PBKDF2 without the newline character.

From stdin: LUKS will read passphrases from stdin up to the 
first newline character or the compiled-in maximum key file length. 
If --keyfile-size is given, it is ignored.

Da gibt es also einen Unterschied zwischen stdin und terminal. Probier man eine falsche Eingabe aus, und zwar am besten in beiden Versionen. Es kann gut sein, dass das doch nicht die Ursache ist. Einen Versuch ist es wert.

In der ersten man-page ist einiges zur Konfiguration und möglichen Änderungen. Vielleicht liegt der Schlüssel auch dort begraben.

[mrserious]

Guter Hinweis, danke!
Bringt leider keinen Unterschied.
Habe den Stick auch mal mit Key statt Passphrase verschlüsselt (denn das Keyfile kann ich ja im Skript explizit angeben), funktioniert ebenfalls nicht.

Es scheint ja am Zugriff auf das Device zu hapern?
Der Pfad ist aber definitiv korrekt und das Skript läuft mit root-Rechten.
Bin mir auch recht sicher, das Problem erst seit Debian 11 zu haben.

[chrbr]

Guter Hinweis, danke!
Bringt leider keinen Unterschied.

Ist die Fehlermeldung wie weit oben? Das hätte ich nie erwartet.

Habe den Stick auch mal mit Key statt Passphrase verschlüsselt (denn das Keyfile kann ich ja im Skript explizit angeben), funktioniert ebenfalls nicht.

Das war eine sehr gute Idee.

Es scheint ja am Zugriff auf das Device zu hapern?
Der Pfad ist aber definitiv korrekt und das Skript läuft mit root-Rechten.
Bin mir auch recht sicher, das Problem erst seit Debian 11 zu haben.

Es scheint definitiv am Zugriff zu liegen. Ich habe auch nicht gelesen, dass man mit cryptsetup den user ändern könnte. Aber vielleicht kann so etwas auch in den Konfigurationsdateien versteckt sein.

Eine sehr unwahrscheinliche Möglichkeit fällt mir noch ein. In den Dateiattributen gibt es ein SETUID Flag. Damit würde das Skript nicht mit den Rechten des Aufrufers, sondern mit den Rechten des Skript Owners laufen. Siehe https://linuxconfig.org/how-to-use-spec ... ticky-bits.

Ansonsten bin ich allmählich mit meinem Latein am Ende.

[chrbr]

Eiiinen hab'n wir noch . In einem der oben gelisteten man-pages habe ich gelesen, dass sich möglicherweise systemd auch berufen fühlt, bei crypto mit zu mischen. Das wäre zur Kontrolle ein systemctl mit grep -i auf crypt, luks und ähnliches interessant. So etwas kann einem auf jedem Fall bei einem Versionssprung vom OS passieren.

[mrserious]

Viele gute Ansätze, danke!

Ich habe erst morgen Zeit, das alles durchzugehen.
Was ich aber spontan sagen kann: Mit /dev/disk/by-uuid funktioniert das Skript einwandfrei!

Ich konnte das Verhalten übrigens auf verschiedenen Debian 11 Installationen replizieren.

[chrbr]

Ich konnte das Verhalten übrigens auf verschiedenen Debian 11 Installationen replizieren.

Na, das ist schon mal prima und sollte Fehler von Dir praktisch ausschließen. Dann ein gutes Nächle .

[chrbr]

Moin,
nun habe ich noch neue Ideen. Die erste wäre, zur Sicherheit env in der Shell, in einer neuen Zeile vor cryptsetup, in einer neuen Zeile zwischen cryptsetup und mount und noch als letzte neue Zeile. Damit wäre durch Vergleich feststellbar, ob der Aufruf in der Shell und keines der Programme das environment wie auch immer manipuliert.

Alias als Workaround. Wenn in der shell die Befehlskette

Code: Alles auswählen

cryptsetup .... && mount ....

funktioniert könntest Du für jeden einzelnen Satz an Parametern wie USB-Stick-Id usw einen Alias wie crypdiska. Mit dem Aufruf vom Alias sollte cryptsetup ... gestartet werden. Wenn davon kein Fehler signalisiert wird sollte danach mount laufen.

Als Alternative käme vielleicht cryptmount in Betracht.

Hier ist noch etwas zum Konflikt mit Systemd. https://bugs.debian.org/cgi-bin/bugrepo ... bug=981405 Mit crypttab kennst Du dich sicher aus.