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

- Debian (https://www.linuxquestions.org/questions/debian-26/)

- - Upgraded to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords (https://www.linuxquestions.org/questions/debian-26/upgraded-to-bookworm-now-gnome-keyring-dies-no-access-to-stored-ssh-key-passwords-4175728120/)

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

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.

Maybe

Quote:

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

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

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.

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.

Quote:

Originally Posted by jamison20000e (Post 6454299)

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.

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

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.

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. :scratch:

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.

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