Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
LUKS password no-longer prompted on boot #1962
I just manually upgraded a box from 1235.12.0 to 1353.7.0 and the LUKS password prompt for the root filesystem was no-longer being issued to the console on boot.
Extracting the initramfs on the 1353.7.0 vmlinuz image, it looks like:
If I patch the 1353.7.0 initramfs with the above from 1235.12.0 (plus the old
Can we get the above systemd support back into the initramfs?
Container Linux Version
Bare metal server.
The LUKS password is prompted on boot from within the initramfs.
No prompt; dracut eventually times out and dumps the console on an emergency prompt.
AFAIK we've yet to intentionally support LUKS encrypting root, so the fact that it did work was merely a happy accident.
We're still working out proper support (more discussion #1687).
Since we're going to be shipping those tools in the initrd eventually regardless, it makes sense to add them back, but we might not have proper tests for this until we have a supported/documented approach using ignition.
cc @dm0-, it seems likely this changed as part of the v233 update at a guess.
I'm happy to have unofficial support until it is formalized. I've been making good use of LUKS for full-disk encryption since late 2016. I'm also happy to manually test it for you in the meantime, since I'm using it anyway.
To remotely supply the unlock secret on boot, I'm using a dropbear sshd. I do this by patching your initramfs for each CoreOS update, which is a pain, but I often have to rebuild kernel drivers (modules) on some upgrades anyway; this process is semi-automated.
Separately, would you be open to adding a dropbear sshd to the initramfs? I'm happy to open a new issue. In my setup, dropbear only activates when there exists a
I agree with that -- my approach was a pragmatic one. At this stage I'm not expecting dropbear support in the CoreOS initramfs. But it would be appreciated if you could restore
I can imagine that you'll eventually need some kind of client and daemon pair, with the initramfs acting as a client perhaps leading to a cleaner architecture. The initramfs connects on startup to a centralized daemon "waiting room" for their LUKS key. That key is provided either automatically, or manually on operator approval. You could use TLS mutual auth with client keys stored on the OEM partition; the server-side would need to support a CRL in case the CoreOS machine is stolen or compromised. Or, perhaps less desirable, we could use some kind of hardware ID in lieu of a client cert.
What I'm doing with dropbear/SSH is actually very similar to the above, where SSH keys are used in place of TLS mutual auth, and the initramfs is the daemon, not the client. The client is my terminal, where I manually SSH into the CoreOS machine (initramfs; via dropbear) after a reboot.
I'm not aware of anything we could use off-the-shelf. If I find any time, I'll have a stab at writing something simple -- would you be interested in that approach at all?