私のマシンには、システムをインストールしたSSDと、大容量ファイルや使用頻度の低いファイルのストレージとして使用するHDDがあります。どちらも暗号化されていますが、同じパスフレーズを使用することにしました。 SSDは/
に、HDDは/usr/hdd
にマウントされます(個々のユーザーはそれぞれにディレクトリを持ち、ホームディレクトリから好きなようにシンボリックリンクできます)。
システムが起動すると、すぐにSSDのパスフレーズが要求され、数秒後にHDDのパスフレーズが要求されます(自動マウントされます)。 両方のパスフレーズが同じであるとすると、システムが一度だけ尋ねるように設定する方法はありますか?
DebianおよびUbuntuは、パスワードキャッシングスクリプトdecrypt_keyctlを cryptsetup パッケージとともに出荷しています。
decrypt_keyctlスクリプトは、複数の暗号化されたLUKSターゲットに同じパスワードを提供し、何度も入力する手間を省きます。 crypttab でkeyscript=decrypt_keyctl
オプションを使用して有効にできます。 keyfileフィールドに同じ識別子を持つターゲットには同じパスワードが使用されます。各識別子の起動時パスワードは1回尋ねられます。
例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
decrypt_keyctl
スクリプトはkeyutils
パッケージに依存します(これは推奨されるだけなので、必ずしもインストールされる必要はありません)。
cryptabを更新したら、変更を適用するためにinitramfsも更新する必要があります。 update-initramfs -u
を使用します。
decrypt_keyctlの完全なreadmeは/usr/share/doc/cryptsetup/README.keyctl
にあります
残念ながら、これは現在systemd initを使用しているDebianシステムでは a bug(他のinitシステムは影響を受けません)。 Debian crypttab man page は、initramfs
オプションを使用してブートのinitramfsステージで処理を強制する回避策として提案しています。
decrypt_keyctrlがディストリビューションで提供されていない場合、デバイスは、暗号化されたルートファイルシステムのキーファイルを使用してロック解除できます。これは、ルートファイルシステムを他の暗号化されたデバイスの前にロック解除してマウントできる場合です。
LUKSは複数のキースロットをサポートしています。これにより、キーファイルが利用できない/紛失した場合に、パスワードを使用してデバイスをロック解除できます。
ランダムなデータでキーを生成し、その権限を所有者が読み取り可能に設定して、漏洩を回避します。キーファイルは、最初にロック解除されたルートパーティション上にある必要があることに注意してください。
dd if=/dev/urandom of=<path to key file> bs=1024 count=1
chmod u=rw,g=,o= <path to key file>
LUKSデバイスにキーを追加します
cryptsetup luksAddKey <path to encrypted device> <path to key file>
鍵ファイルを使用するようにcrypttabを構成します。 crypttabにリストされているのと同じ順序でデバイスがロック解除されるため、最初の行はルートデバイスである必要があります。キーファイルには絶対パスを使用します。
<target> <source> <keyfile> <options>
root_crypt /dev/disk/... none luks
part1_crypt /dev/disk/... <path to key file> luks
もう1つのオプションは、Debian/Ubuntuのcryptsetupの一部でもある/lib/cryptsetup/scripts/decrypt_derived
スクリプトを使用することです。
キーをキャッシュする代わりに、1つのディスクのボリュームキーを2番目のディスクの追加パスワードとして使用します。これには2番目(および3番目など)の暗号化されたディスクに2番目のパスワードを追加する必要がありますが、LUKSはそれをサポートしています。したがって、このソリューションは、複数の暗号化されたディスクが同じパスワードを使用しない場合にも機能します。
Sda6cryptからsda5にキーを追加する例:
Sda5の追加パスワードとしてsda6cryptのボリュームキーを追加します。
mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo
/etc/crypttab
でsda5cryptが自動的にロック解除されるように設定します
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
これは、名前付きパイプ(fifo
)を使用してキーを渡し、ボリュームキーをディスク上の一時ファイルに保存する必要がないようにします。
keyscript
オプションは、crypttab
がDebianのオリジナルのcryptsetupツールで処理された場合にのみ機能します。systemdの再実装では現在サポートされていません。システムがsystemd(ほとんどのシステム)を使用している場合、initramfs
オプションを使用して、systemdが起動する前に、cryptsetupツールによってinitrdで処理を強制的に実行する必要があります。
上記の@sebasthで参照されているバグを考慮して、debianでの私の回避策を以下に示します。
私のセットアップは少し異なります。暗号化されたルートパーティションとレイドディスクの束があります。私にとっては、crypttabにinitramfsオプションを追加する必要がありました。
<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
これは、これらのcrypttabエントリをinitramfsにマウントさせたいことをupdate-initramfsに伝えます。私はcrypttabを実行してチェックしました
cryptdisks_start part1_crypt
cryptdisks_start part2_crypt
私のRAIDディスクはプレーンなdm-cryptであることに注意してください。これは、systemdキースクリプトのバグを回避するluksキーファイルメソッドを使用できないことを意味しました。プレーンなdm-cryptの場合、パスフレーズをプレーンテキストで保存する必要があります。
暗号化されたディスクは、update-initramfs
を実行する前にマウントする必要があります。そうしないと、エラーがスローされます。 initramfsがビルドされたとき、次の行を探す必要がありました。
update-initramfs -k -u -v | grep 'keyctl'
次の2つのファイルを示しています。
/bin/keyctl
cryptkeyctl
initramfsに追加されます。
最後に、上で参照したバグに対処するために、cryptdを処理するsystemdを無効にする必要がありました。systemdは、crypttabのkeyscriptオプションをサポートしていません。このため、私はカーネルオプションを追加しました
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"
/ etc/default/grubに移動してupdate-grub
を実行します。 systemdはcrypttabを無視するようになり、暗号化されたすべてのパーティションがinitramfsにロードされます。
暗号化されたルートパーティションを持っているため、cryptrootがキーをキャッシュしていないようです。つまり、パスワードを2回入力する必要があります。 1つはルートパーティション用、もう1つはRAIDアレイ用です。