Bug 1205558 - No documented or discoverable way to disable gnome-keyring ssh and gpg
Summary: No documented or discoverable way to disable gnome-keyring ssh and gpg
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-keyring
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-25 08:15 UTC by Craig Ringer
Modified: 2019-05-20 07:33 UTC (History)
12 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-12-02 10:30:57 UTC


Attachments (Terms of Use)

Description Craig Ringer 2015-03-25 08:15:59 UTC
There is no documented, standard way to disable gnome-keyring-daemon's gpg and ssh agent hijacking, or to restore the real ssh agent.

This is an issue because gnome-keyring-daemon:

* doesn't allow users to flush credentials using ssh-add -D or -d (bug #1205546)

* doesn't allow credential expiry to be set via ssh-add -t (bug #588080)

* doesn't have mature and reliable PKCS#11 smartcard support for gpg-agent

* keeps credentials over suspend/hibernate (#1205552) and doesn't respect agent commands in hook scripts to flush credentials like the real ssh-agent does

* doesn't respect --no-ask which can break scripting (#1071586) and result in surprise modal dialogs

* Offers no easy way to clear credentials. GNOME's "passwords and keys" CP will *delete* them for you, but doesn't have a "clear cached keys" option.


There is no GUI option to disable the agent in the "passwords and keys" CP, gnome-tweak-tool, or elsewhere in GNOME.

The method to disable the agent has changed several times. Even when the agent is disabled the normal ssh-agent is not started.


To disable the gnome-keyring-daemon's ssh and gpg support on Fedora 21 (GNOME 3.14):

* Edit

  /etc/xdg/autostart/gnome-keyring-gpg.desktop
  /etc/xdg/autostart/gnome-keyring-ssh.desktop

  to append "Hidden=true", or copy them to ~/.config/autostart/
  in your user profile and append "Hidden=true" to the copies.

* Create /etc/X11/xinit/xinitrc.d/ssh-agent.sh with content (no indent):

  #!/bin/bash
  eval `ssh-agent`

* chmod a+x /etc/X11/xinit/xinitrc.d/ssh-agent.sh


Ideally GNOME would start the real ssh agent if the keyring's agent was disabled.

Comment 1 Matthias Clasen 2015-04-09 13:14:13 UTC
> There is no documented, standard way to disable gnome-keyring-daemon's gpg and 
> ssh agent hijacking, or to restore the real ssh agent.

xdg autostart is a fairly well-established way of starting things automatically in the user session. I don't think characterizing it as undocumented and nonstandard is accurate. But that matches with the tone of the rest of this complaint.

Comment 2 Tomas Vondra 2015-06-05 14:41:55 UTC
I see nothing wrong with the tone of Craig's post, and it rather seems like an easy way out of this ticket - just claim you don't like the *perceived* tone.

I don't know what exactly you mean by "well-established", but unless it's documented somewhere, it's of no use for regular users. I'm using Linux for 15+ years but with Fedora I'm a mere user, and I've been unable to solve this exact issue no matter how much I tried, searched for documentation etc.

What I tried so far:

1) exactly the things Craig described

2) remove all gnome-keyring-*.desktop files from all the locations

3) remove all keyring-related items from gnome-session-properties

