However I primarily want to unlock servers via “remote unlocking” to each one a Nitrokey shall be connected to. Remote unlocking via ssh works in general, but not when using “keyscript=decrypt_gnupg-sc”. I assume it conflicts with already ongoing decryption attempt.
As soon as decryption retries fail due to non-entered Nitrokey PIN, the dropbear connection is closed.
I hope I am not the first one trying remote unlock with GPG keys for root LUKS partion, so I am wondering if there is already a solution out there.
May I ask what’s the advantage of doing this? I assume the key is always plugged in to the server. To unlock it, you need manual user interaction anyway, why not just use a super secure password instead?
@Amazyy333 The advantage of using the nitrokey is that luks-key to unlock the device is secured by the secure element on the key, which will lock-down access after just a few wrong PIN tries (unlike cryptsetup, which does not lock).
@dimxbsqo
I’m not aware of an existing solution for the anticipated setup, but let me add a couple remarks:
To my understanding the dropbear_initramfs hook from debian (which you probably use) may wait for you to enter a (backup) passphrase of the LUKS device. It may simply unlock luks-root and boot, if you enter that into the ssh connection blind - have you tried that?
What you try to achieve is to keep the luks-key to unlock the root safe on the nitrokey. Ok. The general problem here is, though, that luks/dm-crypt is designed as a data-at-rest encryption scheme. If you unlock root remotely and have no sufficient safeguards protecting system integrity before and after, you must consider the encryption potentially compromised. This means the luks-key on your nitrokey may still be safe, but the unlocked luks-masterkey may have been extracted, rendering its protection void as soon as the system boots.
To solutions:
a. If you consider your safeguards (physical security, etc.) for system integrity sufficient, an existing solution for a setup would be to (1) activate ssh public-key authentication for dropbear, (2) activate secureboot so that integrity of the initramfs and kernel is attested and (3) simply use a luks passphrase via ssh to unlock root. The script should actually default to that, in case no nitrokey is present.
b. The more wholesome approach nowadays is to install a verity-protected system root. In the last years (since the keyscript you use was last updated), a number of distros have been published that employ an immutable system root. Search for “immutable linux distros” to get an overview of their features. With such an installation, you can gain a lot more assurance of an uncompromised root.
c. Obviously, it is an alternative to have a second (b) small installation for remote access and keep your existing regular system root intact. Then login via remote to the secondary and unlock/mount the existing on demand.
HTH
