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.
ecryptfs-recover-privateproduit une erreur de montage (2). essayez d'exécutersudo ecryptfs-manager, appuyez sur 4 (sortie), puis exécutez à nouveau l'originalecryptfs-recover-private. devrait fonctionner maintenantecryptfsversion 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?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=870126Pour 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 à:
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: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é.
la source