Mi computadora se congeló por mucho tiempo y presioné el botón de reinicio. Después de reiniciar, los CINCO sistemas de archivos cifrados con luks (LUKS 1) ya no se abrirán. El mensaje que recibo es "No hay clave disponible con esta frase de contraseña". Estoy seguro de que estoy usando la contraseña correcta. Llevo años usando la misma contraseña para todos los sistemas de archivos. Tengo copias de seguridad de todos esos volúmenes excepto uno, así que me gustaría analizar mis opciones. Probé 'cryptsetup isLuks' y 'cryptsetup luksDump' en todos los sistemas de archivos y todos tuvieron éxito, es decir, son particiones Luks y puedo volcar sus encabezados y ver sus ranuras. Sin embargo, al investigar, encontré casos similares en los que las personas dicen que sus cabezales han sufrido daños irreparables. No sé cómo identificar eso. ¿Cómo puedo hacer eso? Gracias por cualquier información.
Respuesta1
Encontré esta página:
https://bbs.archlinux.org/viewtopic.php?pid=1846810#p1846810
También esta página:
Más específicamente,
"Puede saber con bastante rapidez si existe alguna posibilidad de recuperación. Ejecute "hexedit -s /dev/sdx" y busque la cadena hexadecimal "4C 55 4B 53 BA BE" al inicio de un sector. (Esa es la cadena ASCII "LUKS" seguido de los bytes hexadecimales 0xBA y 0xBE). Si no encuentra eso en los primeros megabytes del disco, el encabezado LUKS habrá desaparecido".
Los cinco sistemas de archivos que se niegan a abrir tienen esa cadena intacta en sus encabezados, por lo que parecen no estar dañados. Ahora bien, por qué no se abren todos es un tema aparte y sospecho que nunca descubriré qué pasó.
Respuesta2
Respuesta proporcionada para la posteridad.
¿Cómo saber si su encabezado LUKS está dañado?
La respuesta corta a su pregunta es que le dirá que está dañado cuando intente desbloquearlo o que el sistema se congela al intentar ingresar la frase de contraseña si es la partición de inicio. Pero, en su caso, simplemente le da un error acerca de que la clave no está "disponible con esta frase de contraseña", lo cual es un poco extraño.
Dado que ya descubrió que hexedit -s <device>también puede intentar ejecutar dmsetup info <device_name>]después de haber intentado ingresar la contraseña y ver qué tipo de estado se informa, las tablas se informan como presentes, etc. Consulte laPágina de manual para DMsetuppara más información.
O intente dmsetup table --showkeys <device or header file>ver si reconoce la ranura para llaves.
Métodos adicionales para verificar el encabezado LUKS
Además de usar cryptsetup luksHeaderBackup <device> --header-backup-file <file>para crear una copia de seguridad del encabezado (aunque no se abre, ya que luksDumpno informa ningún daño), también puedes intentar hacer una copia de seguridad de ellos y luego intentar restaurarlos desde esas copias de seguridad para ver si cryptsetupfuncionan. le permitirá restaurar el encabezado de esa manera. Aparte del método mencionado anteriormente, también puedes utilizar ddcomo alternativa para crear una "copia de seguridad" del encabezado:
root@system:# dd if=<device> of=<Luksheader_filename> bs=512 count=4097
Además de usarlo hexeditpara verificar el encabezado, también puede usar el comando fileo stringsen el archivo que acaba de crear arriba, o incluso ejecutar luksDumpel comando en el archivo mismo reemplazando el nombre del dispositivo con la ruta y el nombre del archivo.
root@system:# file <Luksheader_filename>
root@system:# strings <Luksheader_filename> | grep -i luks LUKS
root@system:# cryptsetup luksDump <Luksheader_filename>
Casos similares pueden o no ser tan similares
En términos de los demás y su investigación, los que vinculó anteriormente, no quedó claro qué estaba haciendo cuando su computadora se congeló y, por lo tanto, sería la última vez que pudo acceder a las unidades. Por el contrario, dos enlaces implican dos razones diferentes por las que sus unidades individuales cifradas con LUKS se vuelven inaccesibles, una relacionada con unHPAconfiguración incorrecta y el otro fue después de una actualización del kernel que solo afectó al /homevolumen y no al /rootvolumen, y en realidad puede deberse a unproblema de recorte/descarte.
Quizás se pueda encontrar un problema más similar basado en la explicación amplia.aquí, donde incluso comenzaron a considerar la posibilidad de que un rayo cósmico fuerce un cambio de bit en alguna parte y puede ser una buena lectura para alguien que quiera verificar que ha explorado todas las demás opciones.
Dado que, según la información proporcionada, no está claro si estos "sistemas de archivos"*, como usted los llama, contienen o no su sistema operativo o simplemente "contenido", como lo describiremos en términos generales, sería útil saber si su sistema se congela al intentarlo. para arrancar si uno de los volúmenes/particiones cifrados LUKS es su unidad de arranque y la contraseña no funciona o si simplemente está intentando acceder a esos 5 dispositivos desde la terminal y/o desde una GUI (y en qué versión de Linux ) que te da ese error repetido? En cuyo caso, puede haber alguna ligera esperanza con esto último.
*Como aclaración, "sistema de archivos" se referiría a cómo y dónde se almacenan los datos, por lo que el sistema de archivos generalmente se referirá a formatos como ext3, ext4, NTFS, etc., mientras que LUKS es una especificación de cifrado de disco. Por lo tanto, no nos da ninguna idea de qué papel desempeñan esos 'sistemas de archivos' de 5 LUKS (presumiblemente volúmenes como usted menciona) como parte de su sistema.
Posible problema sin encabezado
La pregunta era sobre cómo identificar y/o determinar un encabezado LUKS dañado. Sin embargo, sin una copia de seguridad de cualquiera de los encabezados, no habría una versión no dañada del encabezado para que el OP la compare. Dado que puede resultar más claro ahora que la situación que se aplica es incierta y probablemente diferente a los ejemplos vinculados, puede que valga la pena intentarlo:
Comprobando si es un problema de LVM usando
root@system:# lvscan
# or
root@system:# lvdisplay
# To check if you can still identify the LUKS filesystems as volume groups or
# supported LVM block devices.
root@system:# vgdisplay --short
# To find the Volume Group (usually fails if password won't work)
root@system:# lvs -o lv_name,lv_size -S vg_name=[name_of_volumegroup]
# To list the logical volumes identified in the volume group (if it works)
Consulte la página de manual paralvscanypantallavgaprender más.
Y explorar otras posibilidades
Desafortunadamente, con el cifrado LUKS1, las sumas de verificación no se implementaron por varias razones, que puede aprender deesta presentaciónSi es deseado. De lo contrario, eso es sólo para decir que la única "suma de comprobación" en LUKS es la que le indica que no hay una ranura de clave coincidente e implica que está dañada.
Sin embargo, se observó que usted había dicho que los 5 sistemas de archivos no se abrirían y se referiría a todos ellos como volúmenes, por lo que no está claro si está todo en un disco y si es una unidad SSD o no, en cuyo caso, unEscaneo de memoria y almacenamientodel disco sería la siguiente sugerencia.
Finalmente, sin duda, usted optó cryptsetuppor sudo¿sí?
Quizás también quieras probar
- Usando la función de recuperación en la GUI de gparted que se encuentra con respecto a las tablas de particiones y todo eso
- Dándole un escaneo con
ddrescue - Asegúrate de que el bloqueo de mayúsculas o el bloqueo numérico no estén activados (es una tontería, lo sé, pero solo un suave recordatorio)
- Pruebe algunas de las respuestas sugeridas.aquí
- Si hubo una actualización antes de que la computadora se congelara, intente volver a una versión anterior.
- Intente agregar una contraseña en otra ranura de clave
Nota al margen
Se supuso que intentó abrir los volúmenes cifrados LUKS dentro de una terminal y con sudo, ya que no se mencionó ningún sistema o GUI específico ni se mencionó un proceso de arranque.