Mein Computer fror lange ein und ich drückte die Reset-Taste. Nach dem Neustart lassen sich alle FÜNF luks-verschlüsselten (LUKS 1) Dateisysteme nicht mehr öffnen. Die Meldung, die ich erhalte, lautet „Kein Schlüssel mit dieser Passphrase verfügbar.“ Ich bin sicher, dass ich das richtige Passwort verwende. Ich verwende seit Jahren dasselbe Passwort für alle Dateisysteme. Ich habe Backups für alle diese Volumes außer einem, daher möchte ich meine Optionen dafür analysieren. Ich habe „cryptsetup isLuks“ und „cryptsetup luksDump“ auf allen Dateisystemen ausprobiert und alle waren erfolgreich, ich meine, es sind Luks-Partitionen und ich kann ihre Header sichern und ihre Slots sehen. Bei der Recherche fand ich jedoch ähnliche Fälle, in denen Leute sagen, ihre Header seien irreparabel beschädigt worden. Ich weiß nicht, wie ich das feststellen soll. Wie mache ich das? Vielen Dank für alle Informationen.
Antwort1
Ich habe diese Seite gefunden:
https://bbs.archlinux.org/viewtopic.php?pid=1846810#p1846810
Auch diese Seite:
Genauer,
"Sie können ziemlich schnell feststellen, ob eine Chance auf Wiederherstellung besteht. Führen Sie "hexedit -s /dev/sdx" aus und suchen Sie am Anfang eines Sektors nach der Hex-Zeichenfolge "4C 55 4B 53 BA BE". (Das ist die ASCII-Zeichenfolge "LUKS", gefolgt von den Hex-Bytes 0xBA und 0xBE.) Wenn Sie diese nicht innerhalb der ersten paar Megabyte der Festplatte finden, ist der LUKS-Header weg."
Bei allen fünf Dateisystemen, die sich nicht öffnen lassen, ist dieser String intakt in ihren Headern, sie scheinen also alle nicht beschädigt zu sein. Warum sie sich alle nicht öffnen lassen, ist ein anderes Problem, und ich vermute, ich werde nie herausfinden, was passiert ist.
Antwort2
Die Antwort wurde für die Nachwelt bereitgestellt.
Wie erkennen Sie, ob Ihr LUKS-Header beschädigt ist?
Die kurze Antwort auf Ihre Frage lautet, dass Sie beim Versuch, es zu entsperren, eine Meldung erhalten, dass es beschädigt ist, oder dass das System beim Versuch, die Passphrase einzugeben, einfriert, wenn es sich um die Startpartition handelt. In Ihrem Fall erhalten Sie jedoch nur eine Fehlermeldung, dass der Schlüssel „mit dieser Passphrase nicht verfügbar“ ist, was etwas seltsam ist.
Da Sie das bereits entdeckt haben, hexedit -s <device>möchten Sie vielleicht auch versuchen, es auszuführen, dmsetup info <device_name>]nachdem Sie versucht haben, das Passwort einzugeben, und sehen, welche Art von Status gemeldet wird, ob Tabellen als vorhanden gemeldet werden usw. Weitere Informationen finden Sie unterManpage für DMsetupFür mehr Information.
Oder versuchen Sie dmsetup table --showkeys <device or header file>herauszufinden, ob der Schlüsselschlitz erkannt wird.
Zusätzliche Methoden zur Überprüfung des LUKS-Headers
Abgesehen davon, dass Sie cryptsetup luksHeaderBackup <device> --header-backup-file <file>zum Erstellen einer Header-Sicherungskopie dies verwenden (auch wenn es sich nicht öffnen lässt, da luksDumpkeine Beschädigungen gemeldet werden), können Sie auch versuchen, eine Sicherungskopie davon zu erstellen und sie dann aus diesen Sicherungen wiederherzustellen, um zu sehen, ob Sie den Header auf diese Weise wiederherstellen können. Abgesehen von der oben genannten Methode können Sie auch Folgendes als Alternative zum Erstellen einer „Sicherungskopie“ des Headers cryptsetupverwenden :dd
root@system:# dd if=<device> of=<Luksheader_filename> bs=512 count=4097
Zusätzlich zur Verwendung hexeditzum Überprüfen des Headers können Sie auch den fileoder den stringsBefehl auf die Datei anwenden, die Sie oben gerade erstellt haben, oder sogar luksDumpden Befehl auf der Datei selbst ausführen, indem Sie den Gerätenamen durch den Pfad und Dateinamen ersetzen.
root@system:# file <Luksheader_filename>
root@system:# strings <Luksheader_filename> | grep -i luks LUKS
root@system:# cryptsetup luksDump <Luksheader_filename>
Ähnliche Fälle können ähnlich sein oder auch nicht
Was die anderen und Ihre Recherchen betrifft, die Sie oben verlinkt haben, wurde nicht klargestellt, was Sie taten, als Ihr Computer einfror und Sie somit zum letzten Mal auf die Laufwerke zugreifen konnten. Im Gegensatz dazu beziehen sich zwei Links auf zwei verschiedene Gründe dafür, dass ihre einzelnen LUKS-verschlüsselten Laufwerke nicht mehr zugänglich sind, einer davon bezieht sich auf eineHPAFehlkonfiguration und die andere war nach einem Kernel-Upgrade, das nur das /homeVolume und nicht das /rootVolume betraf und tatsächlich auf eineProblem beim Trimmen/Verwerfen.
Vielleicht kann ein ähnlicheres Problem basierend auf der allgemeinen Erklärung gefunden werdenHier, wo sie sogar begannen, die Möglichkeit in Betracht zu ziehen, dass eine kosmische Strahlung irgendwo einen Bit-Schalter erzwingt, und es könnte eine interessante Lektüre für jemanden sein, der noch einmal überprüfen möchte, ob er alle anderen Optionen geprüft hat.
Da es aufgrund der bereitgestellten Informationen unklar ist, ob diese „Dateisysteme“*, wie Sie sie nennen, Ihr Betriebssystem oder nur „Inhalte“ enthalten, wie wir es allgemein ausdrücken, wäre es hilfreich zu wissen, ob Ihr System beim Versuch zu booten einfriert, wenn eines der mit LUKS verschlüsselten Volumes/Partitionen Ihr Boot-Laufwerk ist und das Passwort nicht funktioniert, oder ob Sie nur versuchen, über das Terminal und/oder eine GUI (und auf welcher Linux-Variante) auf diese 5 Geräte zuzugreifen, und dass Ihnen dieser wiederholte Fehler angezeigt wird? In diesem Fall besteht bei Letzterem möglicherweise ein wenig Hoffnung.
*Zur Klarstellung: „Dateisystem“ bezieht sich darauf, wie und wo Daten gespeichert werden. Dateisystem bezieht sich also normalerweise auf Formate wie ext3, ext4, NTFS usw., während LUKS eine Festplattenverschlüsselungsspezifikation ist. Daher gibt es uns keinen Einblick in die Rolle dieser 5 LUKS-Dateisysteme (vermutlich Volumes, wie Sie erwähnt haben) als Teil Ihres Systems.
Mögliches Problem aufgrund von Nicht-Headern
Die Frage war, wie man einen beschädigten LUKS-Header identifiziert und/oder bestimmt. Ohne eine Sicherungskopie eines der Header gäbe es jedoch keine unbeschädigte Version des Headers, die der OP vergleichen könnte. Da jetzt klarer sein könnte, dass die vorliegende Situation unsicher und wahrscheinlich anders ist als die verlinkten Beispiele, könnte es sich lohnen, Folgendes zu versuchen:
Überprüfen, ob es sich um ein LVM-Problem handelt, mithilfe von
root@system:# lvscan
# or
root@system:# lvdisplay
# To check if you can still identify the LUKS filesystems as volume groups or
# supported LVM block devices.
root@system:# vgdisplay --short
# To find the Volume Group (usually fails if password won't work)
root@system:# lvs -o lv_name,lv_size -S vg_name=[name_of_volumegroup]
# To list the logical volumes identified in the volume group (if it works)
Weitere Informationen finden Sie in der Manpage fürAbonnierenUndvgdisplayum mehr zu lernen.
Und andere Möglichkeiten erkunden
Leider wurden bei der LUKS1-Verschlüsselung aus einer Reihe von Gründen keine Prüfsummen implementiert.diese Präsentationfalls gewünscht. Ansonsten bedeutet das nur, dass die einzige „Prüfsumme“ in LUKS diejenige ist, die Ihnen sagt, dass kein passender Schlüsselsteckplatz vorhanden ist und impliziert, dass er beschädigt ist.
Es wurde jedoch angemerkt, dass Sie gesagt hatten, dass sich alle 5 Dateisysteme nicht öffnen ließen und dass Sie sie alle als Volumes bezeichneten. Es ist also unklar, ob sich alles auf einer Festplatte befindet und ob es sich um ein SSD-Laufwerk handelt oder nicht. In diesem Fall ist einSpeicher- und Datenspeicherscandes Laufwerks wäre der nächste Vorschlag.
Und um sicherzugehen, haben Sie sich abschließend cryptsetupfür sudo„Ja“ entschieden?
Vielleicht möchten Sie auch versuchen
- Verwenden der Wiederherstellungsfunktion in der GUI von gparted bezüglich der Partitionstabellen und so weiter
- Scannen Sie es mit
ddrescue - Stellen Sie sicher, dass die Feststelltaste oder die Nummernsperre nicht aktiviert ist (ich weiß, das ist albern, aber nur eine kleine Erinnerung)
- Probieren Sie einige der vorgeschlagenen Antworten ausHier
- Wenn vor dem Absturz des Computers ein Update vorhanden war, versuchen Sie, zu einer früheren Version zurückzukehren
- Versuchen Sie, ein Passwort in einem anderen Schlüsselslot hinzuzufügen
Randnotiz
Es wurde angenommen, dass Sie versucht haben, die mit LUKS verschlüsselten Volumes in einem Terminal und mit „sudo“ zu öffnen, da weder ein bestimmtes System oder eine bestimmte GUI noch ein Startvorgang erwähnt wurde.