upstart job race prevents gnome-keyring from being ssh agent

[Marc Deslauriers]

I expect gnome-keyring to be the ssh authentication agent when I am logged in to a graphical session.

Because of what I suspect is a race in upstart jobs, I believe SSH_AUTH_SOCK is being overwritten after gnome-keyring starts.

Perhaps the gnome-session job needs to make sure the ssh-agent job is finished?

[testcase]
1) Perform desktop login
2)
[ "$GNOME_KEYRING_CONTROL/ssh" = "$SSH_AUTH_SOCK" ] && echo Good || Fail

Expected output: Good

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: gnome-session 3.9.90-0ubuntu5
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
Uname: Linux 3.13.0-5-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Jan 22 10:25:59 2014
InstallationDate: Installed on 2013-11-26 (56 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
PackageArchitecture: all
SourcePackage: gnome-session
UpgradeStatus: Upgraded to trusty on 2014-01-17 (4 days ago)

[Dimitri John Ledkov (xnox)]

I was wondering, if that's just me or everyone. It appears that gnome-keyring does not ship user-session jobs & the default ssh-agent is used from openssh-client package, which does ship user-session job.

So gnome-keyring should provide user session jobs for all of it's agents & export the AGENT environment variables, similar to the ssh-agent job.

[Dimitri John Ledkov (xnox)]

/etc/xdg/autostart/gnome-keyring-pkcs11.desktop
/etc/xdg/autostart/gnome-keyring-ssh.desktop
/etc/xdg/autostart/gnome-keyring-gpg.desktop
/etc/xdg/autostart/gnome-keyring-secrets.desktop

[Marc Deslauriers (mdeslaur)]

gnome-keyring updates SSH_AUTH_SOCK by calling gnome-session's Setenv DBus method.
gnome-session then calls DBus's UpdateActivationEnvironment so that dbus activated clients also get the env variable.

Perhaps adding the upstart job, but leaving the autostart desktop files in place is sufficient?

[Marc Deslauriers (mdeslaur)]

This may also be the cause of bug 1259564

[Andre Tomt (andre-tomt)]

I see what I think is this bug on 3 different computers running 13.10, 2 installed with 13.10, 1 upgraded from 12.10.

Often what ssh agent is tried depends on how I start the terminal - the agent environment is set differently if started from the dash, launcher or alt-ctrl-t. And sometimes they all work like they should.

[Leon (leonbo)]

I can confirm what Andre is saying: launching a terminal via the launcher or the dash (or synapse) results in Unity not using gnome-keyring. If I launch via ctrl-alt-t gnome-keyring is used.

Launch via the dash:
SSH_AGENT_PID=2253
SSH_AUTH_SOCK=/tmp/ssh-y0YsIQziIbZX/agent.2249

Launch via ctr-alt-t:
SSH_AGENT_PID=2253
SSH_AUTH_SOCK=/run/user/1000/keyring-0WLPB7/ssh

[Øyvind Stegard (oyvinst)]

I have chosen to unlock my GPG key at login time. In processes launched by Unity, I sometimes get the GPG_AGENT_INFO environment variable set, but other times (in other login sessions) not. So likely some kind of race. From terminal launched with Ctrl+Alt+T, the variable always seems to be available. (Emacs, which I usually launch from Unity, needs this variable to connect to gpg agent.)

Fully updated 14.04 and clean installation.

[Damien Cassou (cassou)]

Is there any workaround so that all applications started from the dash can benefit from the agent?

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-keyring - 3.10.1-1ubuntu5

---------------
gnome-keyring (3.10.1-1ubuntu5) utopic; urgency=medium

  * debian/gnome-keyring.conf: upstart user-session job to re-export
    gnome-keyring agent's sockets into the desktop environment. (LP:
    #1271591)
 -- Dimitri John Ledkov <email address hidden> Mon, 28 Apr 2014 13:40:08 +0100

[CSRedRat (csredrat)]

When this fixed in 14.04 Trusty Tahr for 14.04.1 (24 July)?

[Bruno Nova (brunonova)]

Finally found this bug report!
I have the same issue. Sometimes it happens, sometimes it doesn't.

Is the fix going to be backported to Tusty soon? That would be great.

[Bruno Nova (brunonova)]

In the meantime, just grab this file from here http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/gnome-keyring/utopic/view/166/debian/gnome-keyring.conf
(it's the fix) and put it in /usr/share/upstart/sessions/, then restart the session and see if the problem is gone forever.

Still, I'm waiting for the fix to appear in the Trusty repositories (should be trivial to backport).

[Bruno Nova (brunonova)]

Sorry, that link is wrong. This is the correct one: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/gnome-keyring/utopic/view/168/debian/gnome-keyring.conf

[Vlad Orlov (monsta)]

More than four months passed - and the fix for a bug with "Importance" set to "High" isn't in Trusty yet?

Disappointing.

[atimonin (atimonin)]

It seems a better way would be to fix /etc/X11/Xsession.d/90x11-common_ssh-agent
(to start ssh-agent before gnome-keyring-daemon or not start it at all)
According to man page use of "initctl set-env --global" is discouraged

[Dimitri John Ledkov (xnox)]

@marga
with this change, gnome-keyring desktop session upstart job will take over ssh-agent upstart job in Trusty 14.04 LTS, and thus override SSH_AUTH_SOCK with the gnome-keyring's one. To disable this:

- system-wide: echo manual | sudo tee -a /etc/xdg/upstart/gnome-keyring.override
- user-wide: echo manual | tee -a ~/.config/upstart/gnome-keyring.override

[Dimitri John Ledkov (xnox)]

[ubuntu/trusty-proposed] gnome-keyring 3.10.1-1ubuntu4.1 (Waiting for approval)

gnome-keyring (3.10.1-1ubuntu4.1) trusty; urgency=medium

  * debian/gnome-keyring.conf: upstart user-session job to re-export
    gnome-keyring agent's sockets into the desktop environment. (LP:
    #1271591)

[Chris J Arges (arges)]

Hello Marc, or anyone else affected,

Accepted gnome-keyring into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gnome-keyring/3.10.1-1ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Bruno Nova (brunonova)]

I upgraded gnome-keyring to 3.10.1-1ubuntu4.1 from trusty-proposed in a virtual machine.

Before upgrading and rebooting, this bug was occurring.
After rebooting, the bug was gone. I rebooted about 5 times and tested ssh keys using gnome-terminal (started both from the Dash and from Ctrl+Alt+T) and it worked every time.

So, for me it's fixed!

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-keyring - 3.10.1-1ubuntu4.1

---------------
gnome-keyring (3.10.1-1ubuntu4.1) trusty; urgency=medium

  * debian/gnome-keyring.conf: upstart user-session job to re-export
    gnome-keyring agent's sockets into the desktop environment. (LP:
    #1271591)
 -- Dimitri John Ledkov <email address hidden> Mon, 13 Oct 2014 10:35:26 +0100

[Chris J Arges (arges)]

The verification of the Stable Release Update for gnome-keyring has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[agnul (sucrabu)]

Running gnome-terminal with the Alt-F2 shortcut the SSH_AUTH_SOCKET env variable is not set. Used to work until a couple of days ago, could this be related?

[Vincent Cautaerts (vincent-cautaerts)]

I have a problem similar to the one of 'agnul' since yesterday's update in ubuntu 14.04 (this update included gnome-keyring 3.10.1-1ubuntu4.1)

When I start a gnome-terminal with alt+F2, the environment is OK (SSH_AUTH_SOCK set)

When I start a terminal using a keyboard shortcut, the env is OK too.

When I start a terminal from the launch menu, the env is OK too.

But when I start it from a ".desktop" file, I don't get the SSH_AUTH_SOCK variable. It was working OK until yesterday's update.

[Vincent Cautaerts (vincent-cautaerts)]

Additionnal note to my last comment:

After downgrading to "gnome-keyring 3.10.1-1ubuntu4" (from "gnome-keyring 3.10.1-1ubuntu4.1"), loging out/in, it started working again: a terminal started form a '.desktop' file has the proper SSH_AUTH_SOCK variable.

[Vlad Orlov (monsta)]

Looks like the things got worse...

Though for us at Linux Mint things haven't really changed. Running mate-terminal via mintMenu still sets SSH_AUTH_SOCK to the wrong value (in /tmp dir).

[Forest (foresto)]

Based on the behavior I've observed, I think it's possible that there are two bugs in play here, and fixing one has revealed the other one.

I'm running Xubuntu 14.04.

Before this update, starting my terminal from the applications menu yielded a shell with SSH_AUTH_SOCK correctly pointing at gnome-keyring, while starting my terminal from a folder in Thunar file manager yielded a shell with SSH_AUTH_SOCK incorrectly pointing at an ssh-agent instance. The latter didn't work because I only have my ssh key loaded into gnome-keyring.

After the update, starting my terminal from the applications menu yields a shell with SSH_AUTH_SOCK correctly pointing at gnome-keyring, while starting my terminal from a folder in Thunar file manager yields a shell with SSH_AUTH_SOCK not set at all.

I haven't read the recently released patch yet, so I don't know what it's supposed to do, but it sure looks like it got rid of the ssh-agent instance that I thought I had disabled long ago (great!). That still leaves the problem of why SSH_AUTH_SOCK isn't propagating into my terminal when launched from my file manager.

[Roger Peppe (rogpeppe)]

I just encountered this problem and eventually found this bug.
I see exactly the behaviour described above - starting a terminal with
ctrl-alt-T gets the correct SSH_AUTH_SOCK, otherwise it's wrong.

dpkg -s gnome-keyring confirms that the fix above is
already running on my system:

% dpkg -s gnome-keyring
Package: gnome-keyring
Status: install ok installed
Priority: optional
Section: gnome
Installed-Size: 3572
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Multi-Arch: foreign
Version: 3.10.1-1ubuntu4.1
Depends: dconf-gsettings-backend | gsettings-backend, libc6 (>= 2.15), libcap-ng0, libdbus-1-3 (>= 1.1.1), libgck-1-0 (>= 3.3.90), libgcr-base-3-1 (>= 3.8.0), libgcrypt11 (>= 1.5.1), libglib2.0-0 (>= 2.37.3), libgtk-3-0 (>= 3.0.0), gcr (>= 3.4), dbus-x11, p11-kit (>= 0.16), libcap2-bin
Pre-Depends: multiarch-support
Recommends: libpam-gnome-keyring, libp11-kit-gnome-keyring
Breaks: libgnome-keyring0 (<< 3.0), seahorse-plugins (<< 3.0)
Conffiles:
 /etc/xdg/autostart/gnome-keyring-pkcs11.desktop 784b3d1e0681f9bb3c8e88a5dd647f0b
 /etc/xdg/autostart/gnome-keyring-gpg.desktop 36f92b6ee1ec39fd7a66800ed344b982
 /etc/xdg/autostart/gnome-keyring-ssh.desktop 2524e326e3413945eabe06dabadb75e5
 /etc/xdg/autostart/gnome-keyring-secrets.desktop 6bbabf4d27046c3bbd4c9081bd9abc4c

[David Lechner (dlech)]

For those of us that don't want to use gnome-keyring-ssh and use ssh-agent instead, this breaks our setup.

Previously, we were able to disable gnome-keyring-ssh by ediing /etc/xdg/autostart/gnome-keyring-ssh.desktop and setting NoDisplay=false. Then it would be visible in Startup Applications Preferences and you could turn it off. (For mre details and screenshots, see https://github.com/dlech/KeeAgent/issues/89#issuecomment-63449092)

However, now even though gnome-keyring-ssh is disabled at startup, these new changes cause it to run anyway. What is the new way to disable gnome-keyring-ssh?

[Gunnar Thielebein (lorem-ipsum)]

I am using gnome-keyring-daemon with ssh-agent capability which broke with the keyring-daemon 3.10.1-1ubuntu4.1.
After downgrading to gnome-keyring=3.10.1 SSH_AUTH_SOCKS is again correctly exposed to the keyring location.

[Vlad Orlov (monsta)]

Here's the list of the regression bug reports caused by this update so far:

https://bugs.launchpad.net/bugs/1387747
https://bugs.launchpad.net/bugs/1388259
https://bugs.launchpad.net/bugs/1391775
https://bugs.launchpad.net/bugs/1412624

Please comment and/or click on "affects me" there instead.

[Dimitri John Ledkov (xnox)]

Please stop filing duplicate bugs.
The regression was fixed in vivid a long time ago and is tracked to be SRUed again in

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1387303