montage: aucun fichier ou répertoire de ce type avec récupération chiffrée


12

J'ai détruit mon installation Mint Linux. Je voulais juste avoir accès à ma vitrine à distance. Donc, ce qui s'est passé, c'est que j'avais des problèmes avec le fichier ICEauthority dans mon répertoire personnel. Donc, en suivant différentes directions sur Internet, je suis arrivé à la conclusion que je pouvais définir le répertoire personnel de manière récursive sur chmod 755 pour permettre à ce fichier de fonctionner… j'ai finalement rencontré des problèmes avec le chargement du système. Finalement, en définissant le répertoire personnel sur une autorisation exécutable pour root, j'ai pu obtenir un accès en lecture / écriture… mais ensuite j'ai réinitialisé ma machine oh pourquoi oh pourquoi ai-je réinitialisé ma machine !!! - maintenant le système me renvoie la même erreur avec ICEauthority mais il ne me fait jamais entrer dans le système d'exploitation car le disque est crypté. Rien de ce que j'ai essayé ne semble fonctionner et je n'ai pas la graine de montage d'origine.

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].

Je suis vraiment inquiet parce que j'avais là-bas des fichiers importants qui étaient stockés sur une machine virtuelle… Si je pouvais simplement accéder à ces fichiers, je n'aurais aucun scrupule à nuquer la configuration et à recommencer

Réponses:


13

J'ai trouvé que l'exécution sudo bashet l'exécution en ecryptfs-recover-privatetant que root (plutôt que via sudo) fonctionnaient. Je ne sais pas pourquoi cela devrait être différent.

Éditer:

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

Vous ne verrez pas d'invite et vous devrez taper votre mot de passe de connexion, en aveugle, dans la commande ci-dessus.

Remplacez le aaaaaaaaaaaaaaaaet bbbbbbbbbbbbbbbbci - dessous par les signatures hexadécimales entre crochets de la sortie ci-dessus, dans l'ordre:

# 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

Préliminaires

Il se trouve que le fonctionnement de root n’a pas fonctionné de manière fiable pour moi; tantôt oui, tantôt non. Fondamentalement, ecryptfs semble bogué et peu convivial, souvent confondant les mots de passe de connexion et les phrases secrètes de montage. Après avoir descendu un trou de lapin profond et sombre, j'ai quelques conseils qui devraient vous aider. Ces notes concernent Ubuntu 17.10, ecryptfs-utils 111-0, et vous devez devenir root avant de commencer. Je suppose que vous souhaitez monter votre répertoire personnel à partir de /mnt/crypt(qui devrait déjà être monté) vers /mnt/plain, et vous devez le remplacer userpar le nom d'utilisateur.

Commencez facilement

La première chose à essayer est:

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

Si cela fonctionne, eh bien, vous avez de la chance. Sinon, il peut donner un message d'erreur d' mountenviron no such file or directory. C'est extrêmement trompeur: ce que cela signifie vraiment, c'est que votre phrase secrète de montage est incorrecte ou manquante.

Obtenez les signatures

