Distribusi berbasis Debian:
Debian dan Ubuntu mengirimkan skrip caching kata sandi decrypt_keyctl dengan cryptsetup paket.
decrypt_keyctl skrip memberikan kata sandi yang sama ke beberapa target LUKS terenkripsi, sehingga Anda tidak perlu mengetiknya berkali-kali. Ini dapat diaktifkan di crypttab dengan keyscript=decrypt_keyctl pilihan. Kata sandi yang sama digunakan untuk target yang memiliki pengenal yang sama di bidang keyfile . Kata sandi saat boot untuk setiap pengidentifikasi diminta satu kali.
Contoh 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 script tergantung pada keyutils paket (yang hanya disarankan, dan karena itu belum tentu diinstal).
Setelah Anda memperbarui cryptab Anda , Anda juga harus memperbarui initramfs untuk menerapkan perubahan. Gunakan update-initramfs -u .
Readme lengkap untuk decrypt_keyctl terletak di /usr/share/doc/cryptsetup/README.keyctl
Sayangnya, saat ini tidak bekerja pada sistem Debian menggunakan systemd init karena bug (sistem init lain seharusnya tidak terpengaruh). Dengan bug ini Anda dimintai kata sandi untuk kedua kalinya oleh systemd, sehingga tidak mungkin untuk membuka kunci dari jarak jauh melalui ssh. halaman manual crypttab Debian menyarankan sebagai solusi untuk menggunakan initramfs opsi untuk memaksa pemrosesan dalam tahap booting initramfs. Jadi untuk menghindari bug ini contoh untuk /etc/crypttab di Debian
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks luks,initramfs,keyscript=decrypt_keyctl
part2_crypt /dev/disk/... crypt_disks luks,initramfs,keyscript=decrypt_keyctl
Distribusi yang tidak menyediakan decrypt_keyctl skrip:
Jika decrypt_keyctrl tidak disediakan oleh distribusi Anda, perangkat dapat dibuka kuncinya menggunakan keyfile dalam sistem file root terenkripsi. Ini ketika sistem file root dapat dibuka dan dipasang sebelum perangkat terenkripsi lainnya.
LUKS mendukung banyak slot kunci. Ini memungkinkan Anda untuk membuka kunci perangkat menggunakan kata sandi jika file kunci tidak tersedia/hilang.
-
Hasilkan kunci dengan data acak dan atur izinnya agar hanya dapat dibaca pemilik untuk menghindari kebocorannya. Perhatikan bahwa file kunci harus berada di partisi root yang dibuka kuncinya terlebih dahulu.
dd if=/dev/urandom of=<path to key file> bs=1024 count=1 chmod u=rw,g=,o= <path to key file> -
Tambahkan kunci ke perangkat LUKS Anda
cryptsetup luksAddKey <path to encrypted device> <path to key file> -
Konfigurasikan crypttab untuk menggunakan file kunci. Baris pertama haruslah perangkat root, karena perangkat dibuka kuncinya dengan urutan yang sama seperti yang tercantum di crypttab . Gunakan jalur absolut untuk file kunci.
<target> <source> <keyfile> <options> root_crypt /dev/disk/... none luks part1_crypt /dev/disk/... <path to key file> luks
Pilihan lainnya adalah menggunakan /lib/cryptsetup/scripts/decrypt_derived skrip, yang juga merupakan bagian dari cryptsetup di Debian/Ubuntu.
Alih-alih menyimpan kunci, Anda menggunakan tombol volume satu disk sebagai kata sandi tambahan untuk disk kedua. Ini membutuhkan penambahan kata sandi kedua ke disk terenkripsi kedua (dan ketiga, dll), tetapi LUKS mendukungnya. Oleh karena itu, solusi ini juga berfungsi jika beberapa disk terenkripsi Anda tidak menggunakan kata sandi yang sama.
Contoh untuk menambahkan kunci dari sda6crypt ke sda5:
Tambahkan kunci volume sda6crypt sebagai kata sandi tambahan untuk sda5:
mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo
Konfigurasikan sda5crypt untuk dibuka secara otomatis di /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
Ini menggunakan pipa bernama (fifo ) untuk meneruskan kunci agar tidak perlu menyimpan kunci volume dalam file sementara di disk.
keyscript opsi hanya berfungsi jika crypttab diproses oleh alat cryptsetup asli Debian, implementasi ulang systemd saat ini tidak mendukungnya. Jika sistem Anda menggunakan systemd (yang merupakan sebagian besar sistem), Anda memerlukan initramfs opsi untuk memaksa pemrosesan terjadi di initrd oleh alat cryptsetup, sebelum systemd dimulai.
Berdasarkan https://unix.stackexchange.com/a/32551/50793
Inilah solusi saya di debian, mengingat bug yang dirujuk di atas oleh @sebasth.
Pengaturan saya sedikit berbeda. Saya memiliki partisi root terenkripsi dan banyak disk serangan. Bagi saya, saya harus menambahkan opsi initramfs ke crypttab:
<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
Ini memberi tahu update-initramfs bahwa saya ingin entri crypttab ini terpasang di initramfs. Saya memeriksa crypttab saya dengan menjalankan
cryptdisks_start part1_crypt
cryptdisks_start part2_crypt
Perhatikan bahwa disk serangan saya adalah dm-crypt biasa. Ini berarti bahwa saya tidak dapat menggunakan metode luks keyfile yang bekerja di sekitar bug keyscript systemd. Untuk dm-crypt biasa, saya harus menyimpan frasa sandi dalam teks biasa.
Keyutils paket harus diinstal dan disk terenkripsi harus dipasang sebelum update-initramfs dijalankan; jika tidak maka akan menimbulkan kesalahan. Saya harus mencari baris berikut saat initramfs saya dibuat:
update-initramfs -u -v | grep 'keyctl'
yang menampilkan dua file berikut:
/bin/keyctl
cryptkeyctl
sedang ditambahkan ke initramfs.
Akhirnya, saya harus menonaktifkan systemd yang menangani crypttab saya, untuk menangani bug yang dirujuk di atas:systemd tidak mendukung opsi keyscript di crypttab. Untuk ini, saya menambahkan opsi kernel
GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"
ke /etc/default/grub dan menjalankan update-grub . systemd sekarang mengabaikan crypttab, dan semua partisi terenkripsi dimuat di initramfs.
Karena saya memiliki partisi root terenkripsi, cryptroot tampaknya tidak menyimpan kunci saya dalam cache. Ini berarti saya harus memasukkan kata sandi saya dua kali; satu untuk partisi root dan sekali untuk array serangan saya.