What is the correct way to use key file LUKS authorization?
Before filing new bug reports i decided to try to get support on my
situation here. Sorry for my english (it may sound frustrating) in
advance, feel free to ask about additional details and thanks!! Formatting
questions is too complicated, sorry lol, so here is the text version just
in case http://paste.ubuntu.com/5967000/
The configuration is as simple as that (no lvm, 2 hdds, no raid):
-> /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/sda2_crypt / ext4 errors=remount-ro 0 1
# /boot was on /dev/sdc1 during installation
UUID=664ca8af-34b8-4012-ba27-9f48044b6e4e /boot reiserfs notail 0 2
/dev/mapper/sdb1_crypt /media/storage ext4 noatime,sync 0 2
/dev/mapper/sda1_crypt none swap sw 0 0
EOF
-> /etc/crypttab
sda1_crypt /dev/sda1 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sda2_crypt UUID=bc4ff5ca-d27a-423b-9ab1-806b64556ace /boot/key luks
sdb1_crypt UUID=85baac75-dae4-4807-98dd-65d17d0c66f4 /boot/key luks
EOF
/dev/sda2 and /dev/sdb1 have one&only Slot0 for /boot/key authorization,
which results in:
update-initramfs: Generating /boot/initrd.img-3.8.0-28-generic
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
and unbootable system.
However, having sda2 with the one&only Slot0 password authorization works
flawless meaning automount during boot via luks key file auth for
/dev/sdb1
-> /etc/crypttab
sda1_crypt /dev/sda1 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sda2_crypt UUID=bc4ff5ca-d27a-423b-9ab1-806b64556ace none luks
sdb1_crypt UUID=85baac75-dae4-4807-98dd-65d17d0c66f4 /boot/key luks
EOF
Getting support related to such configuration appeared to be not that
easy, so maybe it's not a bug, because atm i'm not sure about the next
moments:
1. Is it necessary to have a keyscript option in order to use luks
authorization based on a key file for drive with mount point on / (root
fs)?
The question appeared after looking at
/usr/share/initramfs-tools/hooks/cryptroot; reading the #13 from
https://answers.launchpad.net/ubuntu/+source/cryptsetup/+question/37176
and:
"However, if you wish to make use of more complex setups (such as
root]key]on]usb]memory), you can create a script which does all the
steps necessary to retrieve the key and then prints it to stdout." From
here /usr/share/doc/cryptsetup/README.initramfs.gz
2. I "can create" it or i "must" in order to mount rootfs using key file?
The situation is totally unclear for me, because:
Why i need a keyscript (if i need one) for / device, but not for my
/media/storage one? Taking in view my setup with key file for both on
removable /boot.
Why do i need the key script if it is clear that removable /boot media
with the key file is accessible due to the fact that /dev/sdb1 finally
comes as mounted luks-mapped device on it's mount point according to
/etc/fstab ?
If i don't need the keyscript, why i'm getting the warning from initramfs
hook which checks if i have one or not for mounting root device? (ending
up with unbootable system)
If above things are clearly defined , i have the last question: is this a
bug or feature? Because it used to work in my previous 12.04 setup as i'm
trying to make it work now on freshly installed 13.04, which means that
something was fixed leaving me like that or otherwise some feature(s) were
added.
Extra:
# If keyscript is set, the "key" is just an argument to the script
if [ "$key" != "none" ] && [ -z "$KEYSCRIPT" ]; then
echo "cryptsetup: WARNING: target $target uses a key file, skipped" >&2
return 1
fi
}
Does it exist just to make sure i'll get useless warning according to the
fact it's != none? Sorry for being so noob.
No comments:
Post a Comment