How do I disable gnome-keyring ssh integration?

Question

I don't want gnome-keyring to get in the way of my git commits, partially because it locks the entire screen while asking for a password, even on KDE (though I have now switched to GNOME). While I do appreciate the convenience of not having to put my SSH passphrase in each time, having to jump from window to window cancels that out personally. It's just a comfort thing :/

I tried git config --global --unset credential.helper and git config --system --unset credential.helper, but they seem to have no effect. As I'm now using GNOME, I'd rather not remove gnome-keyring. Is there any other option I can do? I'm presently on Ubuntu 14.10, having done this both with Kubuntu and with Ubuntu GNOME. Thanks.

UPDATE 17 November 2014

This apparently affects all of SSH. I tried doing

sudo rm /etc/xdg/autostart/gnome-keyring-ssh.desktop

but that did not work. I CAN do

gnome-keyring-daemon --replace -c pkcs11,secrets,gpg

once each session, but I would like to keep that permanent. Still looking...

Answer 1

Just copy the relevant .desktop file from /etc/xdg/autostart to ~/.config/autostart and add Hidden=true to it:

(cat /etc/xdg/autostart/gnome-keyring-ssh.desktop; echo Hidden=true) > ~/.config/autostart/gnome-keyring-ssh.desktop

then reload gnome-shell (press Alt + F2, then type r and press Enter).

This is the only user-friendly solution that has worked for me (ie not having to softlink the .desktop file to /dev/null or chmod 0 the gnome-keyring-daemon). In fact, softlinking to /dev/null stopped working for me in GNOME 3.16.

Credit goes to nus.

Answer 2

I can't speak for Ubuntu releases other than Trusty — and GNOME is such a constant moving target that you can guarantee that every release will be different — but this is what I've found to most reliably work:

mkdir -p ~/.config/autostart
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
echo "X-GNOME-Autostart-enabled=false" >> ~/.config/autostart/gnome-keyring-ssh.desktop

