On Do, 06.06.24 19:42, Sergio Arroutbi (sarro...@redhat.com) wrote: > > > I miss an option where systemd-cryptsetup is executed headless, but > > > continues running, without exiting. > > > > > > I have tried with keyfile=/dev/urandom and option=keyfile-size=600000, > > but > > > it is too quick. I also tried try-empty-password, but this is tried only > > > once. > > > > > > I am running out of ideas. > > > > Hmm, I am not sure I follow? So do you or do you not want cryptsetup > > ask for passwrds via the ask-password agent stuff? > > > > We are developing a PKCS11 plugin for Clevis ( > https://github.com/latchset/clevis). Clevis allows automatic boot encrypted > disks unlocking by storing some information into LUKS metadata.
systemd-cryptsetup supports TPM2 and PKCS#11 natively, you know that? Why isn't that enough for your usecase? What are you missing? >From my PoV Clevis/Tang are useful if you want the networked/SSSS unlock, but if you want TPM/PKCS11 then I am pretty sure systemd-cryptsetup can do that already much better? > To do so, it is executed in parallel to systemd-cryptsetup and, > while the password is prompted to the user (and the agent runs), > Clevis provides the key by writing to the systemd-cryptsetup > ask-password socket. Sorry, but this is simply the wrong approach. The ask-password stuff is for *interactively* asking the user for *passwords* and *PINs*, i.e. for querying *human* users for secrets. It should *not* be used for automatic supplying of key material from non-interactive sources. If you want to supply unlock keys non-interactively, then specify an AF_UNIX/SOCK_STREAM socket as path to a key file in /etc/crypttab. Example: test1 /dev/disk/by-uuid/7376e512-00a4-4a49-8c51-970f0dae5ab1 /run/foobar/keysock - If you do it it like that then systemd-cryptsetup will connect to /run/foobar/keysock and read the key from it. Hence, write a small service (could be socket activated, i.e. ListenStream=/run/foobar/keysock) that listens on that AF_UNIX/SOCK_STREAM socket, and simply respond to any request with your raw key blob, then close the connection. You can even list the same socket inode on multiple /etc/crypttab lines. If you do you can determine from the AF_UNIX peer address on incoming connections for which volume we are requesting the key. For details see: https://www.freedesktop.org/software/systemd/man/latest/crypttab.html#AF_UNIX%20Key%20Files Lennart -- Lennart Poettering, Berlin
