mount: Keine solche Datei oder kein solches Verzeichnis mit verschlüsselter Wiederherstellung

Ich habe meine Mint Linux-Installation zerstört. Ich wollte nur Zugriff auf meine Remote-Storefront. Was also geschah, war, dass ich Probleme mit der ICEauthority-Datei in meinem Home-Verzeichnis hatte. Nachdem ich im Internet verschiedenen Anweisungen gefolgt war, kam ich zu dem Schluss, dass ich das Home-Verzeichnis rekursiv auf chmod 755 setzen konnte, damit diese Datei funktioniert. Schließlich stieß ich auf Probleme beim Laden des Systems. Durch das Setzen des Ausgangsverzeichnisses auf die ausführbare Berechtigung für root konnte ich schließlich Lese- / Schreibzugriff erhalten ... aber dann habe ich meinen Computer zurückgesetzt. Oh, warum, warum habe ich meinen Computer zurückgesetzt? - Jetzt gibt mir das System den gleichen Fehler mit ICEauthority, aber es bringt mich nie in das Betriebssystem, weil die Festplatte verschlüsselt ist. Nichts, was ich versucht habe, scheint zu funktionieren und ich habe nicht den ursprünglichen Montagesamen.

frankenmint@honeybadger /home $ sudo ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
INFO: Found [/home/.ecryptfs/frankenmint/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] y
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [979c6cdf80d2e44d] into the user session keyring
mount: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.Hy3BV96c].

Ich mache mir wirklich Sorgen, weil ich dort wichtige Dateien hatte, die auf einer virtuellen Maschine gespeichert waren. Wenn ich nur zu diesen Dateien gelangen könnte, hätte ich keine Bedenken, das Setup zu zerstören und von vorne zu beginnen

Ich fand, dass das Laufen sudo bashund dann das Laufen ecryptfs-recover-privateals root (und nicht über sudo) funktionierte. Ich bin mir nicht sicher, warum es anders sein sollte.

Bearbeiten:

TL; DR:

# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase - | ecryptfs-add-passphrase --fnek -
    < Type your login password here >
Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring

Sie sehen keine Eingabeaufforderung und müssen Ihr Anmeldekennwort blind in den obigen Befehl eingeben.

Ersetzen Sie die aaaaaaaaaaaaaaaaund bbbbbbbbbbbbbbbbunten durch die hexadezimalen Signaturen zwischen den Klammern der obigen Ausgabe in der folgenden Reihenfolge:

# mount -i -t ecryptfs -o ecryptfs_sig=aaaaaaaaaaaaaaaa,ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

Vorbereitungen

Es stellt sich heraus, dass nur das Ausführen von root für mich nicht zuverlässig funktioniert hat. manchmal schon, manchmal nicht. Grundsätzlich scheint ecryptfs fehlerhaft und ziemlich benutzerunfreundlich zu sein, was Anmeldekennwörter und Mount-Passphrasen oft verwirrt. Nachdem ich ein tiefes, dunkles Kaninchenloch hinuntergegangen bin, habe ich einige Tipps, die helfen sollten. Diese Hinweise gelten für Ubuntu 17.10, ecryptfs-utils 111-0, und Sie sollten vor dem Start root werden. Ich gehe davon aus, dass Sie Ihr Home-Verzeichnis von /mnt/crypt(das bereits gemountet sein sollte) nach mounten möchten /mnt/plain, und Sie sollten es durch userden Benutzernamen ersetzen .

Einfach starten

Das erste, was Sie versuchen sollten, ist:

# ecryptfs-recover-private /mnt/crypt/.ecryptfs/user/.Private

Wenn das funktioniert, haben Sie Glück. Wenn nicht, wird möglicherweise eine Fehlermeldung von mountungefähr ausgegeben no such file or directory. Dies ist äußerst irreführend: Was es wirklich bedeutet, ist, dass Ihre Mount-Passphrase falsch ist oder fehlt.

Holen Sie sich die Unterschriften