4) comment out all keyring stuff from /etc/pam.d/*

And guess what - nothing worked, the keyring daemon is still getting started for some reason. What eventually did the trick eventually was 'chmod -x /usr/bin/gnome-keyring-daemon'. So much for the 'well-established' part.

Regarding the gnome-keyring trickery - all of those are effectively security issues, IMNSHO.

Comment 3 Fedora End Of Life 2015-11-04 11:07:01 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Fedora End Of Life 2015-12-02 10:31:02 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 5 David Woodhouse 2016-12-09 11:34:34 UTC
Reopening as this is still an issue in Fedora 25. See also 
https://ask.fedoraproject.org/en/question/92448/how-do-i-get-proper-ssh-agent-functionality-in-gnome/

I think we should probably expand the scope, in fact. Rather than "make it easy to disable" I think perhaps we should actually disable it by *default* in favour of the 'real' ssh-agent and gpg-agent.

Quoting stefw from https://bugzilla.gnome.org/show_bug.cgi?id=641082#c17 : 
> Yes, exactly Ed25519 is what removed the doubt any doubt in my mind that I 
> don't want to be maintaining a whole reimplemented ssh agent.

If we don't want to be maintaining it, we don't want to be enabling it by default either. Stef, what do you think?

What functionality do we lose if we switch from gkr's SSH agent back to the OpenSSH one?

Comment 6 David Woodhouse 2016-12-09 11:43:35 UTC
FWIW the reason I'm looking at this right now is because gkr's implementation is also missing 'ssh-add -s <PKCS#11 provider>' support, in addition to the list above.

Comment 7 Björn 'besser82' Esser 2017-09-07 10:24:51 UTC
Resetting to Rawhide since this is still an issue for all recent releases.

Comment 8 Björn 'besser82' Esser 2017-09-07 10:29:28 UTC
Until this is resolved:

You can disable that horrible default replacement of $MY_REAL_SSH_AGENT on a per-user setting by running

`sed -e 's~^X-GNOME-Auto~#&~g' < /etc/xdg/autostart/gnome-keyring-ssh.desktop > ~/.config/autostart/gnome-keyring-ssh.desktop``

from the terminal.

Comment 9 Fedora End Of Life 2018-02-20 15:23:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 10 James Boyle 2018-07-05 19:04:11 UTC
Hello,

I had previously built gnome-keyring from source with the option '--disable-ssh-agent' to deal with the lack of ECDSA & ED25519 support.  I recently upgraded to Fedora 28 / MATE (which uses gnome-keyring) and thought, "oh, neat, it's working out of the box."  My feeling of elation was crushed shortly thereafter when I tried to log into a system I log into frequently.  SSH responded with the error "too many authentication failures" and I though to myself, "gee that's strange".  It didn't take long to figure out why.  Running 'ssh-add -l' showed that all eighteen (18) of my SSH keys had been added.  Of course I checked 'man ssh-add' which indicates that the expected behavior of ssh-add with no options will add the four default named keys, $HOME/.ssh/id_{dsa,rsa,ecdsa,ed25519}.  I tried to flush the loaded keys with 'ssh-add -D', and, as others have documented, that failed as well.

I'm mildly appalled, yet not surprised that gnome-keyring won't let you flush the keys from memory.  What a frightening to me is that gnome-keyring goes out of its way to load every possible SSH key in $HOME/.ssh/, but doesn't display that it's done so.  

*When you run 'ssh-add' it only reports that the 4 default keys have been loaded.*

Only later, when you query it with 'ssh-add -l' do you have any indication that every SSH key has been loaded.  (This is why I experienced "too many authentication failures")

This may be unreasonable on my part, but, I expect the system to behave as described in the manuals.  'man ssh-add' describes a set of behaviors, including 'ssh-add -D' and what is loaded by default when 'ssh-add' is run.

I was disappointed 5 years ago when I discovered, that in Fedora, we don't really run ssh-agent (https://bugzilla.redhat.com/show_bug.cgi?id=1027280) and that gnome-keyring masquerades as ssh-agent, without being able to do the job.  And, even though it now supports ECDSA and ED25519, it's hard to feel good about poseur software that doesn't follow the well documented behavior of the software it intends to mimic.  This latest disappointment has led me again revert to building gnome-keyring from source.

I'm okay if my tone is interpreted as insistent, upset, pushy, aggravated, sarcastic, or any other type of tone that might give someone claim to victimhood.  I truly feel that Fedora can, and should, do better. 

The original problem description lists factual deficiencies in gnome-keyring's attempt to emulate ssh-agent.  The software component selected for this bug is "gnome-keyring" and not xdg.  Since users are experiencing problems when using gnome-keyring, they are trying to share their ways of working around the problems or illicit other, perhaps better ways.  

In that helpful spirit, here's my _very rough_ outline on building gnome-keyring from source with its ssh-agent emulation disabled:
$ sudo dnf install rpmdevtools intltool {libcap-ng,libgcrypt,libselinux,pam,gcr,glib,p11-kit}-devel pkgconfig docbook-dtds docbook-style-xsl gcc{,-c++}
# add user/group mockbuild to the system
$ cd $HOME
$ rpmdev-setuptree
$ cd rpmbuild/SRPMS
$ dnf download --source gnome-keyring
$ cd ~/rpmbuild
$ rpm -ivh SRPMS/gnome-keyr*

# edit SPECS/gnome-keyring.spec:
  Release: 1_custom%{?dist}
  %configure \
    --disable-ssh-agent \
    --with-pam-dir=%{_libdir}/security \
    --enable-pam

$ rpmbuild -bb SPECS/gnome-keyring.spec
$ sudo dnf upgrade RPMS/x86_64/gnome-keyring-*

I'm hoping that 2018 will be the year that either Fedora or Gnome gives Fedora users an out of the box experience where ssh-add, et al., behave as expected.  Alternately, someone can take the easy way out and document the deficiencies and workarounds so that users can more easily switch to ssh-agent when gnome-keyring doesn't meet their needs.

Comment 11 Ben Cotton 2019-05-02 21:00:12 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Dave 2019-05-20 02:44:46 UTC
This still appears to be a problem on fedora29 and hoped someone might have a current workaround.

I'm trying to use a gnupg password cracker (https://www.vanheusden.com/nasty/) on some private keys, and each time it runs it prompts gnome-keyring (pinentry-gnome3?) to enter a passphrase.


Note You need to log in before you can comment on or make changes to this bug.