It turns out that if gnome compatibility is turned on in xfce, xfce4-session will unconditionally start gnome-keyring-daemon. This is hardcoded, there is at the moment no way to configure this. Disabling the gnome compatibility mode results in keyring not starting on login and you will need to provide your password again if you start it.
The simplest solution seems to be to intercept the call to gnome-keyring-daemon, and insert a script that will insert the --components
flag into the arguments to prevent gnome keyring from replacing ssh-add.
Run the following to move gnome-keyring-daemon:
sudo mv /usr/bin/gnome-keyring-daemon /usr/bin/gnome-keyring-daemon-wrapped
create a new gnome-keyring-daemon with
sudo nano /usr/bin/gnome-keyring-daemon
and insert the following content:
#!/bin/sh
exec /usr/bin/gnome-keyring-daemon-wrapped --components=pkcs11,secrets,gpg "$@"
Make the new gnome-keyring-daemon executable with sudo chmod +x /usr/bin/gnome-keyring-daemon
.
Now gnome keyring will no longer try to replace ssh-add.
Note that upgrading your system will reinstate the default gnome-keyring-daemon, so you will probably need to execute the above steps again after upgrading.
edit:
In xubuntu 14.10 startup works slightly different in that g-k-d is also started from the session upstart. It is possible to override the upstart configuration so it won't start the ssh component, but even so g-k-d will start its ssh component when xfce4-session also tries to start it. So if you want to have xfce also automatically start gnome services you will still need the above hack. An alternative is to disable gnome services (Setings -> Session and Startup -> advanced -> Launch GNOME services on startup), configure upstart to start g-k-d with the --components=pkcs11,secrets,gpg
flag, and optionally also configure the gnome services you do want to start manually.
(Apart from the two places that launch g-k-d mentioned above, the g-k-daemon is also started before that from lightdm/PAM in order to receive the user's login password. But that launch does not fully configure g-k-d and it still expects to be fully configured by a second attempt to start it, so that start attempt is not relevant to the current problem.)
NOTE: is not an answer solving the root issue. Please provide a new answer if you think you can solve the root cause. You really have to read on why my solution is just an ugly hack.
Here's an explanation on what happens at boot time, identifying the culprit.
Using KDM (or LightDM) as log in manager, an X session is spawned for you upon logging in. The log in manager allows you to select an X session (e.g. GNOME, KDE Plasma, etc.) based on those available in your system. The directory /usr/share/xsessions
contains the files for each of those desktop environment installed and your user specific choice is saved in ~/.dmrc
.
While the desktop environment loads after logging in, it loads all scripts in /etc/X11/Xsession.d/
. On a Kubuntu 14.04 system I see /etc/X11/Xsession.d/90x11-common_ssh-agent
there by default, initialising an SSH agent. As expected. Great!
In practice however we see different things. Where does gnome-keyring-daemon
come from then and why is the regular ssh-agent
not started? Well, the GNOME keyring is started in two ways:
- XDG autostart, in
/etc/xdg/autostart/gnome-keyring-ssh.desktop
- As an Upstart session job in
/usr/share/upstart/sessions/gnome-keyring.conf
All scripts are first checking the environment values whether they will proceed. E.g.
[ -z "$SSH_AUTH_SOCK" ] || [ -z "$GPG_AGENT_INFO" ] || { stop; exit 0; }
This makes it a sort of race condition which SSH agent is actually started. First one wins. Brace for more nasty bits.
How come it works at one machine reliably and it doesn't reliably at another? The X session upstart jobs are only started when the DESKTOP_SESSION
environment variable is whitelisted for it in /etc/upstart-xsessions
, handled by /etc/X11/Xsession.d/00upstart
. KDM allows one to set a Desktop environment 'Default' (default
in ~/.dmrc
), effectively kde-plasma
, but not appearing kde-plasma
.
With Session=kde-plasma
:
⟫ echo $DESKTOP_SESSION
kde-plasma
With Session=default
in a KDE Plasma desktop:
⟫ echo $DESKTOP_SESSION
default
This is plain wrong. And you can guess now why it fails the whitelist check against /etc/upstart-xsessions
.
Quick fix for running terminal session
killall gnome-keyring-daemon && eval `ssh-agent`
Conclusion
It appears that one can hit a bug with all Upstart session jobs not being started at all. Another bug prevents proper interfacing with the GNOME keyring SSH agent (or ssh-add
should complain and fail). Oh I hate you, bugs.
Once I find time to do some research on what is exactly supposed to do what, I'll file the bug reports.
For now I decided to just 'use' the Upstart bug and prevent Upstart session jobs from running by setting Session=default
. I'm not sure how much this breaks, but so far I haven't seen anything falling apart.
The root cause is the appearance of GNOME keyring in the first place and which should not lie to me and keep offering wrong keys.
Best Answer
I didn't really find a solution, others had the same question on the KDE forum but a simple workaround is to set the ssh agent in
.profile
this is not overwritten by the rest of the start-up procedures and at least sets it correctly in a (startup) shell. In the rest of window system, it's still the other ssh agent, unfortunately.