Keyring authentication required with LUKS and automatic login

Ask Fedora Ask in English
, , ,
1

I setup full disk encryption during install and successfully configured automatic login. However, every time I log in I get an Authorization Required prompt, stating that “the login keyring did not get unlocked when you logged into your computer”, even though all of the 3 passwords involved are the same (LUKS encryption password, user password, and keyring password).

ea1af346363652f79da0e229da998ca9646abfca.jpeg

I was under the impression that systemd-cryptsetup were to make the password used for the disk encryption available to PAM, which in turn would be used by pam_gnome_keyring.so to unlock the login keyring.

In fact, it seems that an Arch Linux user once tried to mimic this behavior from Fedora, as described in the ArchWiki GNOME/Keyring#Using_the_keyring, which sums up to the behavior I expect. Did I mess something up?

I’ve checked /etc/pam.d/gdm-autologin and these lines were already there:

...
-auth      optional    pam_gnome_keyring.so
...
session    optional    pam_gnome_keyring.so auto_start
...

I also tried to change the keyring password, as suggested for the topic keyring-authentication-required-prompt-every-login/19261, and then changed it back again to match the other passwords, but the problem persisted.

If I disable automatic login and type in the user password on GDM, the keyring is unlocked successfully. But then I’d have to type the password twice anyway (LUKS and GDM).

How can I make the keyring to be unlocked automatically, with the same password used during boot for the LUKS encrypted disk, when GDM is configured for automatic login?

Thank you in advance.
Diogo

2

Hi, I never did auto unlock disk encryption. But may be you could start it over and works only for auto unlock disk encryption first and ignore the GDM since it should be easy because it’s already have setup configuration in Gnome setting for auto login.

As long as I know, if we encrypt the root partition, the flow should be grub → boot → insert password to unlock disk encryption → continue to boot → GDM → insert user password → session.

The auto unlock disk encryption should involving something with fstab for the default mount target for systemd during the boot and maybe it also pointing the key or whatever data saved to unlock the encryption.

I try to find on the internet and found this article and look like it make sense, but not sure if this works. Maybe you could find another resources with same approach.

3

Hi! Thank you for taking the time looking into this. The auto unlock I’m trying to get working is for the Gnome Keyring, when I’m already logged in. The password for disk encryption I am willing to type myself.

So with the workflow you mentioned, I’m looking for something like this: boot → I manually type the password to unlock disk encryption → continue to boot → GDM automatic logs me in just fine → session comes up → Gnome Keyring gets unlocked automatically with the password I typed for disk encryption, granted that both passwords are the same.

I thought this should work out of the box since pam_gnome_keyring.so is configured in PAM to unlock the ‘login’ keyring using the same password; and GDM seems supposed to get the password used in cryptsetup and make last_cached_password available as PAM_AUTHTOK.

I either messed up some configuration or I’m misunderstanding the implementation.

This other thread makes me believe it should work as I’m expecting, since the complaint there is only for the times you type the wrong password before typing it right: https://github.com/systemd/systemd/issues/17565

4

I’m afraid the only way is to set an empty password on the login keyring:
https://discussion.fedoraproject.org/t/keyring-authentication-required-prompt-every-login/76027/2?u=vgaetera

5

Hi! Thanks for replying.

All the passwords involved are already the same. I even tried using seahorse to change the password as suggested in that thread, in case something was outdated, but the keyring still doesn’t get unlocked automatically.

In fact I tried to link to that exact thread in my original post, just for reference of what I’ve tried before, but I wasn’t allowed to link to more than 2 links.

7

I really believe that, by design, gnome-keyring is supposed to be unlocked with cryptsetup password, considering the commit 31ed6f2b3f1ab45ae07aad41c13a51ba91fd159d to pam_gdm (I’d post a link to it but somehow my topic has been marked as spam):

If the user has an encrypted disk then systemd will cache the password
they type into the keyring. It makes sense to try to use this password
for automatic login purposes first, since on single user machines,
the sole user password is likely to match the disk password.

Of course if it doesn’t work we’ll fall back to the old way of doing
automatic login without a password (and then the user will have to
manualy enter if they need to for gnome-keyring or whatever)

I must have messed something up with my setup… :sob:

8

