I want to use the real ssh-agent instead of gnome-keyring in xubuntu. I followed the steps from http://dtek.net/blog/how-stop-gnome-keyring-clobbering-opensshs-ssh-agent-ubuntu-1204, but gnome keyring still registers itself as ssh-agent. I still want to keep using gnome-keyring for other passwords

5 Answers 5


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:

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.


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

  • 1
    I can't believe I had to resort to this ugly hack to make such a choice, it's terrible but looked like the only way. Dec 2, 2014 at 16:22
  • For anyone interested, here's the respective section of the docs. Not as clear as this answer.
    – phil294
    Oct 10, 2019 at 14:03

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.

  • What does this do to the $SSH_AUTH_SOCK that gnome-keyring-daemon originally set? I would expect that it stays set in the environment and points to a nonexisting socket (the ssh-add message seems to agree). If so this does not allow someone to automatically run the original ssh agent without some more modifications.
    – JanKanis
    Jun 14, 2016 at 14:24
  • @JanKanis No need to worry, when you run the original ssh-agent it will replace the $SSH_AUTH_SOCK automatically so instead of using the Gnome keyring original value it will use the new one. I have wrote custom solution to replace gnome-keyring-daemon using original ssh-agent notes.rioastamal.net/2016/06/…
    – rioastamal
    Jun 15, 2016 at 1:24

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

    # 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/):



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

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

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.


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]

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



# 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
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:

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

  • Note that you can view a process' environment by doing cat /proc/<PID>/environ | tr \\0 \\n. Use pstree to see the process tree.
    – JanKanis
    May 28, 2016 at 19:08
  • Not a bad idea for debugging similar things in future. Thanks for the suggestion.
    – boltronics
    May 30, 2016 at 2:50

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.



if [[ $ARGS =~ \-\-components= ]]; then
    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
        exit 0

/usr/bin/gnome-keyring-daemon-wrapped $ARGS
  • If there is no --components flag passed, I think gnome-keyring-daemon will just start all components, so in that case this script doesn't work. I think xfce4-session will sometimes do that (maybe depending on configuration).
    – JanKanis
    Dec 2, 2014 at 21:42
  • I think you're right, as I still have this pop up on boot, despite my wrapper. If I kill it and let another app restart it (like Chromium) it will behave itself until reboot... I'll perhaps experiment and see if I can improve.
    – SPoage
    Jan 14, 2015 at 6:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .