You are not logged in.
What component / tool passes credential to systemd unit in ID form, and how to use it?
systemd-networkd.service(8) automatically imports credentials matching "network.wireguard.*". For more details on credentials, refer to systemd.exec(5).
it is strongly recommended to use an (encrypted) credential.
If the specified path is not absolute and itself qualifies as valid credential identifier it is attempted to find a credential that the service manager itself received under the specified name — which may be used to propagate credentials from an invoking environment (e.g. a container manager that invoked the service manager) into a service.
LoadCredential=network.wireguard.*
I glanced through the massive documentations CREDENTIALS, systemd.exec but still didn't understand how to set it up:
What decrypted the credentials at boot and passed them to the units, such that they can just load by ID? (I'm guessing systemd-creds?)
How to set it up? Looking at systemd-creds I only saw examples using file path. How does it know where the files are if I store them at random locations?
Last edited by Beemo (2026-07-15 01:36:13)
Offline
How does it know where the files are if I store them at random locations?
Once you've stored creds somewhere the location is no longer random but known/fixed . You tell systemd where to find them.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
What component / tool passes credential to systemd unit in ID form, and how to use it? Looking at systemd-creds I only saw examples using file path. How does it know where the files are if I store them at random locations?
systemd expects the credentials to be in well-known directories, unless you specify the full path to the credentials file. This is documented in LoadCredential= in systemd.exec(5) § CREDENTIALS.
If the specified path is not absolute and itself qualifies as valid credential identifier it is attempted to find a credential that the service manager itself received under the specified name — which may be used to propagate credentials from an invoking environment (e.g. a container manager that invoked the service manager) into a service. If no matching passed credential is found, the system service manager will search the directories /etc/credstore/, /run/credstore/ and /usr/lib/credstore/ for files under the credential's name — which hence are recommended locations for credential data on disk. If LoadCredentialEncrypted= is used /run/credstore.encrypted/, /etc/credstore.encrypted/, and /usr/lib/credstore.encrypted/ are searched as well. The per-user service manager will search $XDG_CONFIG_HOME/credstore/, $XDG_RUNTIME_DIR/credstore/, $HOME/.local/lib/credstore/ (and the counterparts ending with .../credstore.encrypted/) instead. The systemd-path(1) tool may be used to query the precise credential store search path.
Offline
Maybe I'm reading it wrong, but that systemd.exec doc seems to suggest 2 scenarios:
"the service manager itself received under the specified name". But how to make it receive the (decrypted) credential?
"no matching passed credential is found, the system service manager will search the directories"
However, I guess I was expecting systemd-creds to be like libsecret (a credential storage / provider service) and it's not.
What I found in the manual is using a drop-in file, which might be how it's supposed to "receive" it:
# mkdir -p /etc/systemd/system/xyz.service.d
# systemd-ask-password -n | ( echo "[Service]" && systemd-creds encrypt --name=mysql-password -p - - ) >/etc/systemd/system/xyz.service.d/50-password.conf
# systemctl daemon-reload
# systemctl restart xyz.servicesystemd-networkd.service is using "LoadCredential=" which expects plain credentials, so that line is useless for encrypted credential (the command above produces a "SetCredentialEncrypted=" block).
Last edited by Beemo (2026-07-14 09:37:13)
Offline
https://github.com/systemd/systemd/issues/26702 - no idea whether that's still relevant/up to date
Offline
Seems like it's indeed the way to pass credentials then.
I'll see if it loads encrypted credential too (I'm guessing no), eventually...
Last edited by Beemo (2026-07-15 01:35:53)
Offline
I'll see if it loads encrypted credential too (I'm guessing no)
Ftr and since this is marked "solved", "LoadCredentialEncrypted=secret" ("secret" being the encrypted cred generated before) didn't work?
Offline