Multiple conflicting SSH agents and SSH_AUTH_SOCK not set after upgrade to noble
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| gnome-keyring (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
After upgrading mantic to noble, there are multiple SSH agents who are independently trying to set SSH_AUTH_SOCK, none of which is successful.
1. ~/.config/
This will start the regular GNOME Keyring SSH Agent. It will set the Agent location to /run/user/1000/ssh, while the Socket is initialised at /run/user/1000/.ssh
2. If that one is not running, the user unit ssh-agent.service kicks in.
It sets the Socket to live at /run/user/
3. Parallely, there is also a GPG agent emulating SSH support gpg-agent-
Socket at /run/user/
4. There is also the (new?) user unit gcr-ssh-
It sets its Socket to live at /run/user/
---
The last one seems to be preferred by GNOME upstream nowadays, but also comes with caveats, as its unit does not set the SSH_AUTH_SOCK variable. This commit from !137 (see below) does not seem to be included in /usr/lib/
- https:/
Apparently it's solved upstream with the gcr 4.2.1 release. Installed is 4.2.0-4build1
There are discussions about how this is possibly resolved in
- https:/
- https:/
- https:/
- https:/
- https:/
- https:/
Similar regressions around GCR (What does that abbreviation even mean? It's not explained in the readme) are described in the following, including other possible workarounds:
- https:/
- https:/
