I am running Debian 10. I have been getting following error while updating repositories for long time: $ sudo apt update Hit:1 http://security.debian.org buster/updates InRelease Hit:2 http://deb.debian.org/debian buster InRelease Hit:3 http://deb.debian.org/debian buster-updates InRelease Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date. W: http://security.debian.org/dists/buster/updates/InRelease : The key(s) in the keyring /etc/apt/trusted.gpg are ignored as the file has an unsupported filetype. W: http://deb.debian.org/debian/dists/buster/InRelease : The key(s) in the keyring /etc/apt/trusted.gpg are ignored as the file has an unsupported filetype. W: http://deb.debian.org/debian/dists/buster-updates/InRelease : The key(s) in the keyring /etc/apt/trusted.gpg are ignored as the file has an unsupported filetype. How do I get read of this warning regarding keys? [Here](https://bin.disroot.org/?4f877d71ea1d713d#ArxxtUUJ1i5hJxYv96ySMhJTGoX7cQ8ufV6gpBTYkiNe) is the content of /etc/apt/sources.list Ask in comment if more information is required.

The Gnome Keyrings "Login" and "Default" are not unlocked automatically on my Linux Mint 22 machine. This is an LDAP user account and login goes throughg pam_sss.so (SSSD). The journal seems to indicate that pam_gnome_keyring.so does not receive the entered password (gkr-pam: no password is available for user), but I do not understand why:

$ sudo journalctl -b | egrep -i 'keyring|pam'
Okt 11 17:24:16 promoter lightdm: gkr-pam: gnome-keyring-daemon started properly
Okt 11 17:24:17 promoter lightdm: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "fritz"
Okt 11 17:24:22 promoter lightdm: pam_sss(lightdm:auth): authentication success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=fritz
Okt 11 17:24:22 promoter lightdm: gkr-pam: no password is available for user
Okt 11 17:24:22 promoter lightdm: pam_unix(lightdm:session): session opened for user fritz(uid=30108) by (uid=0)
Okt 11 17:24:22 promoter lightdm: gkr-pam: gnome-keyring-daemon started properly

Here's the (hopefully) relevant sections of my PAM auth config. I could provide more, but I don't think that common-account, common-session, and common-password are relevant to this question:

$ cat /etc/pam.d/lightdm
#%PAM-1.0
auth    requisite       pam_nologin.so
auth    sufficient      pam_succeed_if.so user ingroup nopasswdlogin
@include common-auth
-auth    optional        pam_gnome_keyring.so
-auth    optional        pam_kwallet.so
-auth    optional        pam_kwallet5.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
#session required        pam_loginuid.so
session required        pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
-session optional        pam_gnome_keyring.so auto_start
-session optional        pam_kwallet.so auto_start
-session optional        pam_kwallet5.so auto_start
session required        pam_env.so readenv=1
session required        pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-password

$ /etc/pam.d/cat common-auth 
# here are the per-package modules (the "Primary" block)
auth	[success=2 default=ignore]	pam_sss.so
auth	[success=1 default=ignore]	pam_unix.so nullok
# here's the fallback if no module succeeds
auth	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth	required	pam_ecryptfs.so unwrap
auth	optional			pam_cap.so 
# end of pam-auth-update config

###### Further observations: * The journal message gkr-pam: no password is available for user also appears when unlocking the screensaver from source cinnamon-screensaver-pam-helper.

My login keyring started asking a password after login. I do not use auto-login, I use a regular login with a password. I tried to re-create a keyring, and might made things worse. The passwords for my account and for the keyring are the same. Where do I start, if I want to troubleshoot this? Maybe I need to mention it, but it stopped unlocking after I enabled all the secure boot things on the motherboard to install windows besides fedora. Maybe it has to do something with my problem.

If you check the error log it comes to that .scope unit is not found - No such process. I got similar error 4 times. I would like to understand what is going on during the boot process. Why these errors appear? How to debug it to find even more details? The full log ------------ First three errors appear in this part

