[gelöst] Probleme mit cryptsetup / luks

[true]

Hallo,


mein Name ist Alex und ich bin neu in diesem Forum. Zunächst möchte ich mich für die zahlreichen Beträge bedanken, die mir in der Vergangenheit das ein oder andere Problem lösen halfen.

Ich nutze Debian in Verbindung mit cryptsetup/luks auf Laptop und Backup-Server seit vielen Jahren und hab bis jetzt keine Probleme damit gehabt. Auf allen Geräten sind die Dateisysteme voll verschlüsselt und als LV aufgeteilt. Zusätzlich hängt am Backup-Server ein verschlüsselter USB-Festplatten-Verbund.

Vor einigen Tagen hab ich ein upgrade von testing auf unstable auf Server und Laptop gemacht. Welche Pakete im einzelnen aktuallisiert wurden weiß ich nicht mehr, weil es im laufenden Betrieb zu keinerlei Schwierigkeiten kam. Die Geräte liefen einige Tage im 24-Stunden-Betrieb. Wärend dieser Zeit hab ich die USB-Festplatten am Server neu eingerichtet ( pv's -> cryptsetup/luks -> lv's ). Die Dateisysteme von Server und Laptop wurden nicht angefasst und blieben im ursprünglichen verschlüsselten Zustand.

Vor 2 Tagen wollte ich den Server neu starten und ich wunderte mich, dass mein Passwort nicht mehr akzeptiert wurde. Ich hab auf einen-Tastatur-Belegungs-Fehler innerhalb der initramfs getippt und das Passwort auch als us-Variante eingegeben. Leider erfolglos. Ich vermutete nun, dass der luks-header beschädigt sein könnte. Oder ein anderer Fehler verhindert den Zugang, den ich möglicher Weise einige Tage später per grml-live-cd beheben könnte. Zwischenzeitlich mußte ich auch den Laptop neu starten und sah zu meinem Entsetzen das gleiche Problem. Ich komme nun nicht mehr an die Daten von beiden Geräten heran. Lediglich die vor kurzem neu eingerichteten USB-Festplatten erlaubten einen Zugriff.

Wo liegt das Problem? Ich hab keinen Debian-bug gefunden, der dieses Phänomen beschreibt. und hab ich natürlich bemüht und hab mittlerweile Quadrat-Augen. Achja... Das Passwort ist auf allen Geräten gleich. Die log-files innerhalb der luks-Geräte sind natürlich nicht erreichbar.

Für Hilfe bin ich Dankbar...
VG Alex...


Mein aktuelles Rettungssystem:

Code: Alles auswählen

root@grml:~/# uname -a
Linux grml 3.16.0-1-grml-amd64 #1 SMP Debian 3.16.7-1+grml.1 (2014-11-05) x86_64 GNU/Linux

nicht entschlüsselbare Laptop-Partition:

Code: Alles auswählen

root@grml:~/# cryptsetup luksDump /dev/sdb1

LUKS header information for /dev/sdb1

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha1
Payload offset:	4096
MK bits:       	512
MK digest:     	1b 6d 20 0c c3 46 06 4a 9f 50 e7 21 97 87 fd 08 c8 8b e8 29 
MK salt:       	a9 e3 63 68 1b 77 20 d2 51 dd 77 29 c4 b1 69 10 
               	9f 75 54 a7 fc 4a 24 25 54 93 08 78 44 d2 44 75 
MK iterations: 	121125
UUID:          	f58d4f0f-513c-4ebe-8250-2bddcba6afae

Key Slot 0: ENABLED
	Iterations:         	492307
	Salt:               	88 f6 7b 9a 5e eb 23 32 04 b3 ac f3 b9 b8 b2 36 
	                      	91 db f3 5f d2 e1 21 36 fd 7d 1e bb 1e 92 b1 da 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: ENABLED
	Iterations:         	477611
	Salt:               	c3 af 9d e9 91 40 1a 5e 42 6a 10 c7 e0 75 56 c6 
	                      	cb 20 93 94 1a 26 da c9 d0 5e 23 a7 d8 57 c2 3f 
	Key material offset:	512
	AF stripes:            	4000
...

die entschlüsselbaren USB-Festplatten:

Code: Alles auswählen

