Any way to autologin with LUKS encrypted boot drive?
Hello everyone!
I daily drive a Nobara install with my main drive being an LUKS encrypted M.2 drive. Every time I boot my computer I get presented with the password prompt to unlock the drive and afterwards get prompted with my login manager to login.
Is there any way to combine these steps into a single prompt? It is starting to get a bit annoying having two steps every time I boot.
I asked this a while back and was told I am an idiot for asking and it is astonishing I am able to even use a computer, which I clearly am not responsible enough to use.
Just kidding (not really) but consensus was "not very easily". I tried a few methods which were complicated and didn't manage to work. Yes, Windows and MacOS do this seamlessly, but nobody has yet taken the time to add a similar functionality to Linux.
What OP is asking is trivial to setup on linux though. Just setup autologin on your login manager which is probably a single checkbox.
Your issue is different because you want biometric login. LUKS encryption only supports passwords, keyfiles and hardware keys (they are kinda goofy though). So you have to use the login manager which supports biometrics. But if you want full disk encryption, you first need to decrypt the hard drive. This can be done by storing the decryption key in the TPM part of your processor. That obviously means that someone with electron microscope could steal your data if they stole your computer. But if you don't care about that, it's a solution. On MacOS and and Windows it works nicely but on linux not so much. Ubuntu has TMP based encryption but it's currently experimental.
Alternative solution is to use Yubikey Bio (hardware key with fingerprint scanner) with LUKS but hardware keys are kinda goofy to setup.
Another is to not use Full disk encryption. You can just encrypt your home folder. Downside are that your cannot use hibernation and less robustness. For example once I accidentally typed my root password to the root shell and it therefore got written to /root/.bash_history which was not encrypted. (it's probably best to symlink it to /dev/null)