Session start up under Unity, at least, and quite probably GNOME3, too, is weird: it will run Upstart scripts out of /usr/share/upstart/sessions/ and then runs all the autostart desktop entries under /etc/xdg/autostart and gnome-keyring, and many other things are in both (and it probably runs things in /usr/share/upstart/xdg/autostart, too; I didn't test that).

The gnome-keyring-ssh upstart entry will check for that X-GNOME-Autostart-enabled=false line in either the system or user local .desktop entry and back out, then the standard ssh-agent session will run. The system-wide gnome-keyring-ssh will then start up out of /etc/xdg/autostart unless you have a matching entry in your user local autostart, in which case that will be run instead.

It used to be enough just to have that enable=false line in the local autostart, but sometime recently (as in, since May 2016, over two years into Trusty's LTS period) that behaviour changed and you need something resembling a full entry. I'm still investigating the precise set of keys necessary, and the offending package update responsible.

Why the GNOME people didn't just proxy through to the OpenSSH key agent is anyone's guess. You might like to suggest they adopt a more sensible behaviour in this Bugzilla entry.

Answer 3

Nice, clean way to disable only the ssh-agent component of gnome-kerying:

gconftool-2 --set --type bool /apps/gnome-keyring/daemon-components/ssh false

Answer 4

I always end up uninstalling gnome-keyring

sudo apt-get remove gnome-keyring

Turns out, if you use many keys (more than three) you can't really log in to hosts that limits attempts to three... Also, gnome-keyring names the keys differently than when using ssh-add, so I don't know what passphrase to use.

Uninstalling gnome-keyring might break a lot of stuff on GNOME, I wouldn't know as I use Kubuntu. On Kubuntu all that disappears in addition are python-ubuntu-sso-client and ubuntu-sso-client.

Answer 5

Solution: Disable gnome-keyring using dpkg-divert

sudo dpkg-divert --local --rename /usr/bin/gnome-keyring-daemon 

Next time you log in, it'll be gone. That one line is all you need, but read on for an explanation and warnings.

Short Explanation

This solution renames the program to gnome-keyring-daemon.distrib so it cannot be found.

When you log in, instead of gnome-keyring trying to handle ssh integration, password requests will go directly to ssh-agent. You can unlock your ssh key for git commits using the usual ssh-add command.

Caveats and remorse

Gnome Keyring is deeply intertwangled with the Gnome Desktop. Without it, some things may stop functioning until a replacement is installed.

To re-enable Gnome Keyring

sudo dpkg-divert --remove --rename /usr/bin/gnome-keyring-daemon 

You might be using Gnome Keyring and not know it

Many applications that can save your passwords, such as Chromium and Evolution, encrypt them using a master key stored in Gnome Keyring. Disabling Gnome Keyring prevents access to all those stored passwords. It is a good idea before disabling Gnome Keyring to backup the saved passwords.

Backing up the Gnome Keyring

You can backup your keys by copying the files in ~/.local/share/keyrings/. The secrets are encrypted so, depending upon your security stance, you may wish to back them up as plain text. To do so, use the "Passwords and Keys" program (aka "Seahorse") to temporarily set an empty password for the Login Keyring. (Tip: Seahorse hides the change password option in the right-click context menu.)

Warning: Passwords may stored in plaintext

Chromium and Google Chrome rely on a daemon called "Secret Service" to get an encryption key for saved passwords. If Secret Service is missing, which it will be once you disable Gnome Keyring, they will save your passwords unencrypted. Unlike Firefox, chromium based browsers do not currently provide a way to manually set a Primary Password.

Freedesktop.org's Secret Service Integration

Gnome Keyring is only one of the programs which can act as the Secret Service daemon. To ensure that saved passwords are encrypted in Chromium and Evolution, you can install keepassxc and enable Secret Service in the settings.

Further explanation

Why not just use chmod or mv?

Changes via chmod or mv will revert when the system is updated. By using dpkg, this solution will persist through anything, even an upgrade to a new release of Ubuntu.

Is there a less drastic way?

At the time of writing, it does not appear to be possible to tell Gnome Keyring to continue providing Secret Service Integration and stop messing with ssh-agent. For many people that would be ideal, so hopefully Gnome will add that option in the future.

Why other methods don't work

Over the years, many different solutions have been proposed only to be broken in the next release. Here's a short summary of why not.

Configuring Gnome Keyring

The ideal solution would be to configure Gnome Keyring to do the right thing. There actually is a command line option --components which almost works. It allows one to specify which components to initialize:

gnome-keyring-daemon --components secrets,ssh,pkcs11

One could omit ssh from the list and, theoretically, it would not muck up ssh authentication. Unfortunately, that was not my experience. Perhaps the problem was that gnome-keyring was getting launched from multiple locations (see below), but the short of it is: there is no way to tell Gnome Keyring to never load the ssh component, only to say not now.

apt remove gnome-keyring

The obvious solution of removing the gnome-keyring package also uninstalls all the packages which depend on it, including gnome-core. While there are ways around it, it is easy to accidentally end up uninstalling the entire GNOME Desktop environment.

Multiple vectors of attack

One of the things that makes gnome-keyring-daemon so hard to kill is that it is launched via (at least) four different methods at login, each of which must be disabled in a particular way.

1. PAM (Pluggable Authentication Modules) in /etc/pam.d/gdm-password
2. systemd user service and socket
3. systemd user session.slice in /usr/share/dbus-1/services/
4. XDG autostart in /etc/xdg/autostart/gnome-keyring-*.desktop

Answer 6

I confirm that the script

#!/usr/bin/python
import gnomekeyring
gnomekeyring.unlock_sync(None,"mypassword");

resolves the issue in 16.04, amd64. The script may be saved as ukr.py, then chmod +x ukr.py, then add ukr.py as a startup application in gnome-session-properties. The (additional) module gnomekeyring is installed via

sudo apt-get install python-gnomekeyring

Answer 7

The easiest way is just to replace existing gnome-keyring-daemon session using command:

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

You can see my full answer on this thread https://askubuntu.com/a/786722/556814

Answer 8

For me, this worked great:

$ unset GNOME_KEYRING_CONTROL

I saw this solution here