Share the Boot LUKS Passphrase with an Autologin PAM Session

On a system using LUKS, pam_systemd_loadkey can let an autologin display-manager session reuse the passphrase entered during boot. That allows GNOME Keyring or KDE Wallet to start unlocked without asking for the same secret again. This guide configures the PAM module and the display manager's systemd service so the service can see root's kernel 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.

Checkpoint 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 to run directly. Its documented options are keyname= and debug. The default key name is cryptsetup, which is the name used by [email protected] for the boot-time LUKS passphrase.

Checkpoint 2: Check the password hand-off

2. Confirm that the display manager's PAM file is the one used for your autologin session. Replace the example name with the file shown by your display-manager configuration:

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

3. Add this line in the auth section:

   -auth       optional    pam_systemd_loadkey.so

The leading hyphen is intentional. PAM treats a missing module as ignorable, which prevents this optional integration from blocking login. The module reads the last password from a NUL-separated list in root's user keyring and sets it as the PAM authentication token. Do not put a 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 the earlier systemd-ask-password --keyname=... request actually stored.

Checkpoint 3: Let the display manager inherit the keyring

4. 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

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

   [Service]
   KeyringMode=inherit

This setting is the part that makes root's keyring available to the service. A drop-in is preferable to editing a vendor unit directly because package upgrades can replace the vendor file. The command may open an editor without printing a success message.

Verify the effective configuration before restarting anything:

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

Expected output includes your [Service] drop-in and a property equivalent to KeyringMode=inherit. If the service name is wrong, stop here and find the installed display manager with systemctl list-unit-files '*display*manager*' '*.service'.

Checkpoint 4: Add the wallet or keyring session hooks

6. 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 the hook for the desktop wallet you actually run. The examples are both shown because the systemd documentation describes either integration, but installing neither module or enabling both without a reason can make diagnosis harder. Keep the same password for the LUKS volume and the wallet. The modules must receive the PAM authtok from the earlier auth line.

Checkpoint 5: Test during a controlled restart

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

   $ sudo systemctl daemon-reload
   $ sudo reboot

Warning: a PAM or display-manager mistake can prevent graphical login. Keep an existing root shell, console access, or remote recovery path open until the test succeeds. If login fails, use that recovery path to remove the three added PAM lines, run sudo systemctl revert sddm.service if you no longer want the drop-in, and 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 output; it supplies a PAM token to later modules.

Failure checks

• The keyring is empty or the wrong password is used: confirm the boot volume was unlocked by passphrase, rather than by a key file or hardware token. Then check that keyname= matches the name used by the password query.

• The module cannot find root's keyring: inspect the effective service property again. KeyringMode=inherit must be on the service that launches the PAM session, not merely on an unrelated user service.

• The wallet still prompts: verify the PAM file name, module package, line order, and desktop-specific session module. Review the display manager and session logs without copying passwords or keyring contents into a ticket.

The cached password is temporary. systemd-ask-password --keyname=... stores cached passwords with a 2.5 minute timeout, so this design depends on the display-manager session starting soon after the boot unlock. It is not a permanent password store.