Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#13986 - Gnome Keyring's SSH Agent doesn't work outside of GNOME desktop

Attached to Project: Arch Linux
Opened by Smith Dhumbumroong (zodmaner) - Friday, 27 March 2009, 15:07 GMT
Last edited by Jan de Groot (JGC) - Sunday, 31 May 2009, 09:29 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


After upgrade gnome-keyring package to version 2.26.0-1 from Testing repository, Gnome Keyring's SSH Agent stop working outside of GNOME desktop.

In previous versions, the keyring's SSH Agent used to work on other DE/WM, such as Openbox.

The keyring starts just fine on other DE/WM, but instead of creating both /tmp/keyring-<sth>/socket and /tmp/keyring-<sth>/ssh it only created the first one, thus no ssh support.

Downgrade the package to version in extra repository (2.24.1-1) restored the functionality.

Additional info:
* package version(s)
- gnome-keyring 2.26.0-1

* config and/or log files etc.
- none

Steps to reproduce:
- Upgrade gnome-keyring to latest version from testing repository
- Restart and try to use ssh to login to other machine, observed that the keyring isn't working

This task depends upon

Closed by  Jan de Groot (JGC)
Sunday, 31 May 2009, 09:29 GMT
Reason for closing:  Not a bug
Additional comments about closing:  User needs to launch a dbus session bus. When not using gdm/kdm, user is responsible for it himself.
Comment by Jan de Groot (JGC) - Monday, 30 March 2009, 14:40 GMT
What options do you use to launch gnome-keyring-daemon?

I checked gnome-keyring sources, the ssh agent is a component plugin since 2.25.x. If nothing has been specified on the commandline using the -c option, gnome-keyring will read the enabled components from gconf in /apps/gnome-keyring/daemon-components/.
Comment by Smith Dhumbumroong (zodmaner) - Tuesday, 31 March 2009, 08:59 GMT
The keyring was started automatically by GDM with the following options: --daemonize --login.

I checked gconf key /apps/gnome-keyring/daemon-components using gconf-editor and make sure that both ssh and pkcs11 key is enabled, but still the ssh agent won't work (still no /tmp/keyring-<sth>/ssh or /tmp/keyring-<sth>/pkcs11).

Using --daemonize --login --components=ssh,pkcs11 options, I try to start the daemon by put the line in .config/openbox/ and start it manually from terminal. Both methods produce same result: Still no /tmp/keyring-<sth>/ssh (or pkcs11). Using --daemonize --login --components=ssh options also produces the same result.

I then tried to run gnome-keyring-daemon from terminal with out any arguments or options (just $ gnome-keyring-daemon). This time, the daemon success in creating both /tmp/keyring-<sth>/socket.ssh and /tmp/keyring-<sth>/socket.pkcs11, but still the ssh agent doesn't work.

The following is what was throw at me by gnome-keyring when I tried to run it from terminal without any options:
** Message: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files

Maybe we need to have GNOME session manager running in order to use ssh agent?

Oh and bender02 have reported that with the rest of GNOME updated, now the keyring also didn't work in GNOME too (source:
Comment by Michael (SiD) - Monday, 13 April 2009, 17:54 GMT
I have the same problem with Openbox. gnome-keyring does not work if I start the XServer with startx. I get the same error as zodmaner if I run gnome-keyring-daemon from a terminal.

** Message: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files

If I use GDM it works.
Comment by Jan de Groot (JGC) - Monday, 13 April 2009, 18:05 GMT
This dbus error message is normal when not running gnome. What gnome-keyring tries to do is injection of environment variables into the gnome-session process using dbus. If gnome-session isn't running, it can't inject the variables.
There's quite some important bugfixes included in 2.26.1, including a packaging bug on my side (the package contained two dbus service files for the same daemon). Please test this version, as it might solve your problems.
Comment by Michael (SiD) - Monday, 13 April 2009, 18:15 GMT
I already used version 2.26.1-1.

I tried to start gnome-keyring-daemon from ~/.xinitrc but it does not work. I need gnome-keyring for nm-applet and Zatto but both ask me for a password because gnome-keyring does not work.

Comment by Jan de Groot (JGC) - Monday, 13 April 2009, 18:23 GMT
When you use GDM, it works you say... When you use startx, do you also start the dbus session bus from .xinitrc? GDM does that for you, and without a dbus session bus many applications (including gnome-keyring it seems), fail to operate correctly.
Comment by Michael (SiD) - Tuesday, 14 April 2009, 08:21 GMT
I added the content from /etc/X11/xinit/xinitrc.d/30-dbus to my ~/.xinitrc and now it works.

# launches a session dbus instance
dbuslaunch="`which dbus-launch 2>/dev/null`"
if [ -n "$dbuslaunch" ] && [ -x "$dbuslaunch" ] && [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
eval `$dbuslaunch --sh-syntax --exit-with-session`
Comment by Jan de Groot (JGC) - Tuesday, 14 April 2009, 08:32 GMT
you can source /etc/X11/xinit/xinirc.d/* also, that's what gdm and kdm do.
Comment by cercasii (cercasi) - Thursday, 23 April 2009, 07:07 GMT
status confirmed [gnome-keyring-2.26.1-1]
after upgrade from 2.24 nm-applet [used in dwm] doesn't find stored wifi passwords.

adding this to .xinitrc:
source /etc/X11/xinit/xinirc.d/*

fixes it.

Status Unconfirmed -> Confirmed? Upstream bug?
Comment by Jan de Groot (JGC) - Thursday, 23 April 2009, 07:18 GMT
It's not an upstream bug, it's a user configuration bug. Maybe we can add a source of /etc/X11/xinit/xinitrc.d/* to the default .xinitrc, but this won't fix this issue for other users.