Reuse the Boot LUKS Passphrase with pam_systemd_loadkey

Typing the LUKS passphrase at boot only to retype it for GNOME Keyring or KDE Wallet is the annoyance pam_systemd_loadkey removes. On a system using LUKS, it lets an autologin display-manager session pull that same passphrase out of root's kernel keyring, so the wallet unlocks itself. This guide wires up the PAM module and the display manager's systemd service so the service can actually see that keyring.

These instructions match the installed systemd 255 interface. Allow about 15 minutes, plus a reboot or display-manager restart to test it. You need root access, a LUKS volume unlocked by passphrase during boot, and a matching keyring or wallet password.

1. Confirm the prerequisites

1. Check that the module and its documentation are installed:

   $ dpkg-query -W -f='${Package} ${Version}\n' systemd
   $ ls -l /usr/lib/x86_64-linux-gnu/security/pam_systemd_loadkey.so
   $ man 8 pam_systemd_loadkey

The module is a PAM shared object, not a command you run directly. Its documented options are keyname= and debug. The default key name is cryptsetup, the name [email protected] uses for the boot-time LUKS passphrase.

2. Check the password hand-off

1. Confirm which display manager PAM file drives your autologin session. Replace the example name with the file your display-manager configuration actually uses:

   $ sudoedit /etc/pam.d/sddm-autologin

2. Add this line in the auth section:

   -auth       optional    pam_systemd_loadkey.so

The leading hyphen is deliberate: it tells PAM to treat a missing module as ignorable, so this optional integration can never block login on its own. The module reads the last password from a NUL-separated list in root's user keyring and sets it as the PAM authentication token. Never put an actual passphrase in this file.

If your boot process uses a non-default key name, pass it explicitly, for example pam_systemd_loadkey.so keyname=boot-luks. Only use a name that an earlier systemd-ask-password --keyname=... request actually stored.

3. Let the display manager inherit the keyring

1. Create a systemd drop-in for the display-manager service. Substitute the real unit name, such as sddm.service or gdm.service:

   $ sudo systemctl edit sddm.service

2. Enter this unit override, then save and exit:

   [Service]
   KeyringMode=inherit

This one setting is what actually exposes root's keyring to the service. Use a drop-in rather than editing the vendor unit directly: a package upgrade can silently replace that file. The systemctl edit command may just open an editor with no success message.

Verify the effective configuration before restarting anything:

$ systemctl cat sddm.service
$ systemctl show sddm.service -p KeyringMode

4. Add the wallet or keyring session hooks

1. In the same autologin PAM file, add the session modules after the authentication line:

   -session    optional    pam_gnome_keyring.so auto_start
   -session    optional    pam_kwallet5.so auto_start

• Use only the hook for the wallet you actually run. Both are shown here because the systemd documentation covers either integration, but installing neither module, or enabling both for no reason, only makes diagnosis harder later.
• Keep one password everywhere. The LUKS passphrase and the wallet password need to match, because the modules receive the PAM authtok set by the earlier auth line, not a separately typed one.

5. Test during a controlled restart

1. Reload unit configuration, then reboot when you have a way back in:

   $ sudo systemctl daemon-reload
   $ sudo reboot

At boot, enter the LUKS passphrase once. After the display manager autologs in, check whether the selected keyring or wallet is already unlocked. Do not expect pam_systemd_loadkey to print anything; it just hands a PAM token to the modules after it.

Common traps

• Keyring is empty or the wrong password gets tried. Confirm the boot volume was unlocked by passphrase rather than a key file or hardware token, then check that keyname= matches the name the password query used.
• Module cannot find root's keyring. Check the effective service property again. KeyringMode=inherit has to be set on the exact service that launches the PAM session, not on some unrelated user service.
• Wallet still prompts anyway. Verify the PAM file name, the module package, the line order and the desktop-specific session module. Check the display manager and session logs, but never paste passwords or keyring contents into a support ticket.

The cached password does not last: systemd-ask-password --keyname=... keeps it for only a 2.5 minute timeout, so the whole design depends on the display-manager session starting soon after the boot decryption. This is not a permanent password store.