Tak, możesz to zrobić, uzyskując dostęp do klucza głównego podczas odszyfrowywania woluminu.
Szybkie i brudne dodanie nowego hasła:
device=/dev/sda5
volume_name=foo
cryptsetup luksAddKey $device --master-key-file <(dmsetup table --showkeys $volume_name | awk '{ print $5 }' | xxd -r -p)
device
i volume_name
powinny być odpowiednio ustawione.
volume_name
to nazwa odszyfrowanego woluminu, tego, w którym się widzisz /dev/mapper
.
Wyjaśnienie:
Woluminy LUKS szyfrują swoje dane za pomocą klucza głównego. Każde dodane hasło po prostu przechowuje kopię tego klucza głównego zaszyfrowaną tym hasłem. Jeśli więc masz klucz główny, wystarczy użyć go w nowym gnieździe na klucz.
Pozwala rozerwać powyższe polecenie.
$ dmsetup table --showkeys $volume_name
To zrzuca garść informacji o aktywnie odszyfrowanym woluminie. Dane wyjściowe wyglądają następująco:
0 200704 crypt aes-xts-plain64 53bb7da1f26e2a032cc9e70d6162980440bd69bb31cb64d2a4012362eeaad0ac 0 7:2 4096
Pole nr 5 to klucz główny.
$ dmsetup table --showkeys $volume_name | awk '{ print $5 }' | xxd -r -p
Nie pokażę wyniku tego, ponieważ są to dane binarne, ale to, co to robi, to pobrać klucz główny dla woluminu, a następnie przekształcić go w surowe dane binarne, które są potrzebne później.
$ cryptsetup luksAddKey $device --master-key-file <(...)
To mówi cryptsetup, aby dodał nowy klucz do woluminu. Zwykle ta czynność wymaga istniejącego klucza, jednak --master-key-file
informujemy, że chcemy zamiast tego użyć klucza głównego.
Jest <(...)
to podstawianie i przekierowywanie poleceń powłoki. Zasadniczo wykonuje wszystko w środku, wysyła dane wyjściowe do potoku, a następnie zastępuje <(...)
ścieżkę do tego potoku.
Tak więc całe polecenie jest tylko linijką, aby skondensować kilka operacji.