Hello there,
I’m coming from Fedora and I’d like to mimic a default configuration on fedora’s side that, if the password to decrypt the device is the same as the user password then the keyring gets automatically unlocked using this password.
I believe there is a PAM plugin involved, unfortunately I cannot find the information to try to replicate this setup.
I’m using Tumbleweed with Plasma.
Does anyone knows how to do this here ?
Do you have any pointers how Fedora does it?
Well, LUKS password has really nothing to do with user password. LUKS is unlocked in system context and keyring is unlocked in user context. I would be quite interested in how it is done.
Auto login maybe???
Do you have any pointers how Fedora does it?
If I recall correctly, The prompt to unlock the disk with systemd stores the password somewhere in memory and a PAM module fetches it and unlock the gnome wallet.
I’ve found various issues talking about this:
Well, LUKS password has really nothing to do with user password. LUKS is unlocked in system context and keyring is unlocked in user context. I would be quite interested in how it is done.
Yes, I’m aware of this.
It seems the feature is only available for GNOME, but I’m not completely sure.
It seems it can be achieved with the following PAM module : pam_systemd_loadkey
So, I think I’m onto something but I cannot figure out how to make it work, here is where I’m at:
In /etc/pam.d/common-auth I’ve added this
auth optional pam_systemd_loadkey.so
before
auth optional pam_kwallet5.so
In /etc/pam.d/common-session I’ve added the auto_start at the end of the line
session optional pam_kwallet5.so
I’ve disabled the display-manager script and enabled directly sddm with the override:
[Service]
KeyringMode=inherit
Still no luck, I have a prompt for kdewallet. Not sure where it fall short.
If you read the manual page you referenced:
The password list is supposed to be stored in the “user” keyring of the root user, by an earlier call to systemd-ask-password(1) with
--keyname=. You can pass the keyname to pam_systemd_loadkey via thekeyname=option.
So, you need to use the correct keyname= option depending on how exactly your LUKS volume is unlocked. You actually never explained what, when and how does it.
So, you need to use the correct
keyname=option depending on how exactly your LUKS volume is unlocked. You actually never explained what, when and how does it.
I find this strange, because the doc also states:
The default is "
cryptsetup". During boot, systemd-cryptsetup@.service(8) stores a passphrase or PIN in the keyring
Also, my volume is unlocked at boot with a prompt (with a plymouth UI, I guess), I believe its systemd-cryptsetup that does the unlock with the result of the prompt since a systemctl status systemd-cryptsetup@cr_root.service returns:
● systemd-cryptsetup@cr_root.service - Cryptography Setup for cr_root
Loaded: loaded (/etc/crypttab; generated)
Active: active (exited) since Sat 2025-03-22 15:53:23 CET; 1h 21min ago
Invocation: 57d6d22866834647a1c7fa1a4a820249
Docs: man:crypttab(5)
man:systemd-cryptsetup-generator(8)
man:systemd-cryptsetup@.service(8)
Main PID: 937 (code=exited, status=0/SUCCESS)
CPU: 7.462s
mar 22 15:53:11 fire systemd[1]: Starting Cryptography Setup for cr_root...
mar 22 15:53:21 fire systemd-cryptsetup[937]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/...
mar 22 15:53:23 fire systemd[1]: Finished Cryptography Setup for cr_root.
Moreover, the docs of crypttab states that password-cache is at yes by default, and the cr_root device comes from this file.
What would be the keyname instead of the default cryptsetup ? I’m confused. Is there any way to read the content of this ?
bor@10:~> sudo -i
10:~ # keyctl list @u
1 key in keyring:
895357096: --alswrv 0 0 user: cryptsetup
10:~ #
That is on a system with root FDE
This would be for the user root. You can get the complete overview with
cat /proc/keys
Hmm …
10:~ # keyctl print 895357096
keyctl_read_alloc: Key has expired
10:~ #
Indeed, the timeout appears to be 2.5 minutes if I interpret the code correctly. How long your startup takes? You should be able to override it by setting
SYSTEMD_ASK_PASSWORD_KEYRING_TIMEOUT_SEC=infinity
in the environment of the cryptsetup@.service, at least for testing.
I do have the key in the keyring :
# keyctl list @u
1 key in keyring:
678611289: --alswrv 0 0 user: cryptsetup
# keyctl print 678611289
keyctl_read_alloc: Permission denied
The key is there, I cannot print it, but it is there. My boot is quite fast (SSD and good cpu).
So, I think the issue might be related to PAM.
Did you read the comment on top of this file?
Anyway, sddm-autologin PAM service does not use common-auth.
Yes, I’ve checked the file and deleted/copied from the symlink. I did not find any /etc/pam.d/sddm* file so I’ve assumed that, on openSUSE, they might have a different architecture when it comes to PAM files. I’ve used this doc to navigate it: Authentication with PAM | Security and Hardening Guide | openSUSE Leap 15.6
And when I checked the /usr/lib/pam.d/sddm-autologin PAM file, I saw that it was loading the elements describe in the /etc/pam.d/ common files :
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_permit.so
account substack common-account
account include postlogin-account
password substack common-password
password include postlogin-password
session required pam_loginuid.so
session optional pam_keyinit.so revoke force
session substack common-session
session include postlogin-session
I have tried to put everything in the common-session without any success
I have figured it out ! Here is a little explanation on how I achieved it:
First, copy the sddm-autologin into /etc/pam.d to override it:
sudo cp /usr/lib/pam.d/sddm-autologin /etc/pam.d
Once copied, open t e file sudo vim /etc/pam.d/sddm-autologin and modify it so it looks like this (this is a diff, do not add the +):
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_permit.so
+auth optional pam_systemd_loadkey.so
+auth optional pam_kwallet5.so
account substack common-account
account include postlogin-account
password substack common-password
password include postlogin-password
session required pam_loginuid.so
session optional pam_keyinit.so revoke force
session substack common-session
session include postlogin-session
Once done, the display-manager.service must be altered to allow accessibg the keyring : (on my system, display-manager.serviceis directly sddm.service, I do not know how it works when there is the bash script wrapper by default):
systemctl edit display-manager.service
In the override part, add:
[Service]
KeyringMode=inherit
That should do the trick ! No package has to be installed, everything is present on the default setup. Note: on my system, the auto_start flag was not required on the common-session, so I did not use pam-config at all.
I feel like it would be a truly great addition to have this by default in terms of UX for coming users that uses FDE with autologin (fedora do indeed activate this by default), it is a setup that happens to be almost the default one when installing openSUSE (I’ve made almost no customization of the default setup).
Huh?!? openSUSE installer does not mix LUKS passphrase and user’s password.
Huh?!? openSUSE installer does not mix LUKS passphrase and user’s password.
I meant, having autologin and LUKS activated at the same time with the same password.
I do not feel its “mixing” it or somewhat a bad feature, it’s an option that could exist in the installer to prevent systems used by single users (which are most systems nowadays) from entering the same password twice.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.