> 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