root@grml:~/# cryptsetup luksDump /dev/mapper/Backup--Verbund-lvol0

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha1
Payload offset:	4096
MK bits:       	256
MK digest:     	ae ff 25 c3 cf c4 14 82 2c f0 b7 18 5c 83 f7 cd 84 22 31 5d 
MK salt:       	e5 3b 28 aa c7 48 ed 51 ad c8 1e 3c 53 29 f1 36 
               	9b 55 5c 94 9d ca 99 2a 9d 57 76 b0 09 4f fe 22 
MK iterations: 	101250
UUID:          	fd45200d-5611-4063-854c-ab47670fdba4

Key Slot 0: ENABLED
	Iterations:         	407642
	Salt:               	9d 13 48 70 2a 33 24 3d 18 ba 1a 53 0d 30 02 41 
	                      	da 69 a2 02 37 83 f6 a9 f2 7a 45 76 1a b0 23 2c 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: ENABLED
	Iterations:         	378697
	Salt:               	cf f0 80 7e dc 8a ac 06 45 2c e7 d9 ab da 0a 75 
	                      	a8 ac 5f 4e cc 5d 71 49 02 67 e4 77 81 22 5c e7 
	Key material offset:	264
	AF stripes:            	4000
Key Slot 2: ENABLED
	Iterations:         	178770
	Salt:               	e6 2d 1f bb 3e 64 f2 30 35 86 10 31 14 fb 2f 07 
	                      	a6 84 db 83 6b 10 7e c2 43 1f 5a 45 8e 81 4d 2e 
	Key material offset:	520
	AF stripes:            	4000
Key Slot 3: ENABLED
	Iterations:         	544680
	Salt:               	85 31 54 81 db 2d 2d 21 28 d5 13 c4 ba 39 86 b3 
	                      	86 f7 f3 12 18 05 72 84 ce cc 1d 66 c2 25 9a d0 
	Key material offset:	776
	AF stripes:            	4000
...

[DeletedUserReAsG]

Welche Fehlermeldung genau kommt denn, wenn du den Container aus grml heraus zu öffnen versuchst?

[wanne]

Für mich sieht das ganz und gar nicht kaputt aus. Würde immer noch auf capslock/falsches Tastaturlayout/falsches ecncoding.. tippen.
Auffällig ist vor allem Dass es da zu allen devices mehrere Passwörter gibt.

[true]

Welche Fehlermeldung genau kommt denn, wenn du den Container aus grml heraus zu öffnen versuchst?

Danke für die Antwort...

Code: Alles auswählen

root@grml:~# cryptsetup luksOpen /dev/sdb1 SDB1
Enter passphrase for /dev/sdb1:
No key available with this passphrase.

[true]

Für mich sieht das ganz und gar nicht kaputt aus

Für mich auch nicht.

Würde immer noch auf capslock/falsches Tastaturlayout/falsches ecncoding.. tippen.

Ich auch.

Auffällig ist vor allem Dass es da zu allen devices mehrere Passwörter gibt.

Das soll nicht weiter stören. Die funktionierende USB-Platte ist auch per keyfile entschlüsselbar.
Die nicht funktionierende Partition sdb1 hat zusätzlich auf sda5 (verschlüsseltes root-Dateisystem) ein keyfile. Ich komme halt nicht ran.

Das Problem dürfte das gleiche sein:

root@grml:~# cryptsetup luksOpen /dev/sda5 SDA5
Enter passphrase for /dev/sda5:
No key available with this passphrase.

[DeletedUserReAsG]

Wenn du weißt, wie die Passphrase aussehen muss, könntest du sie auch in eine Shell tippen und via Copy&Paste einfügen, oder direkt in eine Datei schreiben und die als Keyfile angeben. Damit würdest du Tastaturprobleme ausschließen.

Ansonsten könntest du mal die LUKS-Header mit den Backups davon vergleichen, die du hoffentlich, wie in der Doku dringend empfohlen wird, angelegt hast.

[true]

Wenn du weißt, wie die Passphrase aussehen muss, könntest du sie auch in eine Shell tippen und via Copy&Paste einfügen, oder direkt in eine Datei schreiben und die als Keyfile angeben. Damit würdest du Tastaturprobleme ausschließen.

Ich hab ein WB angelegt mit allen möglichen Varianten. Danach abarbeiten lassen:

Code: Alles auswählen