...
Jan 05 13:42:51 magnetron systemd: Starting GNOME Session Manager (session: gnome)...
░░ Subject: A start job for unit UNIT has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ A start job for unit UNIT has begun execution.
░░ 
░░ The job identifier is 393.
Jan 05 13:42:51 magnetron gnome-keyring-daemon: The PKCS#11 component was already initialized
Jan 05 13:42:51 magnetron gnome-keyring-d: The PKCS#11 component was already initialized
Jan 05 13:42:51 magnetron gnome-keyring-daemon: The Secret Service was already initialized
Jan 05 13:42:51 magnetron gnome-keyring-secrets.desktop: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring
Jan 05 13:42:51 magnetron gnome-keyring-secrets.desktop: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Jan 05 13:42:51 magnetron gnome-keyring-pkcs11.desktop: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring
Jan 05 13:42:51 magnetron gnome-keyring-pkcs11.desktop: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Jan 05 13:42:51 magnetron gnome-keyring-ssh.desktop: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring
Jan 05 13:42:51 magnetron gnome-keyring-ssh.desktop: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Jan 05 13:42:51 magnetron gnome-keyring-d: The Secret Service was already initialized
Jan 05 13:42:51 magnetron gnome-keyring-daemon: discover_other_daemon: 1
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dpkcs11-2742.scope: Couldn't move process 2742 to requested cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-gnome\x2
dkeyring\x2dpkcs11-2742.scope': No such process
Jan 05 13:42:51 magnetron gnome-keyring-daemon: discover_other_daemon: 1
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dpkcs11-2742.scope: Failed to add PIDs to scope's control group: No such process
Jan 05 13:42:51 magnetron gnome-keyring-daemon: discover_other_daemon: 1
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dpkcs11-2742.scope: Failed with result 'resources'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ The unit UNIT has entered the 'failed' state with result 'resources'.
Jan 05 13:42:51 magnetron systemd: Failed to start Application launched by gnome-session-binary.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ A start job for unit UNIT has finished with a failure.
░░ 
░░ The job identifier is 450 and the job result is failed.
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dsecrets-2743.scope: Couldn't move process 2743 to requested cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-gnome\x2dkeyring\x2dsecrets-2743.scope': No such process
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dsecrets-2743.scope: Failed to add PIDs to scope's control group: No such process
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dsecrets-2743.scope: Failed with result 'resources'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ The unit UNIT has entered the 'failed' state with result 'resources'.
Jan 05 13:42:51 magnetron systemd: Failed to start Application launched by gnome-session-binary.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ A start job for unit UNIT has finished with a failure.
░░ 
░░ The job identifier is 454 and the job result is failed.
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dssh-2740.scope: Couldn't move process 2740 to requested cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-gnome\x2dkeyring\x2dssh-2740.scope': No such process
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dssh-2740.scope: Failed to add PIDs to scope's control group: No such process
Jan 05 13:42:51 magnetron systemd: app-gnome-gnome\x2dkeyring\x2dssh-2740.scope: Failed with result 'resources'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ The unit UNIT has entered the 'failed' state with result 'resources'.
Jan 05 13:42:51 magnetron systemd: Failed to start Application launched by gnome-session-binary.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ A start job for unit UNIT has finished with a failure.
...

The last error is at different place in the log:

