LUKSに慣れていないということから始めましょう。 LVMを使用して、または使用せずに、キースクリプトを使用してLUKSを何度も設定しました。ここで実際に何が起こっているのか分かりません。暗号化された単一のパーティションを持つシステムがあります。私のドライブは次のように構成されています。
#lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 128G 0 disk └─sda18:1 0 128G 0 part ├─vg0-root253:1 0 20G 0 lvm / ├─vg0-secure253:6 0 100M 0 lvm │└─secure253:7 0 98M 0 crypt /root/secure └─vg0-swap253:4 0 1G 0 lvm [SWAP]
/etc/crypttab
ファイルは次のようになります
#ここでは、LVへのパスが変更されないため、UUIDは不要です。 secure/dev/vg0/secure none luks、keyscript =/lib/cryptsetup/scripts/insecure
/lib/cryptsetup/scripts/insecure
ファイルは実行可能で、次のようになります
#!/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"
Crypttabを設定してkeyscriptファイルを配置した後、update-initramfs -k all -u
を何度も実行しました。
私の知る限り、スクリプトファイルはinitrd.imgファイルにもコピーされていません。 考えてみると、ルートパーティションは暗号化されておらず、そこからスクリプトファイルに簡単にアクセスできるため、initrd.imgファイルにコピーされるとは思いません。
再起動すると、システムはcrypttabからレコードを確認し、キースクリプトを使用してLUKSパーティションをロック解除するのではなく、パスワード(私の場合、唯一のキーはランダムビットでいっぱいのキーファイルであるため実際には存在しません)を要求します。 LVMからLUKSを取り出してsda2に配置してみましたが、結果は同じでした。 cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)"
はチャームのように機能し、LUKSパーティションを復号化するため、キースクリプトが機能することも知っています。
Ubuntu 16.04.2とUbuntu Mate 16.04.2でこれを試しましたが、同じ結果になりました。以前に問題なくキースクリプトを使用したことがあります。唯一の違いは、過去にmy /パーティションが常に暗号化されていたことです。誰もが光を放つことができれば、感謝します。このシステムのクローンを作成する予定があるため、非常に小さな暗号化されたパーティションのみが必要であり、暗号化された/パーティション全体でクローンを作成したくありません。
更新2017-04-26
ログを掘り下げてみると、意味のない次のエラーのある行が見つかりました。 'keyscript =/path/to/script'がcrypttabの未知のオプションになるのはいつですか?
... systemd-cryptsetup [737]:不明な/ etc/crypttabオプション 'keyscript =/lib/cryptsetup/scripts/insecure'に遭遇しました。無視します。
キックのために、私はキースクリプトオプションを削除してキーファイルを使用しようとしましたが、すべてうまくいきました!実際、keyfile-offsetのような他のオプションを試しましたが、それらも機能します。したがって、問題はkeyscriptオプションのどこかにあります。誰にも理由はありますか?
/ etc/crypttabのオプション「initramfs」を試してください( https://unix.stackexchange.com/a/447676/356711 による)。 /etc/crypttab
は次のようになります。
# 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
ルートfsがLVMコンテナにあることが問題になる可能性があることに注意してください。この問題は、上記のリンク記事にも記載されています。「しかし、これは現在、(信頼できる)ルートデバイスがLVMにない場合にのみ機能します。」幸いなことに、回避策のようです供給される。
私のシステムは次のようになります。
$ 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]
...そして、次の/etc/crypttab
は復号マジックを行いますキースクリプト(!)を使用 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
提供されたキースクリプトを使用したsdc2_crypt
の復号化は、without initramfsオプションで機能することに注意してください(ルートfsが含まれているため、initramfsブートフェーズで自動的に考慮されるため)。 md1_crypt
は、initramfsオプションを追加した後、initramfsブートフェーズ中に(つまり、crypttabエントリに応じたキースクリプトを使用して)既に復号化されました。 「systemd cryptsetup」はオプションkeyscriptをサポートしていないため、systemdブートフェーズ中のmd1_cryptのその後の復号化は、crypttabで指定されたkeyscriptでは動作しません。 https://github.com/systemd/systemd/pullを参照/ 3007 。