systemd-creds - Lists, shows, encrypts and decrypts service credentials
systemd-creds is a tool for listing, showing, encrypting and decrypting unit credentials. Credentials are limited-size binary or textual objects that may be passed to unit processes. They are primarily used for passing cryptographic keys (both public and private) or certificates, user account information or identity information from the host to services.
Credentials are configured in unit files via the LoadCredential=, SetCredential=, LoadCredentialEncrypted= and SetCredentialEncrypted= settings, see systemd.exec(5) for details.
The following commands are understood:
Along with each credential name, the size and security state is shown. The latter is one of "secure" (in case the credential is backed by unswappable memory, i.e. "ramfs"), "weak" (in case it is backed by any other type of memory), or "insecure" (if having any access mode that is not 0400, i.e. if readable by anyone but the owner).
When combined with --json= or --transcode= the output is transcoded in simple ways before outputting.
encrypt input|- output|-
Takes two file system paths. The file name part of the output path is embedded as name in the encrypted credential, to ensure encrypted credentials cannot be renamed and reused for different purposes without this being noticed. The credential name to embed may be overridden with the --name= setting. The input or output paths may be specified as "-", in which case the credential data is read from/written to standard input and standard output. If the output path is specified as "-" the credential name cannot be derived from the file system path, and thus should be specified explicitly via the --name= switch.
The credential data is encrypted symmetrically with one of the following encryption keys:
Which of the three keys shall be used for encryption may be configured with the --with-key= switch. Depending on the use-case for the encrypted credential the key to use may differ. For example, for credentials that shall be accessible from the initial RAM disk (initrd) of the system encryption with the host key is not appropriate since access to the host key is typically not available from the initrd. Thus, for such credentials only the TPM2 key should be used.
Encrypted credentials are always encoded in Base64.
Use decrypt (see below) to undo the encryption operation, and acquire the decrypted plaintext credential from the encrypted ciphertext credential.
The credential data is encrypted using AES256-GCM, i.e. providing both confidentiality and integrity, keyed by a SHA256 hash of one or both of the secret keys described above.
decrypt input|- [output|-]
Takes one or two file system paths. The file name part of the input path is compared with the credential name embedded in the encrypted file. If it does not match decryption fails. This is done in order to ensure that encrypted credentials are not re-purposed without this being detected. The credential name to compare with the embedded credential name may also be overridden with the --name= switch. If the input path is specified as "-", the encrypted credential is read from standard input. If only one path is specified or the output path specified as "-", the decrypted credential is written to standard output. In this mode, the expected name embedded in the credential cannot be derived from the path and should be specified explicitly with --name=.
Decrypting credentials requires access to the original TPM2 chip and/or credentials host key, see above. Information about which keys are required is embedded in the encrypted credential data, and thus decryption is entirely automatic.
Note that this has no effect on the encrypt command, as encrypted credentials are unconditionally encoded in Base64.
When specified with the decrypt command control the credential name to validate the credential name embedded in the encrypted credential with. If not specified the name is chosen automatically from the filename component of the specified input path. If no credential name is embedded in the encrypted credential file (i.e. the --name= with an empty string was used when encrypted) the specified name has no effect as no credential name validation is done.
Embedding the credential name in the encrypted credential is done in order to protect against reuse of credentials for purposes they weren't originally intended for, under the assumption the credential name is chosen carefully to encode its intended purpose.
When specified with the decrypt command controls the timestamp to use to validate the "not-after" timestamp that was configured with --not-after= during encryption. If not specified defaults to the current system time.
--with-key=, -H, -T
The -H switch is a shortcut for --with-key=host. Similar, -T is a shortcut for -with-key=tpm2.
When encrypting credentials that shall be used in the initial RAM disk (initrd) where /var/lib/systemd/ is typically not available make sure to use --with-key=tpm2 mode, to disable binding against the host secret.
This switch has no effect on the decrypt command, as information on which key to use for decryption is included in the encrypted credential already.
On success, 0 is returned.
Example 1. Encrypt a password for use as credential
The following command line encrypts the specified password "hunter2", writing the result to a file password.cred.
# echo -n hunter2 | systemd-creds encrypt - password.cred
This decrypts the file password.cred again, revealing the literal password:
# systemd-creds decrypt password.cred hunter2
Example 2. Encrypt a password and include it in a unit file
The following command line prompts the user for a password and generates a SetCredentialEncrypted= line from it for a credential named "mysql-password", suitable for inclusion in a unit file.
# systemd-ask-password -n | systemd-creds encrypt --name=mysql-password -p - - 🔐 Password: **** SetCredentialEncrypted=mysql-password: \
The generated line can be pasted 1:1 into a unit file, and will ensure the acquired password will be made available in the $CREDENTIALS_DIRECTORY/mysql-password credential file for the started service.
Utilizing the unit file drop-in logic this can be used to securely pass a password credential to a unit. A similar, more comprehensive set of commands to insert a password into a service xyz.service:
# mkdir -p /etc/systemd/system/xyz.service.d # systemd-ask-password -n | systemd-creds encrypt --name=mysql-password -p - - > /etc/systemd/system/xyz.service.d/50-password.conf # systemctl daemon-reload # systemctl restart xyz.service