[SOLVED] Upgraded to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

Nate_KS · 08-17-2023, 08:23 AM

I now have two desktop systems running Bookworm with GNOME 43. The laptop was upgraded last month and I upgraded the desktop this past Sunday afternoon. I have been using the GNOME keyring applet to manage the SSH public key passwords I use as it prompts to save passwords and then lets me SSH to other hosts without out a password prompt.

Some time after the upgrade I wanted to SSH into one of the other systems on my LAN and was greeted with a password prompt for the corresponding public key that had prior been managed by the keyring applet. I noted differences in the running processes between the laptop where the keyring applet is still working and the desktop where it was not.

On an off-chance I cold booted this system and found the keyring applet was working as expected so I went on doing other things for a while. Then I tried again and was prompted for the public key's password. Uggh.

Right after rebooting the process list looked like this which mirrors the laptop:

Code:

$ ps ax -u nate | grep "agent\|keyring"
   2037 ?        SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring
   2151 ?        Ssl    0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?        Ss     0:00 ssh-agent -D -a /run/user/1000/openssh_agent
   3802 ?        S      0:00 /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh
   3922 pts/0    S+     0:00 grep --color=auto agent\|keyring

Some time after the cold start and logging in things looked like this:

Code:

$ ps ax -u nate | grep "agent\|keyring"
   2151 ?        Ssl    0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?        Ss     0:00 ssh-agent -D -a /run/user/1000/openssh_agent
  12324 ?        Sl     0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets                                                                  
  12325 ?        Ssl    0:00 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring
  19308 pts/0    S+     0:00 grep --color=auto agent\|keyring

It appears to me that gnome-keyring-daemon has been restarted for some reason. As a result PIDs 2037 and 3802 are terminated and also /run/user/1000/keyring/.ssh is no longer present along with the pkcs11 and ssh files in the same directory.

Code:

debian-archive-keyring/stable,stable,now 2023.3 all [installed,automatic]
fasttrack-archive-keyring/stable,stable,now 2020.12.19 all [installed]
gnome-keyring-pkcs11/stable,now 42.1-1+b2 amd64 [installed,automatic]
gnome-keyring/stable,now 42.1-1+b2 amd64 [installed,automatic]
gpg-agent/stable,now 2.2.40-1.1 amd64 [installed,automatic]
libpam-gnome-keyring/stable,now 42.1-1+b2 amd64 [installed,automatic]
libpolkit-agent-1-0/stable,now 122-3 amd64 [installed,automatic]

A while later, perhaps an hour or so, all keyring PIDs vanished!

Code:

$ ps ax -u nate | grep "agent\|keyring"
   2151 ?        Ssl    0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?        Ss     0:00 ssh-agent -D -a /run/user/1000/openssh_agent
  22418 pts/0    S+     0:00 grep --color=auto agent\|keyring

This behavior has persisted after at least another system restart. I can provide journalctl output if needed.

jamison20000e · 09-17-2023, 12:35 PM

Maybe

Quote:

https://forum.gl-inet.com/t/no-more-...kworm/30525/12

from searching your title or "About 3,850" unrefined "results?"

Nate_KS · 09-17-2023, 01:04 PM

I did eventually post on the GNOME Discourse in the keyring category and was advised to open separate issues in the Gitlab issue tracker. The are issues 135 for the abnormal shutdown and 136 for the failure to restart properly.

Nate_KS · 10-19-2023, 06:11 AM

I have also opened this issue in the Debian BTS:

https://bugs.debian.org/cgi-bin/bugr...gi?bug=1053923

I noted in that report and not elsewhere that the system with the daemon shutting down is running snapd while the other is not. I've no idea if that is relevant to this issue but that is the major difference between the two systems other than other installed packages. Upgrading to 12.2 has not resolved this issue.

Nate_KS · 10-19-2023, 06:14 AM

Quote:

Originally Posted by jamison20000e

Maybefrom searching your title or "About 3,850" unrefined "results?"

Not the same. In my case the gnome-keyring-daemon shuts down in an hour or less after logging in. My SSH keys still work to all the other hosts, I just have to remember and enter the pass phrase.

jamison20000e · 10-30-2023, 04:55 PM

Did you try post #2 from "Debian User Forums" or maybe a search for: how to purge Gnome key rings

Nate_KS · 10-31-2023, 07:54 AM

I'm gathering data for Post #2.

I'm reluctant to purge the keyring as Chromium stores all of its stuff in that file as well independently of the gnome-keyring-daeom it appears.

jamison20000e · 10-31-2023, 06:38 PM

You do clean out your browser Cache once in a while, don't you? I also found a lot of other helpful information with that search on our subject, for example managing or resetting.

Nate_KS · 11-06-2023, 07:29 AM

The keyring is separate from the browser cache. My mention of Chromium is mostly tangential to the issue of the keyring daemon shutting down on the desktop while remaining running on the laptop through multiple suspend/resume cycles.

Nate_KS · 02-19-2024, 05:43 PM

It seems a badly formed cron entry that matched text in the daemon command line was responsible for sending it the SIGTERM signal. Another project recommended the use of 'strace' to examine activity of a process for another project I was working on yesterday. This morning I decided to try it with the gnome-keyring-daemon process after a reboot and discovered the daemon was terminating at the top of each hour no matter how long, or short, of time it ran. I recalled that I had a cron entry that was calling 'pkill' at the top of each hour for an unrelated reason.

I gave a complete write up to the debian-user mailing list: https://lists.debian.org/debian-user.../msg00800.html