LUKS-Keyscript wird ignoriert ... fragt nach dem Passwort

Lassen Sie mich zunächst sagen, dass ich für LUKS nicht neu bin. Ich habe LUKS mit Keyskripten mehrfach mit und ohne LVM eingerichtet. Ich bin mir allerdings nicht sicher, was hier eigentlich los ist. Ich habe ein System, das eine einzelne verschlüsselte Partition hat. Meine Fahrt ist wie folgt organisiert:

# lsblk

NAME MAJ: MIN RM GRÖSSE RO TYP MOUNTPOINT
sda 8: 0 0 128G 0 Festplatte  
└─sda1 8: 1 0 128G 0 Teil  
  ├─vg0-root 253: 1 0 20G 0 lvm /
  ├─vg0-Secure 253: 6 0 100M 0 lvm   
  │ └secure 253: 7 0 98M 0 crypt / root / Secure
  └─vg0-Swap 253: 4 0 1G 0 lvm [SWAP]

Meine /etc/crypttabDatei sieht ungefähr so ​​aus

# UUID ist hier nicht erforderlich, da sich der Pfad zum LV nicht ändert
sichere / dev / vg0 / sichere keine luks, keyscript = / lib / cryptsetup / scripts / unsicher

Meine /lib/cryptsetup/scripts/insecureDatei ist ausführbar und sieht ungefähr so ​​aus

#!/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"

Ich habe update-initramfs -k all -ueinige Male ausgeführt, nachdem ich crypttab konfiguriert und meine Keyscript-Datei eingerichtet habe.

Soweit ich das beurteilen kann, wird meine Skriptdatei nicht einmal in die Datei initrd.img kopiert. Jetzt, wo ich darüber nachdenke, glaube ich nicht, dass es in die Datei initrd.img kopiert wird, da die Root-Partition nicht verschlüsselt ist und die Skriptdatei von dort aus leicht zugänglich sein sollte.

Beim Neustart sieht das System den Datensatz von crypttab und fragt nach einem Kennwort (das in meinem Fall nicht vorhanden ist, da der einzige Schlüssel eine Schlüsseldatei voller zufälliger Bits ist), anstatt das Schlüsselskript zum Entsperren der LUKS-Partition zu verwenden. Ich habe versucht, LUKS aus dem LVM herauszunehmen und auf sda2 zu setzen, und die Ergebnisse waren die gleichen. Ich weiß auch, dass das Keyscript funktioniert, weil es cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)"wie ein Zauber wirkt und meine LUKS-Partition entschlüsselt.

Ich habe dies in Ubuntu 16.04.2 und Ubuntu Mate 16.04.2 mit den gleichen Ergebnissen versucht. Ich habe zuvor ohne Probleme Keyskripte verwendet. Der einzige Unterschied war, dass meine / Partition in der Vergangenheit immer verschlüsselt war. Wenn jemand etwas Licht ins Dunkel bringen kann, würde ich es schätzen. Ich möchte nur eine sehr kleine verschlüsselte Partition, da ich vorhabe, dieses System zu klonen, und ich möchte es nicht mit der gesamten / partition verschlüsselten Partition klonen.

UPDATE 26.04.2017

Beim Durchsuchen von Protokollen habe ich eine Zeile mit dem folgenden Fehler gefunden, die keinen Sinn ergibt. Seit wann ist 'keyscript = / path / to / script' eine unbekannte Option für crypttab?

... systemd-cryptsetup [737]: Unbekannte / etc / crypttab-Option 'keyscript = / lib / cryptsetup / scripts / unsicher' gefunden, ignoriert.

Nur zum Spaß habe ich versucht, die Keyscript-Option zu entfernen und eine Schlüsseldatei zu verwenden, und alles hat einfach funktioniert! Tatsächlich habe ich andere Optionen wie Keyfile-Offset ausprobiert, und sie funktionieren auch. Daher liegt das Problem irgendwo bei der Keyscript-Option. Hat jemand eine Idee warum?

Probieren Sie die Option "initramfs" in Ihrer / etc / crypttab aus (gemäß /unix//a/447676/356711 ). Ihr /etc/crypttabwürde dann so aussehen:

# 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

Bitte beachten Sie, dass es möglicherweise ein Problem ist, dass sich Ihr Root-Fs in einem LVM-Container befindet. Dieses Problem wird auch in dem oben verlinkten Artikel erwähnt: " Dies funktioniert derzeit jedoch (zuverlässig) nur, wenn sich das Root-Gerät nicht in einem LVM befindet. " Glücklicherweise scheint eine Problemumgehung bereitgestellt zu werden.

Mein System sieht folgendermaßen aus:

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

... und das Folgende /etc/crypttabmacht die Entschlüsselungsmagie mit einem Keyscript (!) in 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

Beachten Sie, dass die Entschlüsselung sdc2_cryptmit dem bereitgestellten Keyscript ohne die Option initramfs funktioniert (da es das Root-fs enthält und daher in der Startphase von initramfs "automatisch" berücksichtigt wird). md1_cryptwurde erst während der Startphase von initramfs (und damit mit dem Keyscript gemäß dem Crypttab-Eintrag) entschlüsselt, nachdem ich die Option initramfs hinzugefügt hatte. Die spätere Entschlüsselung von md1_crypt während der Systemd-Startphase funktioniert nicht mit einem in crypttab angegebenen Keyscript, da das "systemd cryptsetup" das Optionsschlüsselskript nicht unterstützt (siehe https://github.com/systemd/systemd/pull/3007) .