Bonjour à tous.

J'ai tout récemment voulu remplacer ma distribution Elementary OS (dérivée d'Ubuntu) pour un retour à Fedora. J'ai pour cela reformaté le système de fichier, à l'exception du /home qui était sur une partition à part.

Je me doutais que le chiffrement du home pourrait poser problème, et ai donc récupéré la clef de chiffrement ecryptfs avant l'installation. L'utilisateur créé durant l'installation ayant le même login et mot de passe que sous Elementary, le /home de l'utilisateur lui a été correctement attribué. Malheureusement, impossible de l'utiliser (ni même de se connecter avec cet utilisateur puisque son répertoire n'est pas accessible).

J'ai tenté de déchiffrer le dossier normalement grâce à ecryptfs-recover-private, mais le résultat obtenu est identique à celui d'un bête ls /home/user : 
[root@localhost ecryptfs.wRbss549]# ls
Access-Your-Private-Data.desktop  README.txt
Le fichier .desktop renvoie à un fichier ayant disparu lors du formatage, et README.txt ne fait que renvoyer vers ecryptfs-mount-private.

Pensant que le dossier avait peut-être été re-chiffré par erreur lors de l'installation, j'ai tenté un second décodage. Sans succès :
[root@localhost ecryptfs.wRbss549]# ecryptfs-recover-private /tmp/ecryptfs.wRbss549/
INFO: Found [/tmp/ecryptfs.wRbss549/].
Try to recover this directory? [Y/n]: 
INFO: Could not find your wrapped passphrase file.
INFO: To recover this directory, you MUST have your original MOUNT passphrase.
INFO: When you first setup your encrypted private directory, you were told to record
INFO: your MOUNT passphrase.
INFO: It should be 32 characters long, consisting of [0-9] and [a-f].

Enter your MOUNT passphrase: 
mount: mauvais type de système de fichiers, option erronée, superbloc erroné
        sur /tmp/ecryptfs.wRbss549, page de code ou programme auxiliaire manquant, ou autre erreur

        Dans certains cas des renseignements utiles sont dans le journal
        système — essayez « dmesg | tail » ou quelque chose du genre.
Je suis à court de solutions et Google semble l'être aussi.
Salut =)

Et si tu faisais un simple ecryptfs-recover-private en root ? 🙂

PS : on dit "chiffré" pas "crypté" 🙂
marc2006 wrote:Salut =)

Et si tu faisais un simple ecryptfs-recover-private en root ? 🙂

PS : on dit "chiffré" pas "crypté" 🙂
Sans arguments ?
[root@localhost ecryptfs.wRbss549]# ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
find: ‘/run/user/1001/gvfs’: Permission non accordée
Le résultat est le dossier Private de l'utilisateur 1001, créé en tâtonnant avec ecryptfs-setup-private. Visiblement la fonction ne recherche que ce genre de dossiers quand on ne lui passe pas d'argument.
Si tu fais un mount, t'as quoi ?

La partition est montée j'imagine, en fait encryptfs crée un fichier chiffré et le monte sous forme de partition c'est ça ?
Ton mdp n'est pas en anglais par hasard? Fedora ayant la facheuse tendance à remettre le qwerty et pas mal de monde ce sont retrouvé dans ce genre de cas.

Voir aussi en désactivant selinux...
J'ai tenté de monter le répertoire chiffré de cette manière :
[root@localhost userBis]# mount -t ecryptfs /home/user /media/decrypted2
Select key type to use for newly created files: 
 1) tspi
 2) openssl
 3) pkcs11-helper
 4) passphrase
Selection: 4
Passphrase: 
Select cipher: 
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32
 2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
Selection [aes]: 
Select key bytes: 
 1) 16
 2) 32
 3) 24
Selection [16]: 
Enable plaintext passthrough (y/n) [n]: 
Enable filename encryption (y/n) [n]: y
Filename Encryption Key (FNEK) Signature [a0d2e00ecfbe29ac]: 
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=a0d2e00ecfbe29ac
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=a0d2e00ecfbe29ac
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key 
before. This could mean that you have typed your 
passphrase wrong.