Voici la partie importante: nous devons vérifier qu'ecryptfs essaie vraiment les bonnes phrases de passe de montage. Les phrases secrètes doivent être chargées dans le noyau Linux avant qu'ecryptfs ne puisse monter votre système de fichiers. ecryptfs les demande au noyau par leur signature. La signature est une valeur hexadécimale de 16 octets (et n'est pas cryptographiquement sensible). Vous pouvez trouver les signatures de mot de passe qu'ecryptfs attend:

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

Souvenez-vous-en. Le but est d'obtenir des phrases secrètes avec ces signatures chargées dans le noyau, puis de dire à ecryptfs de les utiliser. La première signature ( aaaaaaaaaaaaaaaa) est pour les données et la seconde ( bbbbbbbbbbbbbbbb) est la clé de cryptage FileName (FNEK).

Obtenez la phrase secrète de montage

Cette commande vous demandera votre mot de passe de connexion (avec une invite trompeuse) et affichera votre phrase secrète de montage :

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

Copiez ceci mais faites attention !! , car c'est extrêmement sensible sur le plan cryptographique, les clés du royaume.

Essayez une monture interactive

La prochaine chose à essayer est:

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

La chose cruciale ici est que mountvous avez besoin de votre phrase secrète de montage (super-sensible) que nous venons de copier (pas votre mot de passe de connexion).

Cela vous posera quelques questions, et vous pouvez accepter les valeurs par défaut, sauf dire oui à Enable filename encryption. Il peut vous donner un avertissement et vous demander de mettre en cache les signatures; vous pouvez dire oui aux deux, mais vérifiez bien que vous avez la bonne phrase de passe pour le montage.

Vous verrez les options qui mountont décidé d'essayer pour vous:

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

Si les signatures sont incorrectes (ne correspondent pas à ce que vous avez obtenu Private.sig), le montage ne fonctionnera pas.

... mais il rapportera très inutilement que c'est le cas. Vous devrez faire un ls /mnt/plainet cat un fichier pour vous en assurer. À ce stade, vous pouvez également rechercher /var/log/sysloget vérifier que ecryptfs recherche les mêmes signatures que nous.

Il y a clairement deux problèmes graves avec ecryptfs ici, et nous devons les contourner.

Chargez les clés dans le noyau

Si le montage interactif n'a pas aidé, nous devons charger nous-mêmes les clés dans le noyau et les spécifier manuellement dans les options de montage.

# ecryptfs-add-passphrase --fnek

Et collez votre phrase secrète de montage (super-senstive) copiée d'en haut. Cela devrait produire:

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

Monter manuellement

Maintenant, les phrases secrètes sont chargées dans le noyau, et nous avons juste besoin de dire à mount de les utiliser:

# 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

Vous remarquerez que les options sont similaires à ce que le support interactif a imprimé, sauf que nous informons manuellement ecryptfs de ce qui se passe.

Espérons que cela fonctionne. Sinon, vous pouvez vérifier que les clés sont chargées dans le noyau avec les signatures correctes en utilisant keyctl list @u, ce qui devrait imprimer au moins les deux signatures que vous attendez.


4
il existe une solution de contournement lorsque le ecryptfs-recover-privateproduit une erreur de montage (2). essayez d'exécuter sudo ecryptfs-manager, appuyez sur 4 (sortie), puis exécutez à nouveau l'original ecryptfs-recover-private. devrait fonctionner maintenant
ulkas

1
@ulkas Une idée de pourquoi cela fonctionne?
Turion

2
@Turion j'ai googlé la solution, donc je ne suis pas l'inventeur. ma supposition est qu'il y a un bogue dans la ecryptfsversion précédente et appeler le gestionnaire définit simplement certaines variables qui sont ensuite réutilisées par le mount.any idée comment automatiser cela afin que je puisse monter mes dossiers après chaque redémarrage?
ulkas

1
keyctl link @u @sétait une solution beaucoup plus simple pour moi. Les crédits sont disponibles ici: bugs.debian.org/cgi-bin/bugreport.cgi?bug=870126
sup

Bien que mon problème soit probablement différent de l'affiche originale.
sup

1

Pour les futurs téléspectateurs de ce Q & A: le même symptôme apparent peut être causé par différentes raisons sous-jacentes. Le symptôme ressemble à:

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].

Dans mon cas, cette réponse détenait la clé de la solution. Le problème était que j'essayais de tout faire à distance via SSH dans une session Tmux, qui était limitée par la ligne suivante dans /etc/pam.d/sshd:

session    optional     pam_keyinit.so force revoke

La réponse susmentionnée suggère de commenter cette ligne et de réessayer dans une nouvelle session.

La solution de contournement simple qui a fonctionné dans mon cas était de le faire sur place, en évitant complètement SSH et Tmux. Une solution de contournement plus compliquée (que je n'ai pas vérifiée) consiste à utiliser quelque chose comme conspy pour accéder à distance à un terminal illimité.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.