root@grml:~# while read LINE ; do echo "$LINE" ; echo "$LINE" | cryptsetup luksOpen /dev/sdb1 SDB1 2>/dev/null && break ;  done</tmp/wb.txt
...

...ohne Erfolg.

Ansonsten könntest du mal die LUKS-Header mit den Backups davon vergleichen, die du hoffentlich, wie in der Doku dringend empfohlen wird, angelegt hast.

Ich dachte, diese Frage können wir auslassen .

Ich glaube nicht, dass es am Paßwort oder dessen Eingabe liegt. Ich glaube auch nicht, dass die Header beschädigt sind - was ich leider nicht nachprüfen kann (immerhin hatte ich zumindest vom Inhalt ein Backup - wenn auch verschlüsselt).
Fakt ist. Alle verschlüsselten Geräte, die vor den Upgrades schon existierten, sind nicht mehr zugänglich. Nur die Geräte, die nach dem Upgrade erzeugt wurden, gewähren mir Zugang. Und das ganze reproduzierbar auf einem Laptop und einem Server. Da muss doch irgendwas passiert sein?! Vielleicht doch die Header verändert? Aber weshalb? Am Gerät wird ja nichts verändert - auch nicht wenn das initramfs neu geschrieben wird...

[true]

Mir ist etwas aufgefallen. Bei einem Vergleich zwischen den Ausgaben von "cryptsetup luksDump" zwischen funktionierenden und nicht funktionierenden Geräten,
ist der Eintrag folgendermaßen:

MK bits: 512 <-funktioniert nicht
MK bits: 256 <- funktioniert

Laut http://www.finnie.org/2009/07/26/keyfil ... in-debian/ ist diese Angabe notwendig um die Größe eines Keyfiles festlegen zu können. Das ist mir komplett neu. Es haben bisher ausnahmslos alle keyfiles funktioniert.

[DeletedUserReAsG]

Ohne dir zu nahe treten zu wollen: der Einzeiler sieht fehleranfällig aus, du solltest den vorgesehenen Weg über › -d datei_mit_passphrase ‹ wählen.

Nur zur Sicherheit: die Passphrase enthält nur Zeichen aus ASCII? Wenn nein, mag folgender Ausschnitt aus den FAQ für dich interessant sein:

PASSPHRASE CHARACTER SET: Some people have had difficulties with this when upgrading distributions. It is highly advisable to only use the 95 printable characters from the first 128 characters of the ASCII table, as they will always have the same binary representation. Other characters may have different encoding depending on system configuration and your passphrase will not work with a different encoding. A table of the standardized first 128 ASCII characters can, e.g. be found on http://en.wikipedia.org/wiki/ASCII

Die »MK bits« beziehen sich auf den eigentlichen Schlüssel (Masterkey) und haben mit deiner Passphrase/deinem Schlüssel wenig zu tun.

[NAB]

Laut http://www.finnie.org/2009/07/26/keyfil ... in-debian/ ist diese Angabe notwendig um die Größe eines Keyfiles festlegen zu können. Das ist mir komplett neu. Es haben bisher ausnahmslos alle keyfiles funktioniert.

Nein, das ist die Länge des "Master Keys" und meines Wissens identisch zu dem Wert, den du mit --key-size angibst. Nun ist es sinnvoll, bei einem 32Byte-Master-Key auch mindestens ein 32Byte-Keyfile aus Zufallszahlen als Schutz zu benutzen, aber es funktioniert natürlich auch ein größeres oder ein kleineres Keyfile.

[true]

Ohne dir zu nahe treten zu wollen:

Keine Sorge...

der Einzeiler sieht fehleranfällig aus,...

Den Einzeiler hab ich an einer "funktionierenden" - verschlüsselten Festplatte ausprobiert. Er hat funktioniert. Wenn auch die Ausgabe nicht sehr komfortabel war.
An welcher Stelle siehst Du ein Problem? (Ich muss dazu sagen, dass ich kein Experte für Programmierung oder Scripte-Schreiben bin...)

... du solltest den vorgesehenen Weg über › -d datei_mit_passphrase ‹ wählen.

Diesen Tip und den Tip die Paßwörter per copy&paste zu übertragen hab ich auch ausprobiert. Zumal die Anzahl der Möglichen Passworte sehr übersichtlich ist.

Nur zur Sicherheit: die Passphrase enthält nur Zeichen aus ASCII?