Would you like to proceed with the mount (yes/no)? : yes
Would you like to append sig [a0d2e00ecfbe29ac] to
[/root/.ecryptfs/sig-cache.txt] 
in order to avoid this warning in the future (yes/no)? : yes
Successfully appended new sig to user sig cache file
Mounted eCryptfs
Après cette opération, le contenu de /media/decrypted2 est le même que celui de la tentative précédente (un fichier .desktop et un Readme). J'ai à nouveau essayé de le déchiffrer une seconde fois, et le message d'erreur fut exactement le même que celui du premier post. J'ai cependant fait un dmesg | tail comme suggéré :
[  286.808034] One or more global auth toks could not properly register; rc = [-2]
[  286.808036] Error parsing options; rc = [-2]
[  335.987682] Could not find key with description: [a0d2e00ecfbe29ac]
[  335.987687] process_request_key_err: No key
[  335.987689] Could not find valid key in user session keyring for sig specified in mount option: [a0d2e00ecfbe29ac]
[  335.987690] One or more global auth toks could not properly register; rc = [-2]
[  335.987692] Error parsing options; rc = [-2]
[  502.430841] SELinux: initialized (dev ecryptfs, type ecryptfs), uses genfs_contexts
[  589.135953] Mount on filesystem of type eCryptfs explicitly disallowed due to known incompatibilities
[  589.136021] Reading sb failed; rc = [-22]
Pour ce qui est de mon mot de passe, il fonctionne correctement. La seule erreur possible viendrait de la phrase de passe qui est un code que je copie-colle.

À défaut de pouvoir chercher ailleurs, je vais me renseigner à propos de ce bug de SELinux.
Hmmm donc le /home est ta partition, et tu as voulu chiffrer le répertoire "user" c'est ça ? Enfin, de ce que je comprends de la doc d'Ubuntu, c'est un répertoire Private qui contient le répertoire chiffré.
ls -al /home
donne quoi ?

As-tu essayé avec cette commande 
ecryptfs-mount-private
?

Sinon, pour SELinux, tu peux le désactiver temporairement par 
setenforce 0
La commande ecryptfs-mount-private concerne les dossiers .Private créés avec l'utilitaire ecryptfs-setup-private, ce qui n'est pas mon cas. L'installation d'Elementary OS m'ayant proposé de chiffrer mon /home, j'ai accepté à ce moment. De retour sur Fedora, je peux utiliser ma partition /home mais n'ai plus accès à mon ancien répertoire personnel (ici renommé en user).
Tu as chiffré le /home (la partition) ? Donc c'est l'outil de l'ancien OS qu'il faut regarder, es-tu sûr que c'est ecryptfs et non pas luks ?

Je ne connais pas ce genre de chiffrage juste pour le répertoire personnel ... Lors de l'installation de Fedora par exemple, je choisissais de chiffrer mes partitions LVM, mais c'est du LUKS donc. Cryptfs est juste pour avoir un "coffre-fort" (dossier .Private).
Sous Fedora, lors de l'installation, je suppose que l'installateur t'a demandé le mot de passe pour monter la partition du /home ?
Je ne pense pas que ce soit la partition entière qui ait été chiffrée, mais juste le répertoire personnel. Les deux fichiers lisibles de /home/user/ faisant référence à ecryptfs, c'est certainement cette méthode qui a été utilisée (d'autant plus que j'ai pu récupérer la clef de chiffrement avant le changement d'OS).

Je suis presque certain de ne pas avoir eu besoin de mot de passe pour monter la partition /home lors de l'installation. Raison de plus de penser que seuls les fichiers ont été chiffrés.
ls -al /home
?

EDIT :
je me suis trompé, c'est cette commande qu'il faudrait que tu lances stp : 
ls -al /home/user
Le nom d'utilisateur de ta session est "user" ? (ou tu l'as probablement changé) Tu tournes actuellement sur ce user, ou un autre pour l'occasion ?

Je viens d'installer le paquet ecryptfs-utils pour comprendre la chose, et bon, si c'est bien "user" qui est chiffré, le recover n'a pas lieu d'être, car tu es déjà sous le nom d'utilisateur dont un répertoire est chiffré.
J'attends déjà ta réponse avant de continuer ^^
Oh. Il semblerait que j'ai fait une erreur.

