LUKS anahtar kodu yok sayılıyor… şifre istiyor


10

LUKS için yeni olmadığımı söyleyerek başlayayım. LVM ile ve LVM olmadan çok sayıda anahtar komut dosyası içeren LUKS kurdum. Aslında burada neler olup bittiğinden emin değilim. Tek bir şifreli bölüm içeren bir sistemim var. Sürücüm aşağıdaki gibi düzenlenmiştir:

# lsblk

ADI MAJ: MIN RM BOYUTU RO TİPİ DAĞ NOKTASI
sda 8: 0 0 128G 0 disk  
1sda1 8: 1 0 128G 0 bölüm  
  ├─vg0-root 253: 1 0 20G 0 lvm /
  ├─vg0-güvenli 253: 6 0100M 0 lvm   
  Güvenli 253: 7 0 98M 0 crypt / root / secure
  └─vg0-takas 253: 4 0 1G 0 lvm [SWAP]

Benim /etc/crypttabdosya şuna benzer

# UUID burada gerekli değildir çünkü LV yolu değişmez
secure / dev / vg0 / secure hiçbiri luks, keyscript = / lib / cryptsetup / scriptler / güvensiz

Benim /lib/cryptsetup/scripts/insecuredosya çalıştırılabilir ve şuna benzer

#!/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"

update-initramfs -k all -uCrypttab'ı yapılandırdıktan ve benim keyscript dosyasını yerine koyduktan sonra birkaç kez çalıştırdım .

Bildiğim kadarıyla, komut dosyası benim initrd.img dosyasına bile kopyalanmıyor. Şimdi düşündüğüm için, kök bölümü şifrelenmediği ve komut dosyasına oradan kolayca erişilebilmesi gerektiğinden initrd.img dosyasına kopyalanacağını düşünmüyorum.

Sistem yeniden başlatıldıktan sonra sistem, crypttab'dan kaydı görür ve LUKS bölümünün kilidini açmak için anahtar komut dosyasını kullanmak yerine bir şifre ister (benim durumumda gerçekte mevcut değildir çünkü tek anahtar rastgele bitlerle dolu bir anahtar dosyasıdır). LUKS'u LVM'den çıkarmaya ve sda2'ye koymaya çalıştım ve sonuçlar aynıydı. Ayrıca, keyscript'in cryptsetup luksOpen /dev/vg0/secure secure -d - <<< "$(/lib/cryptsetup/scripts/insecure)"bir cazibe gibi çalıştığını ve LUKS bölümümün şifresini çözdüğünü biliyorum .

Bunu aynı sonuçlarla Ubuntu 16.04.2 ve Ubuntu Mate 16.04.2'de denedim. Daha önce hiç sorunsuz bir şekilde senaryoları kullandım. Tek fark geçmişte benim / bölümümün her zaman şifrelenmiş olmasıydı. Eğer biri ışık tutabilirse, bunu takdir ediyorum. Sadece çok küçük şifreli bir bölüm istiyorum çünkü bu sistemi klonlamayı planlıyorum ve tüm / bölüm şifreli olarak klonlamak istemiyorum.


GÜNCELLEME 2017-04-26

Günlükleri kazarken, şu hatayı içeren bir satır buldum, bu mantıklı değil. 'Keyscript = / path / to / script' ne zamandan beri crypttab için bilinmeyen bir seçenek?

... systemd-cryptsetup [737]: Bilinmeyen / etc / crypttab seçeneği 'keyscript = / lib / cryptsetup / scripts / güvensiz' ile karşılaştı, yok sayılıyor.

Sadece tekmeler için, keyscript seçeneğini kaldırmayı ve bir keyfile kullanmayı denedim ve hepsi işe yaradı! Aslında, keyfile-offset gibi diğer seçenekleri denedim ve onlar da çalışıyor. Bu nedenle, sorun bir yerde anahtar komut dosyası seçeneğiyle yatmaktadır. Neden herhangi bir fikri olan var mı?


3
Bence systemd senin sorunun. Systemd ve keyscript için hızlı bir google, burada systemd'de keyscript uygulamak için bir hata ve bir çekme isteği gösterir . İlk bağlantıdan bir çözüm bile var.
sergtech

Bu benim şüphe oldu yanı sıra benim sorunu kazmaya devam etti ve arama sonuçları çevrimiçi buldum. Burada bazı öneriler denedim , ancak komut dosyasının initrd içine nasıl alınacağından emin değilim.
b_laoshi

Yanıtlar:


3

/ Etc / crypttab (" https://unix.stackexchange.com/a/447676/356711" e göre ) "initramfs" seçeneğini deneyin . Sizin /etc/crypttabo zaman bu gibi görünecektir:

# 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

Kök fs'nizin bir LVM kapsayıcısında olması bir sorun olabileceğini lütfen unutmayın. Bu sorun, yukarıda bağlantılı makalede de belirtilmiştir: " Ancak bu şu anda (güvenilir bir şekilde) kök aygıt bir LVM'de değilse çalışır. " Neyse ki, bir geçici çözüm sağlanmış gibi görünüyor.

Sistemim şöyle görünüyor:

$ 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]

... ve aşağıdakiler Ubuntu 18.04.2 LTS'de bir anahtar koduyla (!)/etc/crypttab şifre çözme sihrini yapıyor :

$ 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_cryptSağlanan anahtar komut dosyası ile şifresinin initramfs seçeneği olmadan çalıştığını unutmayın (çünkü kök fs içerdiğinden ve bu nedenle initramfs önyükleme aşamasında "otomatik olarak" dikkate alınır). md1_cryptinitramfs seçeneğini ekledikten sonra yalnızca initramfs önyükleme aşamasında (ve böylece crypttab girişine göre anahtar komut dosyasıyla) zaten şifresi çözüldü. Md1_crypt komutunun sistemd önyükleme aşaması sırasında daha sonra çözülmesi, "systemd cryptsetup" seçenek anahtar komut dosyasını desteklemediğinden, crypttab'da verilen bir anahtar komut dosyası ile çalışmaz, bkz. Https://github.com/systemd/systemd/pull/3007 .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.