Luks "Kein Schlüssel mit dieser Passphrase verfügbar", aber scheinbar zufällig

Luks "Kein Schlüssel mit dieser Passphrase verfügbar", aber scheinbar zufällig

Ich habe die seltsamsten Erfahrungen mit meinem verschlüsselten Luks-Volume gemacht und hoffe, dass mir vielleicht jemand helfen kann, Licht ins Dunkel zu bringen. Ich werde es Ihnen erklären.

Bei der Installation meines Betriebssystems (übrigens Vanilla Arch) habe ich mit cryptestup und luks v2 eine verschlüsselte Root-Partition eingerichtet (die /bootunverschlüsselt bleibt). In den ersten Tagen funktionierte alles problemlos. Dann, einen Tag nach einem Neustart, akzeptierte es plötzlich meine Passphrase nicht mehr.

No key available with this passphraseist alles, was ich bekomme. Also habe ich als Erstes natürlich überprüft, ob mit meinem Tastaturlayout irgendetwas nicht stimmt. Ich habe eine Live-ISO von Manjaro gestartet, um das Volume dort mit dem folgenden Befehl zu mounten, damit ich mein Passwort sehen konnte (so kann ich es nicht falsch eingeben):

echo [mypassword] | cryptsetup open --test-passphrase /dev/nvme0n1p2

und habe auch Folgendes versucht, falls es einen Unterschied gemacht hat

echo [mypassword] | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2

aber ohne Erfolg. Ich habe beim Hochfahren versucht, break=premountmein Tastaturlayout zu überprüfen, und es gibt auch kein Problem damit. An diesem Punkt dachte ich, ich hätte Glück, da ich kein Header-Backup hatte (ich dachte, die aktuellen seien beschädigt), aber in einem letzten verzweifelten Versuch habe ich versucht, erneut zu booten, und dieses Mal hat es einwandfrei funktioniert?

Ich habe sofort eine Header-Backup-Datei erstellt. Ich habe überprüft, ob sie intakt ist, indem ich

echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader

und den Header außerhalb des verschlüsselten Datenträgers gespeichert.

Ich bin bis heute nicht wieder auf das Problem gestoßen, als ich beim Booten wieder die No key available with this passphraseMeldung bekam. Also gut, boote zu meinem Live-ISO und versuche, das Volume dort zu mounten, funktioniert nicht. Dann kopiere ich die Header von dem Ort, an dem ich sie gespeichert habe, und versuche, sie zu öffnen, aber dasFunktioniert AUCH nicht. Habe sogar den Befehl ausgeführt, der es unmöglich macht, mein Passwort durcheinander zu bringen:

echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader

Um eine akute selektive Amnesie in Bezug auf mein Passwort auszuschließen, habe ich versucht, die Header-Datei auf einem anderen Computer zu öffnen, und das funktioniert problemlos. Auf meinem Hauptcomputer tritt der Fehler jedoch immer noch auf.

Also habe ich beschlossen, den Befehl im Wesentlichen zu spammen, indem ich

echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader

sobald das Vorherige abgeschlossen ist. Seltsamerweise beobachte ich jetzt eine Erfolgschance von etwa 1/5 beim Öffnen der Header-Datei. Meistens hatte ich mehrere Fehlschläge hintereinander, manchmal aber auch zwei oder drei Erfolge hintereinander.

Das kam mir sehr merkwürdig vor, da der obige Befehl es unmöglich macht, das Passwort falsch einzugeben/sich falsch zu merken. Es war immer dieselbe Zeichenfolge, die an die Header-Datei übergeben wurde. Außerdem ist dies kein ständiges Problem, wie ich bereits erwähnte, da es zwischen dem ersten Mal, als ich dies beobachten konnte, und heute mehrere Wochen gab, in denen ich neu starten und meine Passphrase ohne Probleme eingeben konnte.

Ich habe dann dasselbe mit der verschlüsselten Partition versucht und konnte auch eine Erfolgsquote von etwa 1/5 beobachten. Ich habe mich dann für einen Neustart entschieden, bekam die No key available ...Meldung zweimal beim Eingeben meines Passworts und konnte beim 3. Versuch erfolgreich booten.


Wenn Sie es bis hierher geschafft haben, herzlichen Glückwunsch. Ich hoffe, Sie sind beim Lesen nicht so verrückt geworden wie ich beim Erleben.

Derzeit mache ich mir keine Sorgen über den Verlust meiner Daten, da a) ich von allem Wichtigen Backups habe und b) ich mein Laufwerk immer auf einem anderen Gerät entschlüsseln kann (glaube ich, lol). Trotzdem hätte ich gerne eine Erklärung für das seltsame Verhalten, das ich beobachte, und möglicherweise eine Lösung dafür, da es für mich zumindest potenziell ärgerlich ist, da ich nicht jederzeit booten kann, wenn ich möchte.

Ich habe sogar einige abwegige Dinge in Betracht gezogen, wie etwa kosmische Hintergrundstrahlung oder andere Quellen elektromagnetischer Felder, und wenn keiner von Ihnen eine bessere Theorie vorlegen kann, dann werde ich sie wohl testen müssen, indem ich meinen Turm in denselben Raum stelle wie die Maschine, die den Header fehlerfrei entschlüsseln kann.

Das große Problem ist, dass dieses Problem scheinbar zufällig auftritt, da ich noch keine Möglichkeit gefunden habe, es zuverlässig zu reproduzieren. Wenn Sie mir dabei helfen könnten, wäre ich Ihnen sehr dankbar!

Abschließend: Dieses Problem scheint durch zusätzliche Neustarts/Ausschalten nicht beeinflusst zu werden, da ich keine Verbesserung der Zuverlässigkeit beim Öffnen der Header-Datei/des Volumes feststellen konnte. Das einzige, was sich darauf auszuwirken scheint, ist die Zeit (morgen wird es wahrscheinlich wieder in Ordnung sein). Ich habe jedoch nicht geprüft, ob ich das CMOS lösche, da ich meine BIOS-Konfiguration nicht verlieren möchte, wenn es sich vermeiden lässt.

verwandte Informationen