Jan 05 13:42:51 magnetron gnome-session: gnome-session-binary: GnomeDesktop-WARNING: Could not create transient scope for PID 2747: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 2747 does not exist.
Jan 05 13:42:51 magnetron gnome-session-binary: GnomeDesktop-WARNING: Could not create transient scope for PID 2747: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 2747 does not exist.
Jan 05 13:42:51 magnetron gnome-session: gnome-session-binary: GnomeDesktop-WARNING: Could not create transient scope for PID 2749: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 2749 does not exist.
Jan 05 13:42:51 magnetron gnome-session-binary: GnomeDesktop-WARNING: Could not create transient scope for PID 2749: GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Process with ID 2749 does not exist.
Jan 05 13:42:51 magnetron systemd: app-gnome-at\x2dspi\x2ddbus\x2dbus-2752.scope: Couldn't move process 2752 to requested cgroup '/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-at\x2dspi\x2ddbus\x2dbus-2752.scope': No such process
Jan 05 13:42:51 magnetron systemd: app-gnome-at\x2dspi\x2ddbus\x2dbus-2752.scope: Failed to add PIDs to scope's control group: No such process
Jan 05 13:42:51 magnetron systemd: app-gnome-at\x2dspi\x2ddbus\x2dbus-2752.scope: Failed with result 'resources'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ The unit UNIT has entered the 'failed' state with result 'resources'.
Jan 05 13:42:51 magnetron systemd: Failed to start Application launched by gnome-session-binary.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support 
░░ 
░░ A start job for unit UNIT has finished with a failure.
░░

