Se ignora el script de LUKS ... pide contraseña

Permítanme comenzar diciendo que no soy nuevo en LUKS. He configurado LUKS con guiones de teclado varias veces con y sin LVM. Sin embargo, no estoy seguro de lo que realmente está sucediendo aquí. Tengo un sistema que tiene una sola partición encriptada. Mi disco está organizado de la siguiente manera:

# lsblk

NOMBRE MAJ: MIN RM TAMAÑO RO TIPO MOUNTPOINT
sda 8: 0 0 128G 0 disco  
Dasda1 8: 1 0 128G 0 parte  
  ├─vg0-root 253: 1 0 20G 0 lvm /
  ├─vg0-secure 253: 6 0 100M 0 lvm   
  Cure └─secure 253: 7 0 98M 0 crypt / root / secure
  └─vg0-swap 253: 4 0 1G 0 lvm [SWAP]

Mi /etc/crypttabarchivo se ve así

# No se requiere UUID aquí ya que la ruta al LV no cambiará
secure / dev / vg0 / secure none luks, keyscript = / lib / cryptsetup / scripts / insecure

Mi /lib/cryptsetup/scripts/insecurearchivo es ejecutable y se ve así

#!/bin/sh
# My actual file looks somewhat different because it dumps the key file with dd.
# This accomplishes virtually the same thing though.

echo -n "my-encryption-password"

He corrido update-initramfs -k all -uvarias veces después de configurar crypttab y poner mi archivo de script en su lugar.

Por lo que puedo decir, mi archivo de script ni siquiera se está copiando en el archivo initrd.img. Ahora que lo pienso, no creo que se copie al archivo initrd.img ya que la partición raíz no está encriptada y el archivo de script debería ser fácilmente accesible desde allí.

Al reiniciar, el sistema ve el registro de la tabla de cifrado y solicita una contraseña (que en mi caso no existe porque la única clave es un archivo de claves lleno de bits aleatorios) en lugar de usar el script para desbloquear la partición LUKS. Intenté sacar LUKS del LVM y ponerlo en sda2, y los resultados fueron los mismos. También sé que el script funciona porque cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)"funciona de maravilla y descifra mi partición LUKS.

He intentado esto en Ubuntu 16.04.2 y Ubuntu Mate 16.04.2 con los mismos resultados. He usado claves antes sin ningún problema. La única diferencia era que, en el pasado, mi / partición siempre estaba encriptada. Si alguien puede arrojar algo de luz, lo agradecería. Solo quiero una partición cifrada muy pequeña porque planeo clonar este sistema, y ​​no quiero clonarlo con toda la partición / cifrada.

ACTUALIZACIÓN 2017-04-26

Al buscar en los registros, encontré una línea con el siguiente error que no tiene sentido. ¿Desde cuándo 'keyscript = / path / to / script' es una opción desconocida para crypttab?

... systemd-cryptsetup [737]: Se encontró una opción desconocida / etc / crypttab 'keyscript = / lib / cryptsetup / scripts / insecure', ignorando.

Solo por diversión, intenté eliminar la opción de script y usar un archivo de claves, ¡y todo funcionó! De hecho, probé otras opciones como keyfile-offset, y también funcionan. Por lo tanto, el problema radica en algún lugar con la opción de script. ¿Alguien tiene alguna idea de por qué?

Pruebe la opción "initramfs" en su / etc / crypttab (de acuerdo con /unix//a/447676/356711 ). Su /etc/crypttabtendría el siguiente aspecto:

# UUID is not required here since the path to the LV won't change
secure      /dev/vg0/secure       none      luks,keyscript=/lib/cryptsetup/scripts/insecure,initramfs

Tenga en cuenta que puede ser un problema que su raíz fs esté en un contenedor LVM. Este problema también se menciona en el artículo vinculado anteriormente: " Pero esto actualmente solo funciona (de manera confiable) si el dispositivo raíz no está en un LVM " . Afortunadamente, parece que se proporciona una solución alternativa.

Mi sistema se ve así:

$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931.5G  0 disk
└─sda1                          8:1    0 931.5G  0 part
  └─md1                         9:1    0 931.4G  0 raid1
    └─md1_crypt               253:3    0 931.4G  0 crypt
      └─raid_crypt_vg-data_lv 253:4    0 931.4G  0 lvm   /raid
sdb                             8:16   0 931.5G  0 disk
└─sdb1                          8:17   0 931.5G  0 part
  └─md1                         9:1    0 931.4G  0 raid1
    └─md1_crypt               253:3    0 931.4G  0 crypt
      └─raid_crypt_vg-data_lv 253:4    0 931.4G  0 lvm   /raid
sdc                             8:32   0 465.8G  0 disk
├─sdc1                          8:33   0   953M  0 part  /boot
└─sdc2                          8:34   0 464.8G  0 part
  └─sdc2_crypt                253:0    0 464.8G  0 crypt
    ├─system_crypt_vg-data_lv 253:1    0   447G  0 lvm   /
    └─system_crypt_vg-swap_lv 253:2    0  17.8G  0 lvm   [SWAP]

... y lo siguiente /etc/crypttabhace la magia de descifrado con un script de clave (!) en Ubuntu 18.04.2 LTS:

$ cat /etc/crypttab
# <target name> <source device>                           <key file> <options>
sdc2_crypt      UUID=[...]                                none       luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh
md1_crypt       /dev/md1                                  none       luks,discard,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh,initramfs

Tenga en cuenta que el descifrado de sdc2_cryptcon el script provisto funciona sin la opción initramfs (porque contiene la raíz fs y, por lo tanto, se considera "automáticamente" en la fase de arranque de initramfs). md1_cryptsolo se descifró durante la fase de arranque de initramfs (y, por lo tanto, con el script de claves de acuerdo con la entrada crypttab) después de agregar la opción initramfs. El descifrado posterior de md1_crypt durante la fase de arranque systemd no funciona con un script escrito en crypttab porque el "systemd cryptsetup" no es compatible con el script de opción, vea https://github.com/systemd/systemd/pull/3007 .