So ist es.

Wenn nein, mag folgender Ausschnitt aus den FAQ für dich interessant sein:

PASSPHRASE CHARACTER SET: Some people have had difficulties with this when upgrading distributions. It is highly advisable to only use the 95 printable characters from the first 128 characters of the ASCII table, as they will always have the same binary representation. Other characters may have different encoding depending on system configuration and your passphrase will not work with a different encoding. A table of the standardized first 128 ASCII characters can, e.g. be found on http://en.wikipedia.org/wiki/ASCII

Alle Zeichen kommen innerhalb der 128 druckbaren ASCII-Zeichen vor. Es sind nur die zwei Zeichen
"-",
"_",
Zahlen und Buchstaben (ohne ß und Umlaute) im Passwort enthalten.

Das heißt, ich muss mich nur auf "-" und "_" konzentrieren. Auf der us-Belegung (auch uk) wären das "/" und "?". Bei feststehnder "Caps-Lock"-Taste würden die beiden Zeichen "-" und "-" nur gegeneinander ausgetauscht werden. Analog dazu "/" und "?". [edit] "Caps-Lock" hat keinen Einfluss auf die Zeichen, sondern nur auf die Groß.- und Kleinschreibung der Buchstaben. Für die anderen Zeichen wäre die Shift-Taste relevant. Diese kann man auf die anderen Zeichen bezogen nicht feststellen. Das war mir nie wirklich bewußt...[/edit]

Oder hab ich da etwas falsch verstanden?

Die »MK bits« beziehen sich auf den eigentlichen Schlüssel (Masterkey) und haben mit deiner Passphrase/deinem Schlüssel wenig zu tun.

Ok, alles gut...

[true]

Laut http://www.finnie.org/2009/07/26/keyfil ... in-debian/ ist diese Angabe notwendig um die Größe eines Keyfiles festlegen zu können. Das ist mir komplett neu. Es haben bisher ausnahmslos alle keyfiles funktioniert.

Nein, das ist die Länge des "Master Keys" und meines Wissens identisch zu dem Wert, den du mit --key-size angibst. Nun ist es sinnvoll, bei einem 32Byte-Master-Key auch mindestens ein 32Byte-Keyfile aus Zufallszahlen als Schutz zu benutzen, aber es funktioniert natürlich auch ein größeres oder ein kleineres Keyfile.

Achso. Ok. Dann hab ich den englischen Beitrag falsch interpretiert. "--key-size" hab ich nie gebraucht, sondern meist den Standard von 256Byte genutzt.

[true]

Ich werde zunächst Sicherungen von den Partitionen anfertigen. Ich hab noch einen Server, dem kein upgrade wiederfahren ist. Ich weiss nicht warum, aber vielleicht kann ich die Sicherungen auf ihm öffnen. Das dauert jetzt eine Weile...

[true]

aktueller Stand

Was das Passwort angeht; Ich bin mir zu 100% sicher.
Der Header scheint iO. zu sein.

das Kennwort:

Folgende Zeichen sind vorhanden:

• 1-_aAginpu

us-Belegung:

• 1ß?aAginpu

Variante mit Caps-Lock:

• 1ß?aAGINPU

• 1-_aAGINPU

Scripte:

• Passwortübergabe per stin

• Passwortübergabe per --key-file="$FILE"

Umgebung:

• aktuelle Installation (unstable)

• aktuelle Installation (stable)

• veraltete Installation (unstable)

Eingabe:

• de_DE.UTF-8

• en_GB

• en_US

Alle Varianten hab ich erfolglos kombiniert.

und nun?

• Ich hab Zeichen im Passwort verwendet, die man nicht verwenden sollte.

• Ich hab kein Backup der Header angelegt.

• Ich hab zwei Geräte auf unstable aktuallisiert ohne zu kontrollieren ob alles funktioniert.

Ich erstelle gerade ein Wörterbuch für einen brute-force-Angriff.
Die Partitionen wurden mit dd in Dateien geschrieben. Anschließend hab ich versucht Zugriff zu erlangen:

Code: Alles auswählen

root@server2:/home/X/DATENRETTUNG/IMAGES# uname -a
        Linux server2 4.2.0-1-amd64 #1 SMP Debian 4.2.5-1 (2015-10-27) x86_64 GNU/Linux