Hier ist der wichtige Teil: Wir müssen überprüfen, ob ecryptfs wirklich die richtigen Mount-Passphrasen versucht. Die Passphrasen müssen in den Linux-Kernel geladen werden, bevor ecryptfs Ihr Dateisystem bereitstellen kann. ecryptfs fragt den Kernel anhand ihrer Signatur nach ihnen. Die Signatur ist ein 16-Byte-Hex-Wert (und nicht kryptografisch sensibel). Sie finden die Passphrase-Signaturen, die ecryptfs erwartet:

# cat /mnt/crypt/.ecryptfs/user/.ecryptfs/Private.sig
aaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbb

Erinnere dich an diese. Das Ziel ist es, Passphrasen mit diesen Signaturen in den Kernel zu laden und ecryptfs anzuweisen, sie zu verwenden. Die erste Signatur ( aaaaaaaaaaaaaaaa) ist für die Daten und die zweite ( bbbbbbbbbbbbbbbb) ist der FileName Encryption Key (FNEK).

Holen Sie sich die Mount-Passphrase

Dieser Befehl wird Sie bitten , für Sie anmelden Passwort (mit irreführende Aufforderung) und geben Sie Ihre Halterung Passwort:

# ecryptfs-unwrap-passphrase /mnt/crypt/.ecryptfs/user/.ecryptfs/wrapped-passphrase

Kopieren Sie dies, aber seien Sie vorsichtig! , da dies äußerst kryptografisch sensibel ist, sind die Schlüssel zum Königreich.

Versuchen Sie es mit einer interaktiven Halterung

Das nächste, was Sie versuchen sollten, ist:

# mount -t ecryptfs /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

Entscheidend dabei ist, dass Sie mountIhre (überempfindliche) Mount-Passphrase benötigen , die wir gerade kopiert haben (nicht Ihr Login-Passwort).

Dadurch werden Ihnen einige Fragen gestellt, und Sie können die Standardeinstellungen akzeptieren, außer Ja zu sagen Enable filename encryption. Möglicherweise erhalten Sie eine Warnung und werden aufgefordert, die Signaturen zwischenzuspeichern. Sie können zu beiden Ja sagen, aber überprüfen Sie noch einmal, ob Sie die richtige Mount-Passphrase haben.

Sie sehen die Optionen, mountdie sich für Sie entschieden haben:

Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=aaaaaaaaaaaaaaaa
Mounted eCryptfs

Wenn die Signaturen falsch sind (nicht mit dem übereinstimmen, was Sie erhalten haben Private.sig), funktioniert der Mount nicht.

... aber es wird sehr wenig hilfreich berichten, dass es getan hat. Sie müssen ls /mnt/plaineine Datei erstellen, um sicherzugehen. An dieser Stelle können Sie auch /var/log/syslogüberprüfen, ob ecryptfs nach denselben Signaturen sucht wie wir.

Es gibt hier eindeutig zwei schwerwiegende Probleme mit ecryptfs, und wir müssen sie umgehen.

Laden Sie die Schlüssel in den Kernel

Wenn der interaktive Mount nicht geholfen hat, müssen wir die Schlüssel selbst in den Kernel laden und sie manuell in den Mount-Optionen angeben.

# ecryptfs-add-passphrase --fnek

Und fügen Sie Ihre (super-senstive) Mount-Passphrase ein, die von oben kopiert wurde. Dies sollte Folgendes ausgeben:

Inserted auth tok with sig [aaaaaaaaaaaaaaaa] into the user session keyring
Inserted auth tok with sig [bbbbbbbbbbbbbbbb] into the user session keyring

Manuell montieren

Jetzt werden die Passphrasen in den Kernel geladen, und wir müssen mount nur anweisen, sie zu verwenden:

# umount /mnt/plain
# mount -i -t ecryptfs -o ecryptfs_sig=aaaaaaaaaaaaaaaa,ecryptfs_fnek_sig=bbbbbbbbbbbbbbbb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 /mnt/crypt/.ecryptfs/user/.Private /mnt/plain

Sie werden feststellen, dass die Optionen denen des interaktiven Mount ähneln, außer dass wir ecryptfs manuell mitteilen, was los ist.

Hoffentlich funktioniert das. Wenn nicht, können Sie überprüfen, ob die Schlüssel mit den richtigen Signaturen in den Kernel geladen wurden. Dabei keyctl list @usollten mindestens die beiden erwarteten Signaturen ausgedruckt werden.