単一のパスフレーズを使用して、起動時に複数の暗号化されたディスクのロックを解除する

私のマシンにはSSDがあり、そこにシステムとHDDをインストールしました。これらは大容量ファイルや頻繁に使用しないファイルのストレージとして使用します。両方とも暗号化されていますが、私はそれらに同じパスフレーズを使用することを選択しました。SSDはにマウントされ/、HDD はにマウントされ/usr/hddます（個々のユーザーはそれぞれディレクトリを持ち、ホームディレクトリから好きなようにシンボリックリンクできます）。

システムが起動すると、すぐにSSDのパスフレーズを要求し、数秒後にHDDのパスフレーズを要求します（自動マウントされます）。両方のパスフレーズが同じ場合、一度だけ尋ねるようにシステムを構成する方法はありますか？

linux disk-encryption cryptsetup

— 倍増
ソース

expectシステムに実行させる代わりに、ディスクをマウントするために呼び出されるスクリプトなどを記述することもできます。代わりに、システムはスクリプトを呼び出してパスワードを要求し、保存し、各マウント操作に提供します。

— h3rrmiller

私があなたの考えを正しく理解していれば、それはSSDに適用できません。それはシステムがそこから起動するからです。しかし、HDDのパスフレーズを個別に入力する必要があるため、意味がなくなります。またはいいえ？

— -19

を使用/etc/crypttab して、2番目のドライブのロックを解除できます。

— jasonwryan

@jasonwryanそれが答えに展開できるなら、答えはコメントではなく答えとして投稿されるべきです。

— デロバート

@derobertには、良い答えを書く時間も、傾向もない人もいます。

— jasonwryan

回答:

Debianベースのディストリビューション：

DebianとUbuntuは、cryptsetupパッケージにパスワードキャッシングスクリプトdecrypt_keyctlを同梱しています。

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

cryptabを更新したら、変更を適用するためにinitramfsも更新する必要があります。を使用しupdate-initramfs -uます。

decrypt_keyctlの完全なreadmeは次の場所にあります。 /usr/share/doc/cryptsetup/README.keyctl

残念ながら、これはバグのためにsystemd initを使用するDebianシステムでは現在動作しません（他のinitシステムは影響を受けないはずです）。Debian crypttabのmanページはinitramfs、ブートのinitramfsステージで処理を強制するオプションを使用する回避策として提案しています。

decrypt_keyctlスクリプトを提供しないディストリビューション：

ディストリビューションで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
```

— セバスト
ソース

READMEの最初の行から、非常に有望に見えます、ありがとう。明日、これを確認します（今すぐ再起動したくない）。

— -19:

残念ながら、それは機能しません（変更なし）。を参照してcrypttabください（UUID=システムインストーラーによって作成されたものには触れませんでしたが、それは問題ではないと思います/var/log/syslog）およびの結果エントリ。エラーは一種の理解可能ですが、私はそれらについて何をすべきか分かりません。ファイル/lib/cryptsetup/scripts/decrypt_keyctlが存在するので、不明なオプションについて文句を言う理由がわかりません。私は...私は何の説明のどこかを見ていない、何のキーファイルとして指定することは考えてもを持っていない

— doublep

decrypt_keyctlがinitramfsに含まれることを確認しましたか？image：を更新するときに詳細オプションを使用してチェックしupdate-initramfs -u -k $(uname -r) -vますAdding binary /lib/cryptsetup/scripts/decrypt_keyctl。出力されます。

— セバスト

initramfsが何が含まれているか確認するには：lsinitramfs /boot/initrd.img-$(uname -r)

— sebasth

ええと、申し訳ありませんが、今私は何にもっと注意を払っていることをupdate-initramfs言った、私はこれに気づきました：E: /usr/share/initramfs-tools/hooks/cryptkeyctl failed with return 1.。少しグーグルで調べたところ、おそらくkeyutilsパッケージが必要であることがわかりました（実際にはインストールされていませんでした）。今update-initramfs成功し、lsinitramfs言及していdecrypt_keytlsます。次回のブート後に更新されます（おそらく明日）。

— 倍増

@sebasthによって上記で参照されたバグを与えられたdebianの私の回避策はここにあります。

私のセットアップは少し異なります。暗号化されたルートパーティションと多数のRAIDディスクがあります。私にとっては、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 keyscriptのバグを回避するluks keyfileメソッドを使用できなかったことを意味します。プレーンdm-cryptの場合、パスフレーズをプレーンテキストで保存する必要があります。

暗号化されたディスクupdate-initramfsは、実行する前にマウントする必要があります。そうしないと、エラーがスローされます。initramfsが作成されたとき、次の行を探す必要がありました。

update-initramfs -k -u -v | grep 'keyctl'

次の2つのファイルが表示されました。

/bin/keyctl
cryptkeyctl

initramfsに追加されます。

最後に、上記のバグに対処するために、crypttabを処理する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アレイ用です。

— user128063
ソース

別のオプションは/lib/cryptsetup/scripts/decrypt_derived、Debian / Ubuntuのcryptsetupの一部でもあるスクリプトを使用することです。

キーをキャッシュする代わりに、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

で自動的にロック解除されるようにsda5cryptを構成する /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

これは、名前付きパイプ（fifo）を使用してキーを渡し、ディスク上の一時ファイルにボリュームキーを保存する必要がないようにします。

このkeyscriptオプションcrypttabは、Debianのオリジナルのcryptsetupツールで処理された場合にのみ機能します。systemdの再実装では現在サポートされていません。システムがsystemd（ほとんどのシステム）を使用している場合、initramfssystemdが起動する前に、cryptsetupツールによってinitrdで処理を強制するオプションが必要です。

/unix//a/32551/50793に基づく

— ジャンカニス
ソース

これは美しい解決策だと言わざるを得ない。Debian10のバスターで問題なく動作した！

— ヤヌス