My system is Debian Bookworm: uname -a ``` Linux magnetron 6.0.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09) x86_64 GNU/Linux

Previously, Gnome Keyring only asked for the Default Keyring password when I attempted to launch Chrome. I tried playing around with settings in Seahorse to see if there was a work around for this, other than leaving the password database unencrypted. During that process I switched the default keyring to the Login Keyring. Obviously, that did not impact Chrome asking for a keyring password; so, I switched the default keyring back to the Default Keyring. Now, when Lightdm auto logs me in to Cinnamon, Gnome Keyring asks for the Login password every time, after logging in. I cancel that prompt and Gnome Keyring asks for the Default Keyring when I launch Chrome. (I'm fine with this) How do i return to the old behaviour of having the Login Keyring encrypted, but never asking for my user password? (default uses root) I never explicitly set up a password for the Login Keyring prior, and I'm pretty sure it was encrypted before since there has been a Login keyring file since I installed Gnome Keyring a few weeks back.

Due to COVID-19 we are working from home. Now I have a linux (Ubuntu) pc at my workplace which has TortoiseHG Workbench installed. I connect via MobaXTerm to my computer over ssh. Normally when I try to update the repo it works due to the password and user is saved in the keyring. Now when I connect over ssh I can not update my repos due to an error in THG: ** Mercurial Distributed SCM (version 4.5.3) ** Extensions loaded: mercurial_keyring, extdiff, rebase, strip, histedit, tortoisehg.util.hgcommands, tortoisehg.util.partialcommit, tortoisehg.util.pipeui, tortoisehg.util.hgdispatch Traceback (most recent call last): File "/usr/bin/hg", line 41, in dispatch.run() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 88, in run status = (dispatch(req) or 0) & 255 File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 183, in dispatch ret = _runcatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 324, in _runcatch return _callcatch(ui, _runcatchfunc) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 332, in _callcatch return scmutil.callcatch(ui, func) File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 154, in callcatch return func() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 314, in _runcatchfunc return _dispatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 918, in _dispatch cmdpats, cmdoptions) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 673, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 926, in _runcommand return cmdfunc() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 915, in d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1197, in check return func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 4764, in serve return server.runservice(opts, initfn=service.init, runfn=service.run) File "/usr/lib/python2.7/dist-packages/mercurial/server.py", line 107, in runservice return runfn() File "/usr/lib/python2.7/dist-packages/mercurial/commandserver.py", line 339, in run return sv.serve() File "/usr/lib/python2.7/dist-packages/mercurial/commandserver.py", line 292, in serve while self.serveone(): File "/usr/lib/python2.7/dist-packages/mercurial/commandserver.py", line 267, in serveone handler(self) File "/usr/lib/python2.7/dist-packages/mercurial/commandserver.py", line 251, in runcommand ret = (dispatch.dispatch(req) or 0) & 255 # might return None File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 183, in dispatch ret = _runcatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 324, in _runcatch return _callcatch(ui, _runcatchfunc) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 332, in _callcatch return scmutil.callcatch(ui, func) File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 154, in callcatch return func() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 314, in _runcatchfunc return _dispatch(req) File "/usr/lib/python2.7/dist-packages/tortoisehg/util/hgdispatch.py", line 23, in _dispatch return orig(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 918, in _dispatch cmdpats, cmdoptions) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 673, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 926, in _runcommand return cmdfunc() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 915, in d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1197, in check return func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1197, in check return func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/hgext/rebase.py", line 1771, in pullrebase ret = orig(ui, repo, *args, **opts) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1197, in check return func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 3990, in pull other = hg.peer(repo, opts, source) File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 181, in peer return _peerorrepo(rui, path, create).peer() File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 156, in _peerorrepo obj = _peerlookup(path).instance(ui, path, create) File "/usr/lib/python2.7/dist-packages/mercurial/httppeer.py", line 497, in instance inst._fetchcaps() File "/usr/lib/python2.7/dist-packages/mercurial/httppeer.py", line 239, in _fetchcaps self._caps = set(self._call('capabilities').split()) File "/usr/lib/python2.7/dist-packages/mercurial/httppeer.py", line 407, in _call fp = self._callstream(cmd, **args) File "/usr/lib/python2.7/dist-packages/mercurial/httppeer.py", line 336, in _callstream resp = self._openurl(req) File "/usr/lib/python2.7/dist-packages/mercurial/httppeer.py", line 193, in _openurl ret = self._urlopener.open(req) File "/usr/lib/python2.7/urllib2.py", line 435, in open response = meth(req, response) File "/usr/lib/python2.7/urllib2.py", line 548, in http_response 'http', request, response, code, msg, hdrs) File "/usr/lib/python2.7/urllib2.py", line 467, in error result = self._call_chain(*args) File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain result = func(*args) File "/usr/lib/python2.7/urllib2.py", line 916, in http_error_401 url, req, headers) File "/usr/lib/python2.7/dist-packages/mercurial/url.py", line 422, in http_error_auth_reqed self, auth_header, host, req, headers) File "/usr/lib/python2.7/dist-packages/mercurial_keyring.py", line 565, in basic_http_error_auth_reqed return basic_http_error_auth_reqed.orig(self, authreq, host, req, headers) File "/usr/lib/python2.7/urllib2.py", line 894, in http_error_auth_reqed return self.retry_http_basic_auth(host, req, realm) File "/usr/lib/python2.7/dist-packages/mercurial/url.py", line 426, in retry_http_basic_auth realm, urllibcompat.getfullurl(req)) File "/usr/lib/python2.7/dist-packages/mercurial_keyring.py", line 556, in find_user_password return self._pwd_handler.find_auth(self, realm, authuri, req) File "/usr/lib/python2.7/dist-packages/mercurial_keyring.py", line 386, in find_auth pwmgr, realm, authuri, skip_caches=after_bad_auth) File "/usr/lib/python2.7/dist-packages/mercurial_keyring.py", line 349, in get_credentials keyring_pwd = password_store.get_http_password(keyring_url, actual_user) File "/usr/lib/python2.7/dist-packages/mercurial_keyring.py", line 164, in get_http_password self._format_http_key(url, username)) File "/usr/lib/python2.7/dist-packages/mercurial_keyring.py", line 206, in _read_password_from_keyring password = keyring.get_password(KEYRING_SERVICE, pwdkey) File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 41, in get_password return _keyring_backend.get_password(service_name, username) File "/usr/lib/python2.7/dist-packages/keyring/backends/SecretService.py", line 66, in get_password collection = self.get_preferred_collection() File "/usr/lib/python2.7/dist-packages/keyring/backends/SecretService.py", line 60, in get_preferred_collection raise InitError("Failed to unlock the collection!") keyring.errors.InitError: Failed to unlock the collection! ** Unknown exception encountered with possibly-broken third-party extension mercurial_keyring ** which supports versions unknown of Mercurial. ** Please disable mercurial_keyring and try your action again. ** If that fixes the bug please report it to https://bitbucket.org/Mekk/mercurial_keyring/issues ** Python 2.7.17 (default, Apr 15 2020, 17:20:14) [GCC 7.5.0] ** Mercurial Distributed SCM (version 4.5.3) ** Extensions loaded: mercurial_keyring, extdiff, rebase, strip, histedit, tortoisehg.util.hgcommands, tortoisehg.util.partialcommit, tortoisehg.util.pipeui, tortoisehg.util.hgdispatch cmdserver: process exited unexpectedly with code 1 As I understand the keyring demon has not been started. I did some research but could not find a way to start the right agent. Is it right, that Ubuntu Gnome has a special keyring which only starts when the desktop environment starts? How can I start that service?

I am trying to unlock the gnome keyring on my server machine so that I can push git commits via ssh to github. The ssh key for this is encrypted. What I tried is this:

# See https://unix.stackexchange.com/a/676655 
function unlock-gnome-keyring () {
    read -rsp "Password: " pass
    export $(echo -n "$pass" | gnome-keyring-daemon --replace --unlock)
    unset pass
}

unlock-gnome-keyring
# Enter password...
# Prints
# discover_other_daemon: 0** Message: 20:29:52.540: Replacing daemon, using directory: /run/user/1000/keyring

ssh-add /home/username/.ssh/id_ed25519
# Enter password for keyfile...
# Prints:
# Identity added: /home/username/.ssh/id_ed25519 (comment)

That looks OK so far and I can then push to the repo. However, after some time this does not work anymore. Similarly, when I close the shell and reopen it, I am asked again for the passphrase. This may be expected if the shell that sharted the keyring daemon gets closed? I don't quite know. Either way, I try to unlock the keyring again, as above and get the same output. Then,

$ git pull
sign_and_send_pubkey: signing failed for ED25519 "/home/username/.ssh/id_ed25519" from agent: agent refused operation
git@...: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

This can only be fixed by re-adding the key to the keyring. How can this be fixed?

When reading gnome-keyring-daemon manual, one can see pretty clearly that the --components option has four valid values: ssh, secrets, gpg, and pkcs11. However, I couldn’t find any detailed explanation on these four options. Could someone detail the **use** and the **field of use** of each component of gnome-keyring-daemon? (For instance it is obvious to me the ssh component is used to automatically decrypt ssh private-keys passphrases and feed them to ssh but other components (especially their field of use) remain obscure to me.)

I am using linux mint and have the nextclound desktop application installed. After each login, I get another login screen: > Authentication required. > The login keyring did not get unlocked when you logged into your computer. Then I can enter my login password again and nextcloud starts without issue. When I open "Passwords" and Keys, Everything looks fine for me: nextcloud is part of the login keyring: How can I configure this, so that the nextcloud can access its keys without me entering the password twice. Edit: I just noticed that if I cancel the "Authentication required" dialog, the keyring is in the locked status:

On ubuntu 22.04, I want to login remotely to it using RDP after boot up, the machine is not connected any display. RDP is not started and Wayland (Gnome session) is not unlocked without physical interaction of user with keyboard and mouse. Although Autologin is successful, gnome session is locked with keyring on ubuntu 22.04. When I try to unlock manually by connecting with HDMI display, the RDP password is randomly changed. Needs. 1. Bypass the keyring prompt to unlock automatically. 2. Must not be randomly changed RDP login password. How to solve it. Thanks.

Sometimes my Linux Mint 22.1 Cinnamon installation takes too much RAM and I have to kill the session. To avoid restarting the computer, I press Ctrl+Alt+Del instead of holding the power button for 5 seconds. But when I try to connect to an SSH server (e.g. when I do a git push), I have to enter the password in the terminal:

lfavole@laurent-linuxmint:~$ ssh git@github.com
Enter passphrase for key '/home/lfavole/.ssh/id_ed25519':

instead of in this GUI prompt:  And the terminal prompt occurs every time that I want to connect via SSH / push something to a repo, and I am mirroring my Git repositories to 3 platforms, whereas the GUI prompt pops up only once per session. How can I restart the keyring process to get the GUI prompt back?

Some tens of minutes after I login with a KDE session, I get a modal gcr-prompter window asking for the master password of the GNOME keyring. The prompt does not include any information about what program is trying to use the keyring or even if the prompter is started by gnome-keyring. From the security perspective, I find it kind of annoying that I need to enter an important password without even knowing which program is asking for the password. **Is there some way to find out which program requested access to the keyring?** The whole desktop is locked (all keystrokes go into the password field) and canceling several times cancels the whole prompt. On the Linux console I see the process started by gnome-keyring, but still I don't know which program is trying to open the keyring.

I'm new to Linux and I've been running the latest version of Zorin OS. I've turned on automatic login on my desktop, but every time it boots, on the desktop a window pops up saying: "An application is trying to access the keyring "Default Keyring" but failed. I tried following a guide to fix this problem but the steps don't quite match. Thank you for your help!

When trying to run a backup with Vorta on Debian 10/KDE I'm prompted to enter my password "Enter password to unlock your login keyring" but after entering my current password it displays: > The login keyring did not get unlocked when you logged into your computer. After looking it up it seems like this is happening because I changed my sudo password. **-> Why does changing the password not update any other relevant files so that this prompt accepts the current password (why does this error still occur at all)? And what's the simplest, most recommended way to solve it on Debian/KDE?** I don't have a .gnome2/keyrings directory .

Whenever I login using the fingerprint sensor instead of the login password, a popup is displayed from gnome-keyring to enter the login password in order to unlock the various certificates that are stored there. This is quite annoying, because it steals the focus, and doesn't let you do anything else until the password is entered. It won't even let you change the keyboard language, so if you had it in a different language than the password before the reboot, you are screwed. I wasn't even able to take a screenshot of the popup, which is why the quality of the picture is so low - it was from my mobile. A partial solution to this problem is to set the keyring password to an empty string, by opening the Passwords and Keys app (type keyring into the search bar), and using the menu as below: But is not a very good solution, because the keyring password keeps being reset, and you have to repeat the same process all over again. I am not sure if this happens on some reboots, or when there has been an update. So my question is twofold: 1. Am I correct in my thinking that the keyring passphrase doesn't add any security, and is redundant, since the system uses secure boot, with UEFI setting that doesn't allow boot from any other disk without an admin password, LUKS full disk encryption, and there are no other user accounts on the laptop? 2. If (1) is correct, then how can I permanently remove the keyring password, in a way that it doesn't get added automatically again? ### Edit This question is related, but the answer doesn't offer a workaround: https://unix.stackexchange.com/questions/393888/why-is-my-no-password-setting-on-my-login-keyring-frequently-reset ### Information requested in the comments

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.3 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/ "
SUPPORT_URL="https://help.ubuntu.com/ "
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/ "
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy "
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.3 LTS
Release:	20.04
Codename:	focal

$ echo $XDG_CURRENT_DESKTOP
ubuntu:GNOME

$ cat /usr/share/gnome/gnome-version.xml


 3
 36
 8
 Ubuntu
 -->

I use Ubuntu 24.10 (Oracular) on a Lenovo Thinkpad X1 (Gen12) with the standard Gnome shell (see [here](https://ihrke.github.io/posts/linux_on_thinpad_x1_gen12.html) for my setup). The problem is not specific to oracular, it was present with 22.04 as well. I am getting this weird error where after a restart, the mail client evolution does not connect to any of my email accounts (I get errors about "Timeout reached" popping up in my client, see screenshot below). I say it is weird, because it only happens sometimes and when I restart the computer the problem is usually gone (it happens maybe 50% of the time when I restart - it is very annoying!). I think this issue might have something to do with the gnome keyring (when I login, I get a a popup telling me to unlock the keyring with a password, which I can succesfully complete). I have no idea how to diagnose this problem (i.e., which logfiles to look at etc), any help would be very much appreciated!

Is it possible to store the Firefox Primary Password (formerly known as the Master password) using the freedesktop secret service dbus API, in order to bypass the password prompt when Firefox starts and attempts to sync? If this were possible, the primary password would be stored in your local password manager (such as KWallet, gnome-keyring, KeePassXC, ...)."

Consider this: > dbus-send --session --print-reply --dest=org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID string:org.gnome.keyring method return time=1724158870.854936 sender=org.freedesktop.DBus -> destination=:1.19163 serial=3 reply_serial=2 uint32 9720 > ps -lp 9720 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD > kill -0 9720 9720: No such process > ps -axlww | fgrep -i keyring 1 XXXX 9722 9216 1 0 293296 3012 - SLl ? 0:23 gnome-keyring-daemon --replace --daemonize --components=pkcs11,secrets,gpg How is this possible? DBus 1.14.6 running under kernel 4.14.328 (if that's even relevant). New observation: it looks like the service gets registered by the launcher before it forks off the daemon. > gnome-keyring-daemon -r -d & 26812 ** Message: Replacing daemon, using directory: /run/user/XXXX/keyring-nIw6b7 GNOME_KEYRING_CONTROL=/run/user/XXXX/keyring-nIw6b7 SSH_AUTH_SOCK=/run/user/XXXX/keyring-nIw6b7/ssh GPG_AGENT_INFO=/run/user/XXXX/keyring-nIw6b7/gpg:0:1 GNOME_KEYRING_PID=26818 > dbus-send --session --print-reply --dest=org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID string:org.gnome.keyring method return time=1724239784.045804 sender=org.freedesktop.DBus -> destination=:1.19724 serial=3 reply_serial=2 uint32 26812 Weird that dbus and GNOME_KEYRING_ID don't correspond but apparently that causes no issues for usual clients. I ran into this "issue" testing KeePassXC's "secret service" feature which wouldn't activate because pid 9720 was already providing the service.

I usually use Ubuntu via Screen Share (RDP) in another building and sometimes I need to reboot. But 1st thing after a reboot is a box asking to authorise the keychain/keyring which I can't type into remotely. I do not wish to root/sudo the whole OS in order to get around this as others have suggested. As another example, I also use my iMac remotely via Screen Share in a similar fashion. If I reboot the machine, I can still Screenshare into the login screen and type my password after a reboot. There is no need to disable any passwords or security features. So how can I reboot a Screen Shared Ubuntu OS and get to the desktop again If I can't physically type things into the keyboard?

Recently, I’ve tried to install nheko, a Matrix client, but I failed using it because it complains it cannot store password and other secrets because there are no providers for org.freedesktop.secrets available on my machine. Not knowing what that meant, I googled it, and found out it’s some standard API for a keyring, the example implementation being GNOME Keyring. Since I use neither Gnome nor KDE, I don’t really want to use software that’s supposed to integrate in these DE, so I looked for alternatives, and I found pass secret service, which is a provider for org.freedesktop.secrets using the GNU Pass backend, which is a good thing for me because I otherwise use pass as my password manager. I tried installing using it by enabling services.passSecretService system-wide, then rebooted. However, that didn’t work: nheko now complains that it timeouts when it tries to store things, and retrieving passwords using GNU Pass takes a significant amount of time. I suspect the issue is the following: - whenever my GPG key is required, the GPG agent tries to obtain the password, first by checking if it’s in the keyring, and resorting to pinentry (ie. a password-asking popup) otherwise - my GPG key is required both when trying to read and write in the password store using GNU Pass, because it has to uncipher the crypted passwords, and because when it writes something, it commits it to the underlying repo, which in turn tries sign the commit using the same key. - checking if a secret information is in the keyring requires reading the password store, since I’ve connected the keyring interface to the GNU Pass backend. That creates a cycle: whenever I need to get the password of my GPG key, it tries to query the keyring first, which in turn queries the password store, which in turns asks GPG the decipher its content, which in turn makes GPG try to get the password for the key, … This, I think, ends with a timeout, explaining why nheko fails with an error message about a timeout, and why the password store takes more time to retrieve the password: it just fails to get the password until the timeout occurs, and then it reverts to asking me for the password. How can I setup things properly to avoid these issues? Ideally, the solution would be not to put GPG key passwords in the keyring at all, if my understanding of the situation is correct.