Lorsque eOS a chiffré mon dossier personnel, il n'a en fait pas à proprement parler utilisé /home/user. Je viens de trouver les fichiers chiffrés dans /home/.ecryptfs/user/.Private. Le logiciel a donc bel et bien utilisé un dossier .Private, et a placé un lien symbolique dans /home/user.

Malheureusement, cela ne change pas grand-chose. Déchiffrer le contenu de /home/.ecryptfs/user/.Private ne fonctionne pas mieux et j'imagine que c'était déjà ce que je faisait auparavant sans savoir que je passait par un lien symbolique.

Concernant le nom d'utilisateur, j'en ai créé un nouveau que j'utilise en ce moment. L'ancien ne peut tout simplement pas se connecter. J'ignore si c'est dû au chiffrage de son répertoire personnel ou à une erreur de permissions, mais ce n'est pas la priorité.
Léger progrès en perspective : J'ai à nouveau tenté de monter l'ancien répertoire user, cette fois-ci dans celui de l'utilisateur que j'utilise en ce moment.

Un ls -al affiche désormais les noms de mes fichiers chiffrés, mais ils sont illisibles. De plus, les permissions ne s'affichent pas. J'ai donc une longue liste semblable à cela :
d??????????  ? ?       ?           ?            ? .adobe
d??????????  ? ?       ?           ?            ? .android
d??????????  ? ?       ?           ?            ? .aptitude
d??????????  ? ?       ?           ?            ? Backup
Ok bon donc j'ai eu l'information que je voulais lol le ls -al /home était pas inutile donc :p

Un 
ecryptfs-recover-private /home/.ecryptfs/user/.Private
donne quoi ?

EDIT : oui normal, tu n'as pas déchiffré le dossier ^^ Bref, un "mount" dit quoi aussi ?
marc2006 wrote:Ok bon donc j'ai eu l'information que je voulais lol le ls -al /home était pas inutile donc :p

Un 
ecryptfs-recover-private /home/.ecryptfs/user/.Private
donne quoi ?
Fichiers récupérés !

À force de me battre avec chaque utilitaire j'avais fini par oublier celui-ci. En revanche, l'ancien utilisateur ne peut toujours pas se connecter normalement. Je vais voir s'il faut reconfigurer les permissions ou faire une manip pour monter automatiquement le dossier chiffré au démarrage du système. Quoi qu'il en soit la phase de panique est passée et je peux toujours copier le contenu du dossier chiffré dans le répertoire d'un nouvel utilisateur. Merci énormément !
Oui oui chaque chose en son temps (on n'a pas fini) lol

Là, on a juste déchiffré le répertoire, et on l'a monté avec 
ecryptfs-mount-private
c'est bien ce que t'as fait ? Le répertoire Private doit être monté dans /tmp/encrypt.XXXXX

De plus, tu dois pouvoir utiliser le raccourci Access your Data pour le monter 😉
Il s'est effectivement monté sur /tmp, mais sans passer par ecryptfs-mount-private (Encrypted private directory is not setup properly).
Je crois que c'est parce que tu n'es pas sous l'user approprié.

Il faudrait repartir de 0, car tu as fait des mount mais c'était inutile ... Et donc il faut redémarrer.

Mais avant, exécute cette commande en root : 
usermod -a -G ecryptfs user
Je suppose ici que "user" est bel et bien le nom d'utilisateur du compte qui possède le /home/user. 🙂

Et, pour pouvoir utiliser le raccourci "Access-Your-Private-Data", exécute ça : 
chmod +x /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
Ensuite tu redémarres, sous le compte "user" (celui où tu devrais te connecter normalement), et regarde si ça marche.
Aucun changement (d'ailleurs j'avais déjà ajouté l'utilisateur au groupe ecryptfs). Si je tente de me connecter en terminal, j'obtiens l'erreur suivante :
change directory failed : Permission denied.
Logging with home ="/".
Tant qu'au raccourci, il semblait réclamer xTerm, mais ne fonctionne toujours pas une fois celui-ci installé.
Et maintenant, en tant qu'utilisateur user, que donne la commande ecryptfs-mount-private ?

Regarde aussi si dans le fichier /etc/sysconfig/authconfig, le paramètre USEECRYPTFS est à yes.