Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

217
Vistas
Red Hat Linux: "desactivar" la comprobación de cifrado

Tengo una implementación de Red Hat 6.5 Linux que usa LUKS para cifrar el sistema y, por razones que no son relevantes, me gustaría "desactivar" la comprobación de cifrado de arranque durante un período de tiempo. Se volverá a activar en algún momento, por lo que incluso si es posible eliminar el cifrado LUKS por completo, esa no es una solución que me interese.

Lo que quiero es proporcionar automáticamente la contraseña de LUKS en el arranque para que no sea necesario ingresarla manualmente; por lo tanto, lógicamente "apagar" el cifrado aunque todavía esté habilitado.

Ahora, si bien esto es sencillo para dispositivos secundarios, es decir. al crear un archivo de clave, aplicar el archivo de clave a los dispositivos encriptados y modificar /etc/crypttab para hacer referencia al archivo de clave, aún debe ingresar al menos una contraseña en el arranque, porque, si el dispositivo principal está encriptado con LUKS, entonces primero tiene que ser descifrado antes de que /etc/crypttab sea accesible.

Hay una forma que he visto de eliminar el requisito de ingresar la contraseña inicial, que es:

  1. crear un archivo clave
  2. aplicar el archivo clave al dispositivo cifrado, es decir. habilitar la clave para que el dispositivo sea descifrado
  3. Copie el archivo de clave en un dispositivo extraíble no cifrado (por ejemplo, una unidad flash)
  4. agregue rd.luks.key= ruta absoluta al archivo de clave : dispositivo extraíble no encriptado a la línea del kernel de arranque en /boot/grub/grub.conf
  5. En el arranque, asegúrese de que el dispositivo extraíble no cifrado esté insertado y pueda ser referenciado por el proceso de arranque.

Todo esto se ve bien, excepto que no quiero un dispositivo extraíble no encriptado involucrado. Simplemente quiero que el servidor arranque como si no estuviera encriptado.

La única forma que veo para lograr esto es reemplazar el dispositivo no cifrado extraíble con un dispositivo no cifrado normal . En cuyo caso, el proceso de arranque leería el dispositivo normal no cifrado , obtendría la clave y la usaría para descifrar los dispositivos cifrados... ¡hey, el cifrado está deshabilitado!

El único dispositivo que puedo encontrar en mi sistema que cumple con los criterios normales de dispositivos no cifrados es /dev/sda1, es decir. /boot, así que realicé los pasos anteriores con los pasos 3 y 4 de la siguiente manera:

  1. como anteriormente
  2. como anteriormente
  3. copie el archivo clave a /boot/keyfile.key
  4. agregar rd.luks.key=/boot/keyfile.key:/dev/sda1
  5. n / A

Desafortunadamente, parece que no puedo hacer que esto funcione.

Red Hat arranca y no se me pide una contraseña (como se esperaba), sin embargo, hacia el final del proceso de arranque, falla con "Pánico en el kernel: no se sincroniza: se intentó matar a init! ..."

Este comportamiento es idéntico cualquiera de los siguientes que use:

  • rd.luks.key=/boot/keyfile.key:/dev/sda1
  • rd.luks.key=/keyfile.key:/dev/sda1
  • rd.luks.key=/archivoclave.clave
  • rd.luks.key=/ algúnArchivoClaveQueConozcoNoExiste.key :/dev/sda1

Entonces mis preguntas son las siguientes:

  1. ¿Es posible lo que estoy tratando de hacer?
  2. Si es así, entonces...
    • ¿Dónde debo poner el archivo clave?
    • ¿Cuál es el valor rd.luks.key que debo usar para hacer referencia al archivo clave?

Gracias de antemano por cualquier ayuda

over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

Después de mucho investigar, finalmente encontré la respuesta (que funciona tanto en CentOS 6.6 como en 7). Gracias a los siguientes 2 recursos en particular:

  • Deshabilitar el cifrado LUKS
  • RedHat Bug 751640 - dracut ignora el archivo de claves crypttab

Lo que hice fue lo siguiente (como usuario root):

 # insert a password into my chosen password file echo -n "anypassword" > /etc/mypasswdfile # instruct the LUKS device to take the password from my password file vi /etc/crypttab and replaced the 3rd parameter "none" with "/etc/mypasswdfile" # add my password file as a valid key for the luks device cryptsetup luksAddKey /dev/sda2 /etc/mypasswdfile # configure dracut to add the following 2 items to the initramfs (so accessible at boot) echo 'install_items="/etc/mypasswdfile /etc/crypttab"' > /etc/dracut.conf.d/99-mypwfile.conf # instruct dracut to apply the configuration dracut -f # reboot the server reboot

Y eso es. El servidor se reinicia sin solicitar una contraseña. (Esto se puede deshabilitar/habilitar a voluntad eliminando/agregando el archivo de claves del dispositivo LUKS a través del comando cryptsetup)

over 4 years ago · Santiago Trujillo Denunciar

0

Nunca tuve la necesidad de esto, pero ciertamente puedo relacionarme con su utilidad. Entonces, su publicación me impulsó a revisar cómo se podría hacer esto, y la única forma que veo es obtener los scripts/detalles de desbloqueo en initramfs.

Este es un proceso mucho más fácil en distribuciones basadas en Debian, porque es posible inyectar scripts en initramfs a través de initramfs-tools... dinámicamente en el arranque. Ver esto y esto y esto

Las distribuciones basadas en RHEL requerirían el uso de dracut (en modo de recuperación) para reconstruir initramfs. Por lo tanto, creo que puede resolver este problema reconstruyendo initramfs e inyectando sus scripts de desbloqueo allí ... de esa manera podemos estar seguros de que su dispositivo raíz/arranque se haya desbloqueado antes de que el kernel necesite montarlos. Este hilo de Gentoo sugiere una forma de acceder y modificar los contenidos de initramfs. En cuanto a la mejor manera de inyectar sus scripts de desbloqueo en initramfs, no estoy seguro de eso.

Sin duda intentaré esto cuando esté menos ocupado. Suena algo bastante útil para poder configurar.

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda