단일 비밀번호를 사용하여 부팅 시 여러 암호화된 디스크 잠금 해제

Question 1

Debian 기반 배포판:

Debian과 Ubuntu는 비밀번호 캐싱 스크립트를 제공합니다.복호화 키 제어그리고비밀번호 설정팩.

복호화 키 제어이 스크립트는 암호화된 여러 LUKS 대상에 대해 동일한 비밀번호를 제공하므로 비밀번호를 여러 번 입력할 수 없습니다. 다음에서 활성화할 수 있습니다.비밀번호 테이블옵션이 있습니다 keyscript=decrypt_keyctl. 동일한 식별자를 가진 대상에는 동일한 비밀번호가 사용됩니다.주요 파일 필드. 시작 시 비밀번호는 식별자당 한 번씩 묻습니다.

한 가지 예비밀번호 테이블:

<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

업데이트됨비밀번호 테이블, 변경 사항을 적용하려면 initramfs도 업데이트해야 합니다. 사용update-initramfs -u.

decrypt_keyctl의 전체 추가 정보 파일은 다음 위치에 있습니다./usr/share/doc/cryptsetup/README.keyctl

배포판이 제공되지 않음복호화 키 제어스크립트:

만약에복호화 키 제어귀하의 배포판은 암호화된 루트 파일 시스템의 키 파일을 사용하여 장치를 잠금 해제하는 기능을 제공하지 않습니다. 다른 암호화된 장치보다 먼저 루트 파일 시스템을 잠금 해제하고 마운트할 수 있는 경우.

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>

구성비밀번호 테이블키 파일을 사용하세요. 장치는 다음에 나열된 것과 동일한 순서로 잠금 해제되므로 첫 번째 줄은 루트 장치여야 합니다.비밀번호 테이블. 중요한 파일에는 절대 경로를 사용하십시오.
```
 <target>      <source>         <keyfile>                  <options>
 root_crypt    /dev/disk/...    none                       luks
 part1_crypt   /dev/disk/...    <path to key file>         luks
```

Answer

Debian 기반 배포판:

Debian과 Ubuntu는 비밀번호 캐싱 스크립트를 제공합니다.복호화 키 제어그리고비밀번호 설정팩.

복호화 키 제어이 스크립트는 암호화된 여러 LUKS 대상에 대해 동일한 비밀번호를 제공하므로 비밀번호를 여러 번 입력할 수 없습니다. 다음에서 활성화할 수 있습니다.비밀번호 테이블옵션이 있습니다 keyscript=decrypt_keyctl. 동일한 식별자를 가진 대상에는 동일한 비밀번호가 사용됩니다.주요 파일 필드. 시작 시 비밀번호는 식별자당 한 번씩 묻습니다.

한 가지 예비밀번호 테이블:

<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

업데이트됨비밀번호 테이블, 변경 사항을 적용하려면 initramfs도 업데이트해야 합니다. 사용update-initramfs -u.

decrypt_keyctl의 전체 추가 정보 파일은 다음 위치에 있습니다./usr/share/doc/cryptsetup/README.keyctl

배포판이 제공되지 않음복호화 키 제어스크립트:

만약에복호화 키 제어귀하의 배포판은 암호화된 루트 파일 시스템의 키 파일을 사용하여 장치를 잠금 해제하는 기능을 제공하지 않습니다. 다른 암호화된 장치보다 먼저 루트 파일 시스템을 잠금 해제하고 마운트할 수 있는 경우.

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>

구성비밀번호 테이블키 파일을 사용하세요. 장치는 다음에 나열된 것과 동일한 순서로 잠금 해제되므로 첫 번째 줄은 루트 장치여야 합니다.비밀번호 테이블. 중요한 파일에는 절대 경로를 사용하십시오.
```
 <target>      <source>         <keyfile>                  <options>
 root_crypt    /dev/disk/...    none                       luks
 part1_crypt   /dev/disk/...    <path to key file>         luks
```

Question 2

/lib/cryptsetup/scripts/decrypt_derived또 다른 옵션은 Debian/Ubuntu의 cryptsetup의 일부인 스크립트를 사용하는 것입니다 .

캐시 키 대신 한 디스크의 볼륨 키를 두 번째 디스크의 추가 비밀번호로 사용할 수 있습니다. 이를 위해서는 두 번째(및 세 번째 등) 암호화된 디스크에 두 번째 비밀번호를 추가해야 하지만 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옵션은 crypttabDebian의 원래 cryptsetup 도구로 처리할 때만 작동하며, systemd 재구현에서는 현재 이를 지원하지 않습니다. 시스템이 systemd(대부분의 시스템)를 사용하는 경우 initramfssystemd가 시작되기 전에 cryptsetup 도구를 통해 initrd에서 강제로 처리하도록 선택 해야 합니다 .

기반으로https://unix.stackexchange.com/a/32551/50793

Answer

/lib/cryptsetup/scripts/decrypt_derived또 다른 옵션은 Debian/Ubuntu의 cryptsetup의 일부인 스크립트를 사용하는 것입니다 .

캐시 키 대신 한 디스크의 볼륨 키를 두 번째 디스크의 추가 비밀번호로 사용할 수 있습니다. 이를 위해서는 두 번째(및 세 번째 등) 암호화된 디스크에 두 번째 비밀번호를 추가해야 하지만 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옵션은 crypttabDebian의 원래 cryptsetup 도구로 처리할 때만 작동하며, systemd 재구현에서는 현재 이를 지원하지 않습니다. 시스템이 systemd(대부분의 시스템)를 사용하는 경우 initramfssystemd가 시작되기 전에 cryptsetup 도구를 통해 initrd에서 강제로 처리하도록 선택 해야 합니다 .

기반으로https://unix.stackexchange.com/a/32551/50793

Question 3

위의 @sebasth가 언급한 오류를 고려하면 이것이 데비안에 대한 해결 방법입니다.

내 설정은 약간 다릅니다. 암호화된 루트 파티션과 여러 개의 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

이는 update-initramfs에게 이러한 crypttab 항목이 initramfs에 설치되기를 원한다는 것을 알려줍니다. 다음을 실행하여 crypttab을 확인했습니다.

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

내 RAID 디스크는 일반 dm-crypt입니다. 이는 시스템 키스크립트 버그를 해결하는 luks keyfile 방법을 사용할 수 없음을 의미합니다. 일반 dm-crypt를 사용하면 비밀번호를 일반 텍스트로 저장해야 합니다.

update-initramfs실행하기 전에 keyutils 패키지를 설치하고 암호화된 디스크를 설치해야 합니다. 그렇지 않으면 오류가 발생합니다. initramfs가 빌드되면 다음 줄을 찾아야 합니다.

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

다음 두 파일이 표시됩니다.

/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가 내 키를 캐싱하지 않는 것 같습니다. 이는 비밀번호를 두 번 입력해야 함을 의미합니다. 하나는 루트 파티션용이고 다른 하나는 RAID 어레이용입니다.

Answer

위의 @sebasth가 언급한 오류를 고려하면 이것이 데비안에 대한 해결 방법입니다.

내 설정은 약간 다릅니다. 암호화된 루트 파티션과 여러 개의 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

이는 update-initramfs에게 이러한 crypttab 항목이 initramfs에 설치되기를 원한다는 것을 알려줍니다. 다음을 실행하여 crypttab을 확인했습니다.

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

내 RAID 디스크는 일반 dm-crypt입니다. 이는 시스템 키스크립트 버그를 해결하는 luks keyfile 방법을 사용할 수 없음을 의미합니다. 일반 dm-crypt를 사용하면 비밀번호를 일반 텍스트로 저장해야 합니다.

update-initramfs실행하기 전에 keyutils 패키지를 설치하고 암호화된 디스크를 설치해야 합니다. 그렇지 않으면 오류가 발생합니다. initramfs가 빌드되면 다음 줄을 찾아야 합니다.

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

다음 두 파일이 표시됩니다.

/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가 내 키를 캐싱하지 않는 것 같습니다. 이는 비밀번호를 두 번 입력해야 함을 의미합니다. 하나는 루트 파티션용이고 다른 하나는 RAID 어레이용입니다.

Question 4

누군가에게 도움이 될 경우를 대비해 현재 대부분의 시스템 기반 시스템에서 이런 일이 발생해야 합니다.

Plymouth가 포함된 Fedora에서는 이 동작이 기본적으로 자동으로 발생합니다.

    * The "ask-password" framework used to query for LUKS harddisk
      passwords or SSL passwords during boot gained support for
      caching passwords in the kernel keyring, if it is
      available. This makes sure that the user only has to type in
      a passphrase once if there are multiple objects to unlock
      with the same one. Previously, such password caching was
      available only when Plymouth was used; this moves the
      caching logic into the systemd codebase itself. The
      "systemd-ask-password" utility gained a new --keyname=
      switch to control which kernel keyring key to use for
      caching a password in. This functionality is also useful for
      enabling display managers such as gdm to automatically
      unlock the user's GNOME keyring if its passphrase, the
      user's password and the harddisk password are the same, if
      gdm-autologin is used.

https://lists.freedesktop.org/archives/systemd-devel/2015-October/034509.html

Answer

누군가에게 도움이 될 경우를 대비해 현재 대부분의 시스템 기반 시스템에서 이런 일이 발생해야 합니다.

Plymouth가 포함된 Fedora에서는 이 동작이 기본적으로 자동으로 발생합니다.

    * The "ask-password" framework used to query for LUKS harddisk
      passwords or SSL passwords during boot gained support for
      caching passwords in the kernel keyring, if it is
      available. This makes sure that the user only has to type in
      a passphrase once if there are multiple objects to unlock
      with the same one. Previously, such password caching was
      available only when Plymouth was used; this moves the
      caching logic into the systemd codebase itself. The
      "systemd-ask-password" utility gained a new --keyname=
      switch to control which kernel keyring key to use for
      caching a password in. This functionality is also useful for
      enabling display managers such as gdm to automatically
      unlock the user's GNOME keyring if its passphrase, the
      user's password and the harddisk password are the same, if
      gdm-autologin is used.

https://lists.freedesktop.org/archives/systemd-devel/2015-October/034509.html

단일 비밀번호를 사용하여 부팅 시 여러 암호화된 디스크 잠금 해제

답변1

Debian 기반 배포판:

배포판이 제공되지 않음복호화 키 제어스크립트:

답변2

답변3

답변4

관련 정보