xubuntu: stop gnome-keyring-daemon from impersonating ssh-agent

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.)


It's an old thread but my workaround for this problem on Xubuntu 14.04 is simple by just respawning gnome-keyring-daemon on Session and Startup. What you need to do is simply running command below:

$ gnome-keyring-daemon --replace --daemonize --components=pkcs11,secrets,gpg

We remove "ssh" from the component of Gnome keyring.

  1. Go to Menu > Settings > Session and Startup
  2. Click Application Autostart tab
  3. Click Add button
  4. New application window will appear, you can fill it like example below
    1. Name: SSH Keyring Remover
    2. Description: Remove SSH from GNOME Keyring
    3. Command: gnome-keyring-daemon --replace --daemonize --components=pkcs11,secrets,gpg
  5. Click OK

Try to log out your XFCE session and log in back. To make sure Gnome keyring does not manage ssh anymore just run.

$ ssh-add -l
Could not open a connection to your authentication agent.

If you got that message means Gnome keyring is not manage your SSH and you're free to use the original OpenSSH ssh-agent implementation.


To build on the answer by @JanKanis, I traced it down to xfce4-session being the culprit for initiating the gnome-keyring-daemon --start command.

When run that way gnome-keyring-daemon does not check for SSH_AUTH_SOCK already being set, which is a "feature", since you then can have both ssh-agent and gnome-keyring-daemon providing a socket.

First things first:

Add ~/.config/upstart/gnome-keyring.conf:

description "GNOME Keyring agents"
author "Dimitri John Ledkov <[email protected]>"

start on (starting xsession-init or starting ssh-agent or starting gpg-agent) and started dbus

task
script
    # Stop because I say so
    stop; exit 0
    eval "$(gnome-keyring-daemon --start)" >/dev/null
    initctl set-env --global SSH_AUTH_SOCK=$SSH_AUTH_SOCK
    initctl set-env --global GPG_AGENT_INFO=$GPG_AGENT_INFO
end script

Now replace gnome-keyring-daemon with a wrapper (I moved the original to /usr/libexec/):

#!/bin/sh

gkd=/usr/libexec/gnome-keyring-daemon
debug=1
log=${XDG_CACHE_HOME:-"${HOME}/.cache"}/gkd.log

if [ ${debug} -gt 0 ]
then
    echo "================" >> ${log}
    echo "Invoked as $0 $@" >> ${log}
    echo "================" >> ${log}
    /usr/bin/pstree -lag >> ${log}
fi

case "$@" in
    *--start*)
        $gkd --components=pkcs11,secrets,gpg "$@"
        ;;
    *)
        $gkd "$@"
        ;;
esac
if [ ${debug} -gt 0 ]
then
    /usr/bin/pstree -lag  >> ${log}
fi

The debug code is there for you to figure out why it stopped working. Since none of these programs have sane configuration methods, there is just no way around hacking commands. In this case, I can't find any documented configuration method for xfce4-session to not envoke gnome-keyring-daemon --start, that has no other side-effects. They all make ass-sumptions about things being installed and thus go ahead read the user's mind.


Here's a less invasive version of the script JanKanis posted. It accepts whatever components were passed to it, but yanks out the SSH component.

#!/bin/bash

ARGS="$@"

COMPONENTS=""
if [[ $ARGS =~ \-\-components= ]]; then
    component_match_expression='(\-\-components=([0-9a-z,]+))'
    COMPONENTS=$(echo $ARGS | grep -oP "$component_match_expression")

    ARGS=$(echo $ARGS | sed -E "s/$component_match_expression//")

    COMPONENTS="--components=$(echo $COMPONENTS | grep -oP '(?<=\-\-components=)([0-9a-z,]+)' | sed -e 's/ssh//' -e 's/,,/,/')"
    if [ "$COMPONENTS" != "--components=" ]; then
        ARGS="$ARGS $COMPONENTS"
    else
        exit 0
    fi
fi

/usr/bin/gnome-keyring-daemon-wrapped $ARGS

I've just encountered this problem on Xubuntu 16.04, and I too wanted both ssh-agent and gpg-agent working.

Firstly, I didn't care about gnome-keyring, so I removed all related packages. eg.

sudo dpkg -P libgnome-keyring-common libgnome-keyring0 libp11-kit-gnome-keyring libpam-gnome-keyring libgnomeui-0 python-gnome2 gir1.2-gnomekeyring-1.0 system-config-printer-gnome

At this point ssh-agent and gpg-agent were both running successfully, but gpg could not connect to gpg-agent due to $GPG_AGENT_INFO not being set. That's really weird because if we look in /etc/X11/Xsession.d/90gpg-agent it's clearly getting set initially. Something must be un-setting it.

To help find the culprit I created a custom session file:

$ cat /usr/share/xsessions/xsession.desktop 
[Desktop Entry]
Version=1.0
Name=Xsession
Exec=/etc/X11/Xsession
Icon=
Type=Application

I then created a custom ${HOME}/.xsession file and made it executable, with something like the following:

#!/bin/sh

# DEBUG
echo "GPG_AGENT_INFO: ${GPG_AGENT_INFO}" > "${HOME}/GPG_AGENT_INFO"

# Defined by /etc/alternatives/x-session-manager
exec x-session-manager

I logged out, restart lightdm and logged in again (with the "Xsession" session selected), and inspected ${HOME}/GPG_AGENT_INFO. Sure enough, the environment variable was still set. So it was something silly Xfce4 was doing.

Poking around, I eventually stumbled upon this:

$ strings /usr/bin/xfce4-session | grep gpg
/startup/gpg-agent/enabled
gpg-agent
gpg-agent-info
GNOME compatibility is enabled and gnome-keyring-daemon is found on the system. Skipping gpg/ssh-agent startup.
gpg-agent is configured as SSH agent, but gpg-agent is disabled or not found
Failed to kill gpg-agent with pid %d
$

Seems xfce4-session is probably un-setting the variable when it tries to launch gnome-keyring-daemon, so the solution requires two steps. First, go to Applications -> Settings -> Session and Startup -> Advanced and tick Launch GNOME services on startup. Next, create an executable file called gnome-keyring-daemon somewhere in your $PATH with the following contents:

#!/bin/sh
#
# This script exists to satisfy an XFCE4 check which prevents
# the GPG_AGENT_INFO environment variable getting unset.

Log out and in once more, and you should be sorted. You should also now be able to delete /usr/share/xsessions/xsession.desktop and ${HOME}/.xsession if you created those too, as they were just for debugging.