montaje: no existe tal archivo o directorio con recuperación cifrada

12

He destruido mi instalación de Mint Linux. Solo quería acceder a mi tienda remota. Entonces, lo que sucedió fue que estaba teniendo problemas con el archivo de autorización ICE en mi directorio de inicio. Entonces, siguiendo diferentes instrucciones en Internet, llegué a la conclusión de que podía configurar el directorio de inicio de forma recursiva en chmod 755 para permitir que ese archivo funcione ... eventualmente tuve problemas con la carga del sistema. Finalmente, al configurar el directorio de inicio con permiso de ejecución para root, pude obtener acceso de lectura / escritura ... pero luego reinicié mi máquina ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ - ahora el sistema me arroja el mismo error con ICEauthority pero nunca me mete en el sistema operativo porque el disco está encriptado. Nada de lo que he intentado parece funcionar y no tengo la semilla de montaje original.

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

Estoy realmente preocupado porque tenía archivos importantes allí almacenados en una máquina virtual ... Si pudiera acceder a esos archivos, no tendría reparos en destruir la configuración y comenzar de nuevo

Frankenmint
fuente

Respuestas:

13

Descubrí que funcionar sudo bashy luego ejecutar ecryptfs-recover-privatecomo root (en lugar de a través de sudo) funcionó. No estoy seguro de por qué debería ser diferente.

Editar:

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

No verá un mensaje y debe escribir su contraseña de inicio de sesión, ciega, en el comando anterior.

Reemplace el aaaaaaaaaaaaaaaay bbbbbbbbbbbbbbbbabajo con las firmas hexadecimales entre paréntesis de la salida anterior, en orden:

# 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

Preliminares

Resulta que solo se ejecuta ya que la raíz no funcionó de manera confiable para mí; a veces lo hizo, a veces no. Básicamente, ecryptfs parece tener errores y es poco amigable para el usuario, a menudo confuso, contraseñas de inicio de sesión y frases de montaje. Después de bajar por una madriguera de conejo profunda y oscura, tengo algunos consejos que deberían ayudar. Estas notas son para Ubuntu 17.10, ecryptfs-utils 111-0, y debe convertirse en root antes de comenzar. Supongo que desea montar su directorio de inicio /mnt/crypt(que ya debería estar montado) /mnt/plainy debe reemplazarlo usercon el nombre de usuario.

Comience fácil

Lo primero que debes intentar es:

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

Si esto funciona, bueno, tienes suerte. Si no, puede dar un mensaje de error de mountaproximadamente no such file or directory. Esto es extremadamente engañoso: lo que realmente significa es que su frase de contraseña de montaje es incorrecta o falta.

Consigue las firmas

Aquí está la parte importante: necesitamos verificar que ecryptfs realmente está intentando la frase de contraseña de montaje correcta. Las frases de contraseña deben cargarse en el kernel de Linux antes de que ecryptfs pueda montar su sistema de archivos. ecryptfs le pide al kernel por su firma. La firma es un valor hexadecimal de 16 bytes (y no es criptográficamente sensible). Puede encontrar las firmas de frase de contraseña que ecryptfs espera:

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

Recuerda estos. El objetivo es obtener frases de contraseña con estas firmas cargadas en el kernel y luego decirle a ecryptfs que las use. La primera firma ( aaaaaaaaaaaaaaaa) es para los datos, y la segunda ( bbbbbbbbbbbbbbbb) es la Clave de cifrado de nombre de archivo (FNEK).

Obtén la frase de contraseña de montaje

Este comando le pedirá su contraseña de inicio de sesión (con un mensaje engañoso) y generará su frase de contraseña de montaje :

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

Copia esto pero ten cuidado !! , ya que esto es extremadamente criptográficamente sensible, las claves del reino.

Prueba un montaje interactivo

Lo siguiente que debes intentar es:

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

Lo crucial aquí es que mountnecesita su frase de contraseña de montaje (súper sensible) que acabamos de copiar (no su contraseña de inicio de sesión).

Esto le hará algunas preguntas, y puede aceptar los valores predeterminados, excepto decir que sí Enable filename encryption. Puede darle una advertencia y pedirle que guarde en caché las firmas; puede decir sí a ambos, pero verifique que tenga la frase de contraseña de montaje correcta.

Verá las opciones que mountha decidido probar por usted:

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 las firmas son incorrectas (no coinciden con las que obtuvo Private.sig), el soporte no funcionará.

... pero informará muy inútilmente que lo hizo. Tendrá que hacer un ls /mnt/plainarchivo cat para asegurarse. En este punto, también puede mirar /var/log/syslogy verificar que ecryptfs está buscando las mismas firmas que nosotros.

Claramente, hay dos problemas serios con ecryptfs aquí, y tenemos que solucionarlos.

Cargue las claves en el kernel

Si el montaje interactivo no ayudó, tenemos que cargar las claves en el núcleo nosotros mismos y especificarlas manualmente en las opciones de montaje.

# ecryptfs-add-passphrase --fnek

Y pegue en su (súper sensible) frase de contraseña de montaje copiada desde arriba. Esto debería generar:

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

Montar manualmente

Ahora las frases de contraseña se cargan en el núcleo, y solo necesitamos decirle a mount que las use:

# 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

Notarás que las opciones son similares a las que imprimió la montura interactiva, excepto que le estamos diciendo manualmente a ecryptfs qué pasa.

Ojalá esto funcione. De lo contrario, puede verificar que las claves estén cargadas en el kernel con las firmas correctas keyctl list @u, lo que debería imprimir al menos las dos firmas que espera.

Doctor j
fuente
44
hay una solución alternativa cuando la ecryptfs-recover-privatesalida genera un error de montaje (2). intente ejecutar sudo ecryptfs-manager, presione 4 (salir), luego vuelva a ejecutar el original ecryptfs-recover-private. debería funcionar ahora
ulkas
1
@ulkas ¿Alguna idea de por qué esto funciona?
Turion
2
@Turion busqué en Google la solución, así que no soy el inventor. Supongo que hay un error en ecryptfsalguna versión y llamar al administrador simplemente establece algunas variables que luego son reutilizadas por el montaje. ¿Alguna idea de cómo automatizar esto para poder montar mis carpetas después de cada reinicio?
ulkas
1
keyctl link @u @sFue una solución mucho más simple para mí. Los créditos van aquí: bugs.debian.org/cgi-bin/bugreport.cgi?bug=870126
sup
Aunque mi problema probablemente era diferente del póster original.
sup
1

Para los futuros espectadores de estas preguntas y respuestas: el mismo síntoma aparente puede ser causado por diferentes razones subyacentes. El síntoma se ve así:

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

En mi caso, esta respuesta tenía la clave de la solución. El problema era que estaba tratando de hacer todo de forma remota a través de SSH en una sesión de Tmux, que estaba limitada por la siguiente línea /etc/pam.d/sshd:

session    optional     pam_keyinit.so force revoke

La respuesta antes mencionada sugiere comentar esa línea e intentar nuevamente en una nueva sesión.

La solución simple que funcionó en mi caso fue hacerlo en el lugar, evitando por completo SSH y Tmux. Una solución alternativa más complicada (que no he verificado) es usar algo como conspy para obtener acceso a un terminal ilimitado de forma remota.

Amir
fuente