Code: Alles auswählen

        root@server2:/home/X/DATENRETTUNG/IMAGES# losetup -v /dev/loop0 ./asus-laptop-sda5.img
        root@server2:/home/X/DATENRETTUNG/IMAGES# losetup -l
        NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
        /dev/loop0         0      0         0  0 /home/X/DATENRETTUNG/IMAGES/asus-laptop-sda5.img
        root@server2:/home/X/DATENRETTUNG/IMAGES# cryptsetup luksDump /dev/loop0
        LUKS header information for /dev/loop0
         
        Version:        1
        Cipher name:    aes
        Cipher mode:    xts-plain64
        Hash spec:      sha1
        Payload offset: 4096
        MK bits:        512
        MK digest:      f9 71 f8 e7 00 cf c2 04 ed ab 22 1d dc e5 78 05 66 47 46 0a
        MK salt:        eb 85 7f 77 31 7b e3 ce a1 a2 87 d9 d4 8e 75 37
                        31 85 c7 ff 77 2c 6a f1 a8 cb 49 56 4a b5 6b 0c
        MK iterations:  45875
        UUID:           de0d1cc7-bd4c-4320-b706-7f0ccf72d4dc
         
        Key Slot 0: ENABLED
                Iterations:             197530
                Salt:                   5b 9f 10 a0 50 a2 1d e7 3f bd 6e 2d dd 03 13 cb
                                        d2 8c 85 bd 65 3c 9a f3 f0 da 49 ae e3 ca 2f d2
                Key material offset:    8
                AF stripes:             4000
        Key Slot 1: DISABLED
        Key Slot 2: DISABLED
        Key Slot 3: DISABLED
        Key Slot 4: DISABLED
        Key Slot 5: DISABLED
        Key Slot 6: DISABLED
        Key Slot 7: DISABLED

Code: Alles auswählen

        root@server2:/home/X/DATENRETTUNG/IMAGES# cryptsetup luksOpen /dev/loop0 IMG
        Geben Sie die Passphrase für »/home/X/DATENRETTUNG/IMAGES/asus-laptop-sda5.img« ein:
        Kein Schlüssel mit dieser Passphrase verfügbar.
        Geben Sie die Passphrase für »/home/X/DATENRETTUNG/IMAGES/asus-laptop-sda5.img« ein:
        Kein Schlüssel mit dieser Passphrase verfügbar.
        Geben Sie die Passphrase für »/home/X/DATENRETTUNG/IMAGES/asus-laptop-sda5.img« ein:
        Kein Schlüssel mit dieser Passphrase verfügbar.

Hab ich irgendwas übersehen?

[NAB]

Erst dachte ich, dass "Unstable" irgendwie deine vorhandenen Container kaputt gemacht hat, während die neu-angelegten funktionieren.

Ich finde aber immer noch keinen dazu passenden Bug-Report.

Hast du mal in die andere Richtung überlegt ... dass eventuell in Testing eine fehlerhafte Version von cryptsetup ausgeliefert wurde, mit der du die alten Container angelegt hast ... und du sie nur mit dieser Version wieder öffnen könntest?

Ob das möglich wäre, kannst nur du wissen. Einen passenden Bug-Report finde ich auch nicht. Eventuell bestand der Fehler nur sehr kurz in Testing, bei dir aber länger, weil du lange keine Updates eingespielt hast?

[true]

Erst dachte ich, dass "Unstable" irgendwie deine vorhandenen Container kaputt gemacht hat,

Eine Möglichkeit...

...dass eventuell in Testing eine fehlerhafte Version von cryptsetup ausgeliefert wurde, mit der du die alten Container angelegt hast ... und du sie nur mit dieser Version wieder öffnen könntest?

Zweite Möglichkeit. Es ist schwierig das Erstellungsdatum herauszufinden. Die testing-Installation erfolgte per lokaler pxe-Installation und einem network-boot-image, welches den Rest nachläd.
Bei einem Stick.- o. DVD-Installationsmedium hätte ich direkt auf das Erstellungsdatum schauen können. Aber es existieren keine.

Eventuell bestand der Fehler nur sehr kurz in Testing, bei dir aber länger, weil du lange keine Updates eingespielt hast?

Also Updates rufe ich relativ zeitnah ab. Und ohne Bug-Report fehlt eine Dokumentation dazu.