I think I understand now. Ussually if we set to auto login, there will some app or task will ask to enter the passworrd (gnome keyring). But if we disable the auto login, this keyring things are integrated with gdm.

If above true, then you’re must be out of luck. I just tried to install Fedora Workstation 35 with luks. Then create autologin for gdm. Just like that without other setting. No any pop up messages asking for keyring during in the session. I just insert once the password when unlock the disk encryption.

Update: both luks and gdm have same password.

9

Thank you so much for trying it. Did you also have Gnome Keyring set up? I think the pop up only starts showing up when there’s a keyring to unlock. This should happen when secrets need to be saved, such as when adding an Online Account or setting up SSH passphrase.

I’ll try it myself on a VM to reproduce the problem with a clean install. Perhaps I messed something up.

10

Not sure. But here what I did to test:

I have 2 machine, A without luks, B with luks. Then both of them I install seahorse and set gdm to auto login and also have online account set on Gnome online accounts.

The A machine without luks, when I open seahorse, the left menu mentioning password are locked.

The B machine with luks (need to enter password on boot to decrypt the disk), when I open seahorse, the left menu mentioning password already unlocked.

11

Thank you for investigating it further.

I’ve also tried a clean install of Fedora 35 in a VM just now, with LUKS and GDM auto-login, and Gnome Keyring was unlocked successfully out of the box. So the feature exists.

However I’ve noticed some differences compared to my laptop, but couldn’t figure out yet how to fix it.

This is a journalctl snippet from the clean VM install:

Dec 30 14:23:51 clean-vm audit[1099]: AVC avc: denied { read } for pid=1099 comm="gdm-session-wor" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=key permissive=0
Dec 30 14:23:51 clean-vm audit[1099]: AVC avc: denied { read } for pid=1099 comm="gdm-session-wor" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=key permissive=0

For some reason this error happens on a clean install, but does not happen on my laptop. So either gnome-session-worker doesn’t run at this point on the laptop or SELinux doesn’t block it.

On my laptop, this is what’s logged regarding authentication:

Dec 30 11:55:00 laptop audit[1437]: USER_AUTH pid=1437 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_permit acct="diogo" exe="/usr/libexec/gdm-session-worker" hostname=laptop addr=? terminal=/dev/tty1 res=success'
Dec 30 11:55:00 laptop audit[1437]: USER_ACCT pid=1437 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="diogo" exe="/usr/libexec/gdm-session-worker" hostname=laptop addr=? terminal=/dev/tty1 res=success'

While the clean VM install logs something different:

Dec 30 14:23:51 clean-vm gdm-autologin][1099]: gkr-pam: stashed password to try later in open session
...
Dec 30 14:23:51 clean-vm audit[1099]: USER_AUTH pid=1099 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_gdm,pam_gnome_keyring,pam_permit acct="diogo" exe="/usr/libexec/gdm-session-worker" hostname=clean-vm addr=? terminal=/dev/tty1 res=success'
Dec 30 14:23:51 clean-vm audit[1099]: USER_ACCT pid=1099 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="diogo" exe="/usr/libexec/gdm-session-worker" hostname=clean-vm addr=? terminal=/dev/tty1 res=success'

The clean VM install mentions stashed password, while my laptop does not.

And the clean VM install logs me in with the grantors pam_gdm,pam_gnome_keyring,pam_permit, while my laptop just says pam_permit.

The funny thing is that this laptop install is just a few days old, so I haven’t really tweaked it that much to make all those differences. I’ll keep digging and see if I can fix it. Thanks again.

12

I think I just read something like this, but I can’t find it. Instead I landed to this https://wiki.gnome.org/Projects/GnomeKeyring/Pam on part Options of the PAM module. Looks like some PAM parameters didn’t set/load correctly, but I’m not sure. I’m afraid it will lead you to wrong direction.

On this part:

parameters: list of services. Example: only_if=gdm,xdm

13

DId you ever make any headway with this? I think I’m having the same problem with my laptop in F36 and 37

https://discussion.fedoraproject.org/t/is-the-keyring-auto-login-unlock-with-luks-passphrase-is-broken-removed/71966

14

Unfortunetely, no. I’ve just disabled automatic login on GDM, then after the LUKS prompt during boot I have to type the same password again, like they did in Ancient Mesopotamia.