Very nice and easy solution, thanks :-) I just implemented this on my headless debian 13 server.
I am using LUKS/cryptsetup because I want to be able to simply bin my disks in case they are at the end of their life. But on the other hand I do not want to walk to the server and enter my passphrase every time it boots, so this solution is perfect for me.
The only changes I applied were:
* remove "-part1" from "for usbpartition in /dev/disk/by-id/usb-*-part1"
because my usb drive is named differently (I could have been more explicit on the name too but I'm too lazy)
* replaced vfat with ext4
- in the scripts mount command
- in the /etc/initramfs-tools/modules file
because my usb stick is formatted with ext4
I am using it for a headless boot on Debian12, with some modification.
- The argument in the third is just the UUID of the USB drive.
- It lets the script be called repeated number of times at 1s intervals, until the USB is visible. If not visible after 10 a monitor is required, and thereafter the user can either enter the usb and hit enter, or enter the password manually.
- It writes to log so if something goes wrong it can be view with journalctl.
Are you using a base install of Debian12?
The default service to handle the decryption is systemd-cryptsetup.
Which does not recognize the keyscript option, making me believe there is something else missing from this guide.
From the Debian crypttab(5) man page keyscript section:
" This option is specific to the Debian crypttab format. It's not supported by systemd.
WARNING: With systemd as init system, this option might be ignored. At the time this is written (December 2016), the systemd cryptsetup helper doesn't support the keyscript option to /etc/crypttab."
Hoping you faced the same issue and found the fix.
This actually works before systemd action takes place. At that time, the systemd log is not yet even started. That why this script uses `/dev/kmsg` for logging.
#!/bin/sh
# Function for logging
log_msg() {
local formatted=$(date '+%Y-%m-%d %H:%M:%S')
# during initramfs, cannot write to journal, must write to /dev/kmesg
echo "[${formatted}] luks-unlock: $1" >> /dev/kmsg
# use the following line for testing
#echo "luks-unlock: $1"
}
#!/bin/sh
# Function for logging
log_msg() {
local formatted=$(date '+%Y-%m-%d %H:%M:%S')
# during initramfs, cannot write to journal, must write to /dev/kmesg
echo "[${formatted}] luks-unlock: $1" >> /dev/kmsg
# use the following line for testing
#echo "luks-unlock: $1"
}
When systemd does kick in, it will prepend what has been written to `/dev/kmsg` to the systemd logfile. And systemd will also write a message complaining about the argument it doesn't understand (omitted from the logfile shown above, for simplicity), but that doesn't matter, because the disk is already unencrypted by that point.
So both native Debian initramfs and the systemd use similar but not identical protocols for unlocking. In my use case, using the native Debian initramfs setup which does not contain systemd, I must unlock the disk first during the UEFI process before systemd can even kick in.
In fact systemd does also provide an alternative to GRUB called "systemd-boot". It might be the case that using systemd-boot would allow the disk to become unlocked during the UEFI process. I don't know.
The system under consideration above is a headless system running Debian windowless server only, with a GPU plugged in for NN stuff.
In fact on my main non-headless system (from which I am writing this post) I do use systemd-boot instead of GRUB, but I never tried booting with a key on a USB stick, obviously because I want to keep my main PC secure.
Thanks for the blog post! It perfectly works for me on Ubuntu 22.04!
However, after updating to 24.04, the auto unlock seems to be no more working: at boot time, I need to press ENTER each time to unlock.
Has anyone observed the same issue ? Any idea on how to solve it ?
I've got only one encrypted partition with no subvolmes and my crypttab looks like this and I can't get further with this tutorial.
GNU nano 8.2 /etc/crypttab
# Configuration for encrypted block devices.
# See crypttab(5) for details.
# NOTE: Do not list your root (/) partition here, it must be set up
# beforehand by the initramfs (/etc/mkinitcpio.conf).
# <name> <device> <password> <options>
# home UUID=b8ad5c18-f445-495d-9095-c9ec4f9d2f37 /etc/mypassword1
# data1 /dev/sda3 /etc/mypassword2
# data2 /dev/sda5 /etc/cryptfs.key
# swap /dev/sdx4 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256
# vol /dev/sdb7 none
I am having trouble getting this to work. The only step I skipped was 10) because I am using Debian 12. I've verified all steps several times. I suspect that the USB key doesn't get mounted, e.g. when I boot with the key inserted or not, I am getting prompted to insert the key, then I hit enter, and it fails to recognize the key. Do you have any suggestions on how to troubleshoot this? Thank you
Nice blog post! It’s straightforward and easy to read. One thing I like is the idea of using a random USB instead of a yubikey because it’s easier to clone and make a backup.
I recommend to put the key shaped USB drive on your main (physical) key ring. You don't leave that in your computer. The keyring goes right back into your pocket as you would do after unlocking any other lock with a key. Optionally you could write a script that requires the key to be removed before the boot continues.
Optionally you could write a script that requires the key to be removed before the boot continues.
I realise this is three years later, but out of interest, do you have any suggestions on how to go about writing such a script that would force someone to remove the USB key before booting continues?
You need to read the key into a variable and then unmount and scan the usb device tree for the device before passing the key from the variable to unlock the drive.
wouldn't that be redundant? why not just decrypt luks with the decryption password created when you installed luks if you're going to type a password anyway?
Dependent_Detail5882@reddit
Very nice and easy solution, thanks :-) I just implemented this on my headless debian 13 server.
I am using LUKS/cryptsetup because I want to be able to simply bin my disks in case they are at the end of their life. But on the other hand I do not want to walk to the server and enter my passphrase every time it boots, so this solution is perfect for me.
The only changes I applied were:
* remove "-part1" from "for usbpartition in /dev/disk/by-id/usb-*-part1"
because my usb drive is named differently (I could have been more explicit on the name too but I'm too lazy)
* replaced vfat with ext4
- in the scripts mount command
- in the /etc/initramfs-tools/modules file
because my usb stick is formatted with ext4
SciurusGriseus@reddit
I am using it for a headless boot on Debian12, with some modification.
- The argument in the third is just the UUID of the USB drive.
- It lets the script be called repeated number of times at 1s intervals, until the USB is visible. If not visible after 10 a monitor is required, and thereafter the user can either enter the usb and hit enter, or enter the password manually.
- It writes to log so if something goes wrong it can be view with journalctl.
https://gist.github.com/craigphicks/115c02969e0d69a9a672ca8c2992f06f
cptnoneal@reddit
Are you using a base install of Debian12?
The default service to handle the decryption is systemd-cryptsetup.
Which does not recognize the keyscript option, making me believe there is something else missing from this guide.
From the Debian crypttab(5) man page keyscript section:
" This option is specific to the Debian crypttab format. It's not supported by systemd.
WARNING: With systemd as init system, this option might be ignored. At the time this is written (December 2016), the systemd cryptsetup helper doesn't support the keyscript option to /etc/crypttab."
Hoping you faced the same issue and found the fix.
SciurusGriseus@reddit
This actually works before systemd action takes place. At that time, the systemd log is not yet even started. That why this script uses `/dev/kmsg` for logging.
When systemd does kick in, it will prepend what has been written to `/dev/kmsg` to the systemd logfile. And systemd will also write a message complaining about the argument it doesn't understand (omitted from the logfile shown above, for simplicity), but that doesn't matter, because the disk is already unencrypted by that point.
So both native Debian initramfs and the systemd use similar but not identical protocols for unlocking. In my use case, using the native Debian initramfs setup which does not contain systemd, I must unlock the disk first during the UEFI process before systemd can even kick in.
In fact systemd does also provide an alternative to GRUB called "systemd-boot". It might be the case that using systemd-boot would allow the disk to become unlocked during the UEFI process. I don't know.
The system under consideration above is a headless system running Debian windowless server only, with a GPU plugged in for NN stuff.
In fact on my main non-headless system (from which I am writing this post) I do use systemd-boot instead of GRUB, but I never tried booting with a key on a USB stick, obviously because I want to keep my main PC secure.
nahakubuilder@reddit
I must say, this is first script what ever worked!!!
Nice
escou64@reddit
Thanks for the blog post! It perfectly works for me on Ubuntu 22.04! However, after updating to 24.04, the auto unlock seems to be no more working: at boot time, I need to press ENTER each time to unlock. Has anyone observed the same issue ? Any idea on how to solve it ?
maus80@reddit (OP)
That probably has to do with the time it takes to initialize USB devices (e.g. it is a timing issue).
d3vilguard@reddit
I've got only one encrypted partition with no subvolmes and my crypttab looks like this and I can't get further with this tutorial.
wurzelnase@reddit
I am having trouble getting this to work. The only step I skipped was 10) because I am using Debian 12. I've verified all steps several times. I suspect that the USB key doesn't get mounted, e.g. when I boot with the key inserted or not, I am getting prompted to insert the key, then I hit enter, and it fails to recognize the key. Do you have any suggestions on how to troubleshoot this? Thank you
wurzelnase@reddit
SOLUTION:
Step 10) is also required for Debian 12 not just Debian 11
https://tqdev.com/2022-luks-with-usb-unlock
Secondly, I also had to use a different USB drive.
deleted_by_reddit@reddit
Nice blog post! It’s straightforward and easy to read. One thing I like is the idea of using a random USB instead of a yubikey because it’s easier to clone and make a backup.
maus80@reddit (OP)
Thank you. It is simpler, cheaper, and can hold as many keys as you want. Arguably it is less secure..
deleted_by_reddit@reddit
One thing I’d imagine is the nuisance of having to remove the usb right away. Otherwise. A thief can steal the stick and laptop together
maus80@reddit (OP)
I recommend to put the key shaped USB drive on your main (physical) key ring. You don't leave that in your computer. The keyring goes right back into your pocket as you would do after unlocking any other lock with a key. Optionally you could write a script that requires the key to be removed before the boot continues.
DavethegraveHunter@reddit
I realise this is three years later, but out of interest, do you have any suggestions on how to go about writing such a script that would force someone to remove the USB key before booting continues?
maus80@reddit (OP)
You need to read the key into a variable and then unmount and scan the usb device tree for the device before passing the key from the variable to unlock the drive.
DavethegraveHunter@reddit
Ok thank you. 😊
sadhunath@reddit
Why did you name your .lek file as a UUID?
maus80@reddit (OP)
To identify the volume (uses the volume uuid) when multiple key files are on a thumb drive.
samkpo@reddit
Is there anyway to also have the keyfile in the drive (or the drive itself) also encrypted with a passphrase?
dhayes501@reddit
wouldn't that be redundant? why not just decrypt luks with the decryption password created when you installed luks if you're going to type a password anyway?