Fedora Account System
Red Hat Associate
Red Hat Customer
To reproduce: 1. Install Fedora 44 Workstation 2. Update to current packages 3. systemctl enable sshd.service; systemctl start sshd.service 4. ssh-keygen, set a passphrase 5. cp ~/.ssh/id_*.pub ~/.ssh/authorized_keys 6. ssh <user>@localhost 7. enter passphrase and check "Automatically unlock this key whenever I'm logged in" 8. reboot and do ssh <user>@localhost again, confirm it works immediately and you do not have to enter the passphrase 9. upgrade to Fedora 45 10. try ssh <user>@localhost At this point you are prompted for the passphrase again and the dialog again has the "Automatically unlock this key whenever I'm logged in" check box, unchecked. It should have unlocked the key on login and not prompted me for it, as was working before the upgrade. I don't think this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=2552171 because gvfs should not be involved in this path.
Thanks for filing this. I've seen anecdotal evidence of SSH passphrase issues from several people but this is the first actual downstream bug report. It looks like mcatanzaro already filed this issue upstream when he encountered it: https://github.com/linux-credentials/oo7/issues/586
I recently briefly reviewed the oo7 commits/pull requests after oo7-0.7.0.beta tagged release to see what bug reports we might encounter for issues that are already fixed in the oo7 main branch, and I listed them here https://bugzilla.redhat.com/show_bug.cgi?id=2560362#c2 From that list, this may be caused by the race condition on startup: https://github.com/linux-credentials/oo7/pull/615 https://github.com/linux-credentials/oo7/commit/b54f8e7cec0700366d3be86170053c014e97a576
If the keyring works for other credentials, but not some of them, then inspect the key:value as described in Issue 586. If the keyring works, but it doesn't automatically unlock at log in when it was supposed to, then that's the race condition issue.
Proposed as a Blocker and Freeze Exception for 45-final by Fedora user augenauf using the blocker tracking app because: Saving passwords to and retrieving passwords from the default keyring must work for all release-blocking desktops.
I didn't propose this as a blocker because I don't think it's serious enough to be one.
I've tried this multiple times over the past weeks, and I tried again today, and I still haven't encountered this problem. So it really might be some race condition. I just want to comment that this problem isn't guaranteed to happen. Adam, you could install oo7-cli and inspect the entries, whether they look correct or something's wrong with them.
There are ssh agent problem reports here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-844fdf9ca7 So perhaps this problem might also be related to that and not to oo7.
There's a scratch build of a git snapshot at https://koji.fedoraproject.org/koji/taskinfo?taskID=151720449 . I'll test it and see if it fixes this bug, and if you notice any other problems with it.
FEDORA-2026-fd58111611 (oo7-0.7.0~beta^1.e91b98a-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-fd58111611
Shouldn't the secret store be unlocked using the user's password during login via PAM, similar to how GNOME Keyring works with pam_gnome_keyring.so? The with-pam-oo7 feature has been added to the authselect master branch, but it hasn't been released yet: https://github.com/authselect/authselect/commit/3084703108e4255e95f78c8acc6320851f1154e
FEDORA-2026-fd58111611 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-fd58111611` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-fd58111611 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
oo7 has another PR that was committed an hour ago to address unlocking the keyring on text console login. https://github.com/linux-credentials/oo7/pull/624 https://github.com/linux-credentials/oo7/commit/e55a1b10fc16c252811b4c7f7cf3603f743679e0
I ran the same test again with the oo7 snapshot and it worked. There's some suggestion this bug is racy so I can't say 100% it's fixed, but let's call it VERIFIED...
Discussed at 2026-10-29 Fedora 45 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-10-29/f45-final-go-no-go-meeting.2026-10-29-18.02.html . Rejected as a blocker as this doesn't really violate the cited criterion (storing and retrieving secrets does work, it's only a convenience feature - unlocking the keyring on login - that potentially does not). Accepted as an FE.
FEDORA-2026-fd58111611 (oo7-0.7.0~beta^1.e91b98a-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.