Vielleicht war ja auch der Kernel oder eine Kombination mit ihm dafür verantwortlich?! Puh..

Code: Alles auswählen

root@grml:~# ls -1 /mnt/vmlinuz-*
/mnt/vmlinuz-3.16.0-4-amd64
/mnt/vmlinuz-4.2.0-0.bpo.1-amd64
/mnt/vmlinuz-4.3.0-0.bpo.1-amd64

Ich schau mal, ob ich das alte System nachbauen kann...

[NAB]

Vielleicht war ja auch der Kernel oder eine Kombination mit ihm dafür verantwortlich?! Puh..

Stimmt überhaupt ... cryptsetup wird ja z.B. für den Password-Hash kerneleigene Funktionen verwendet haben. In der Richtung hab ich noch gar nicht nach Bugs gesucht.

Debian Snapshots kennst du?
http://snapshot.debian.org/

[true]

Debian Snapshots kennst du?
http://snapshot.debian.org/

Jep...

Ich hab das Problem ein paar Tage liegen lassen und bin eben auf die mögliche Ursache in einer Test-VM gestoßen.

Ich denke dass es sich hier um den sogenannten "break Whirlpool" in den 1.5er Versionen von gcrypt handelt.

In der FAQ des cryptsetup-Wikis wird mittlerweile, unter Punkt "8.3 Gcrypt 1.6.x and later break Whirlpool" (https://gitlab.com/cryptsetup/cryptsetu ... cryptsetup), von einer Lösung gesprochen.

In den nächsten Tagen werde ich das Problem angehen und hier berichten.

VG Alex...

[NAB]

Öhm ... müsste dann bei deinem luksDump nicht "Hash spec: whirlpool" auftauchen? Bei dir steht sha1.

[true]

Öhm ... müsste dann bei deinem luksDump nicht "Hash spec: whirlpool" auftauchen? Bei dir steht sha1.

Öhm, das war dann wohl ein Eigentor. Du hast Recht. Der bug hat mich so sehr erfreut, dass ich nicht über den Algorythmus nachgedacht hab .

Zwischenzeitlich war mein Brute-Force-Angriff auf eine der Sicherungen erfolgreich. Es stellte sich heraus, dass der ganze Aufwand hier für die Katz war. Der Fehler lag dann doch im Passwort. Eine externe Tastatur, die ich damals beim Erstellen der verschlüsselten Partitionen verwendet hab, prellte hin und wieder an einem bestimmten Zeichen. Da die Passwörter während der Eingabe nicht angezeigt wurden und die Rechner relativ selten neu gestartet wurden, bemerkte ich den Fehler nicht. Mit crunch hab ich mir verschiedene Teile des in Frage kommenden Passwortes in zwei Textdateien geschrieben und mit unterschiedlichen Zeichenketten kombiniert. Ein kleines Script (hier leicht verändert und natürlich auf mein wirkliches Passwort zugeschnitten) hat mir dann ein Wörterbuch erstellt:

Code: Alles auswählen

#!/bin/bash
ZIEL=./wb.txt
rm $ZIEL

while read L1 ; do while read L2 ; do echo $L2$L1 ; echo $L2$L1>>3.txt ; done<crunch_1.txt ; done<crunch_2.txt
while read L3 ; do echo "$L3""ZEICHENKETTE" ; echo "$L3""ZEICHENKETTE">>4.txt ; done<3.txt
while read L3 ; do echo "$L3""ZEICHENKETTE" ; echo "$L3""ZEICHENKETTE">>5.txt ; done<3.txt
cat 4.txt 5.txt >>$ZIEL
rm 3.txt
rm 4.txt
rm 5.txt
exit

Für den Brute-Force hab ich meinen Eingangs erwähnten Einzeiler in eine Datei geschrieben und durchlaufen lassen:

Code: Alles auswählen

#!/bin/bash

LODEV="/dev/loop0"
WBFI="/home/true/Daten/WB/wb.txt"

clear
while read PWD ; do echo $PWD ; echo $PWD | cryptsetup luksOpen $LODEV IMG && break; done<$WBFI
exit

Beim ersten korrekten Passwort beendete sich die While-Schleife und das Passwort wurde angezeigt.

Für Eure Hilfe möchte ich mich bedanken, hab ich doch noch einiges dazu lernen dürfen.