10

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

Improve this question
1
11

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.

Improve this answer
4
  • 5
    It seems this no longer works in 16.04. Why does it seem like with every Ubuntu release, a new method of starting things is reinvented? What happened to good old Xsession? :( – Phil Frost May 18 '16 at 16:12
  • Someone please validate it for newer Ubuntu/Debian/GNOME versions. – George Sovetov Feb 24 '18 at 12:47
  • In Ubuntu 17.10 (GNOME Wayland), it's not possible to restart GNOME anymore. See superuser.com/q/1164174/174311. Use gnome-keyring-daemon -r -c pkcs11,secrets to disable it in current session. – George Sovetov Feb 24 '18 at 12:51
  • It still works with Debian 9 (stretch). – Marc Wrobel Aug 24 '18 at 6:40
2

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
Improve this answer
2
  • 2
    This doesn't seem to work, at least not yet. Does it require GNOME 3.14 or 3.16 or gnome-keyring-daemon 3.12+? – andlabs Mar 9 '15 at 21:37
  • 3
    Anyone know what the ubuntu 16.04 version of above command is ? – Scott Stensland Apr 28 '16 at 22:43
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.

Improve this answer
1
  • This link seems to imply that using X-GNOME-Autostart-enabled=false, is deprecated. In any case it looks as if the Hidden property described in the autostart standard provides the same functionality. Use Hidden=true. gist.github.com/najamelan/b44e943145b03e018229 – nomadrc Sep 14 '17 at 20:50
2

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.

Improve this answer
1
  • 1
    Sorry for the late reply. That's what I thought I did do when I had Kubuntu (and it took a while to figure it out), but now I'm not as sure. As for now, though, since the keyring is a part of GNOME, removing that would remove ubuntu-gnome-desktop and a few other related components (oneconf, python-ubuntu-sso-client, seahorse, software-center, and ubuntu-sso-client, not counting software that becomes autoremove candidates as a result) :/ Thanks though; I'll upvote because it will help non-GNOME users who accidentally wind up in this situation like I did. – andlabs Mar 9 '15 at 21:34
0

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
Improve this answer
1
  • Hardcoding your keyring password is a bad idea from a security standpoint. Unlocking it automatically without user interaction seems even worse, you could stop using a keyring at all then. – DBX12 Mar 4 at 8:04
0

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

Improve this answer
0

For me, this worked great:

$ unset GNOME_KEYRING_CONTROL

I saw this solution here

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.