Distribuciones basadas en Debian:
Debian y Ubuntu envían un script de almacenamiento en caché de contraseñas decrypt_keyctl con cryptsetup paquete.
descifrar_clavectl El script proporciona la misma contraseña para varios objetivos de LUKS cifrados, lo que le evita tener que escribirla varias veces. Se puede habilitar en crypttab con keyscript=decrypt_keyctl opción. Se utiliza la misma contraseña para objetivos que tienen el mismo identificador en el campo de archivo de claves . En el arranque, la contraseña para cada identificador se solicita una vez.
Un ejemplo de crypttab :
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks luks,keyscript=decrypt_keyctl
part2_crypt /dev/disk/... crypt_disks luks,keyscript=decrypt_keyctl
El decrypt_keyctl el script depende del keyutils paquete (que solo se sugiere y, por lo tanto, no necesariamente se instala).
Después de haber actualizado su cryptab , también deberá actualizar initramfs para aplicar los cambios. Usa update-initramfs -u .
Léame completo para decrypt_keyctl se encuentra en /usr/share/doc/cryptsetup/README.keyctl
Desafortunadamente, esto actualmente no funciona en los sistemas Debian que usan systemd init debido a un error (Otros sistemas de inicio no deberían verse afectados). Con este error, systemd le solicita la contraseña por segunda vez, lo que hace que sea imposible desbloquearlo de forma remota a través de ssh. Debian página de manual de crypttab sugiere como solución alternativa usar initramfs opción para forzar el procesamiento en la etapa initramfs de arranque. Entonces, para evitar este error, un ejemplo para /etc/crypttab en Debian
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks luks,initramfs,keyscript=decrypt_keyctl
part2_crypt /dev/disk/... crypt_disks luks,initramfs,keyscript=decrypt_keyctl
Distribuciones que no proporcionan decrypt_keyctl guión:
Si decrypt_keyctrl no es proporcionado por su distribución, el dispositivo se puede desbloquear usando un archivo de claves en el sistema de archivos raíz encriptado. Esto cuando el sistema de archivos raíz se puede desbloquear y montar antes que cualquier otro dispositivo cifrado.
LUKS admite múltiples ranuras para llaves. Esto le permite desbloquear alternativamente el dispositivo usando una contraseña si el archivo clave no está disponible o se ha perdido.
-
Genere la clave con datos aleatorios y configure sus permisos para que el propietario solo pueda leerlos para evitar filtrarlos. Tenga en cuenta que el archivo clave debe estar en la partición raíz que se desbloquea primero.
dd if=/dev/urandom of=<path to key file> bs=1024 count=1 chmod u=rw,g=,o= <path to key file> -
Agrega la clave a tu dispositivo LUKS
cryptsetup luksAddKey <path to encrypted device> <path to key file> -
Configurar crypttab para usar el archivo clave. La primera línea debe ser el dispositivo raíz, ya que los dispositivos se desbloquean en el mismo orden que se indica en crypttab . Use rutas absolutas para archivos clave.
<target> <source> <keyfile> <options> root_crypt /dev/disk/... none luks part1_crypt /dev/disk/... <path to key file> luks
Otra opción es usar el /lib/cryptsetup/scripts/decrypt_derived script, que también forma parte de cryptsetup en Debian/Ubuntu.
En lugar de almacenar en caché la clave, utiliza la clave de volumen de un disco como contraseña adicional para el segundo disco. Esto requiere agregar una segunda contraseña al segundo (y tercero, etc.) disco cifrado, pero LUKS lo admite. Por lo tanto, esta solución también funciona si sus múltiples discos encriptados no usan la misma contraseña.
Ejemplo para agregar la clave de sda6crypt a sda5:
Agregue la clave de volumen de sda6crypt como contraseña adicional para sda5:
mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo
Configure sda5crypt para que se desbloquee automáticamente en /etc/crypttab
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
Esto usa una canalización con nombre (fifo ) para pasar la clave y evitar tener que almacenar la clave de volumen en un archivo temporal en el disco.
El keyscript la opción solo funciona si crypttab es procesado por las herramientas cryptsetup originales de Debian, la reimplementación de systemd no es compatible actualmente. Si su sistema usa systemd (que es la mayoría de los sistemas), necesita el initramfs Opción para forzar el procesamiento en el initrd mediante las herramientas cryptsetup, antes de que se inicie systemd.
Basado en https://unix.stackexchange.com/a/32551/50793
Aquí está mi solución en Debian, dado el error mencionado anteriormente por @sebasth.
Mi configuración es ligeramente diferente. Tengo una partición raíz encriptada y un montón de discos raid. Para mí, tuve que agregar una opción initramfs a crypttab:
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
part2_crypt /dev/disk/... crypt_disks plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
Esto le dice a update-initramfs que quiero tener estas entradas de crypttab montadas en initramfs. Revisé mi crypttab ejecutando
cryptdisks_start part1_crypt
cryptdisks_start part2_crypt
Tenga en cuenta que mis discos de incursión son simples dm-crypt. Esto significaba que no podía usar el método de archivo de claves luks que soluciona el error de secuencia de comandos de systemd. Para dm-crypt sin formato, tendría que almacenar la frase de contraseña en texto sin formato.
El paquete keyutils debe instalarse y los discos cifrados deben montarse antes de update-initramfs se ejecuta; de lo contrario arrojará errores. Tuve que buscar las siguientes líneas cuando se creó mi initramfs:
update-initramfs -u -v | grep 'keyctl'
que mostraba los siguientes dos archivos:
/bin/keyctl
cryptkeyctl
siendo agregado a initramfs.
Finalmente, tuve que deshabilitar systemd manejando mi crypttab, para lidiar con el error mencionado anteriormente:systemd no admite la opción keyscript en crypttab. Para esto, agregué la opción kernel
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"
a /etc/default/grub y ejecutó update-grub . systemd ahora ignora crypttab y todas las particiones cifradas se cargan en initramfs.
Debido a que tengo una partición raíz cifrada, cryptroot no parece almacenar en caché mi clave. Esto significa que tengo que ingresar mi contraseña dos veces; uno para la partición raíz y una vez para mi matriz raid.