Bug 1205558

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

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.

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.

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.

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?

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.

Resetting to Rawhide since this is still an issue for all recent releases.

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.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

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.

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.

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.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
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 '29'.

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

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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.

AFAICS, this is an issue in Fedora 31.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
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 '31'.

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

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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.

I couldn't figure out a working way to disable gnome-keyring (secrets part). I tried copying the .desktop files to ~/.config/autostart/ and modify them in a number of ways to no avail. Also tried removing the .desktop files from /etc/xdg/autostart altogether, but that didn't work either. The only thing that actually worked was chmod ugo-x /usr/bin/gnome-keyring-daemon, and that seems like an idiotic solution to this problem. There has to be a better way, the Gnome Keyring manager should certainly not be such an integral part of the Fedora environment.

Could you please reopen this bug?
It still persists with Fedora 36.

Using sddm and KDM having gnome-key-ring starting makes no sense at all.

This issue still persists with Fedora 38
Only https://bugzilla.redhat.com/show_bug.cgi?id=1205558#c8 still works

I'm reopening this as this is still an issue with Fedora 38.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

This is indeed still an issue in the latest Fedora.

My current setup:
$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQChe8q8DxUvM+gcg0JzBJV4XOz24Q0U5ioJYJKBx/coZCMk+dYCMGm9j3xuHd8jgnwe2t+wVTyKN3NMIyccPVjIAF9gx8tJQzPANIYyI0WgCBjBOT8MDANXdGduUgUW+EvA1W3ARi5sScPVEDK2Lry8MHBjJivEvq2dq5saovTsQxL2PK7uNzpWAKHwznrnMk0uUWuA8ocFRU92lMVb43XKD2D9IaWpz24gwAFMU56wZS6wnYh1cY8H7IY51eKLzUVEPSkT+OAblK8PcUwsy0QS05YBZAGaqPCWKflZxV/YdNacL0SD5Ipx1Eo7wlj1Ad0PS4Q6yTs+cZ9C6G5RkcO7mobGPB9NKYHFfPuGwmLeA7AZj/Zh/LBjbbAksofNgSEmSBuTyyI5ngws49wfSX97C/krlqxwx3h04nKDaGQ8q/ray91/Y3HG7VQ+PCMBLmFX8rqvySF5UHOwjsvEraESInV8EX0Yfngoa6mAIIQQxZ8m4i5Px//PnBcYOIvRD50= mathieu@fedora
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC2MJZxs2m3o+1IxaI+XFPxoP92VS6o4lkApdZth5k0h8GF2OI8RuwHyapDjxMsByPRroZk/7yv1d2hPrMIc9fDb7MzKnpg6lUxtJ6//v3V3S/2DodxYEuCqyrM0W0mpiRC94JeMpKskKosmV5K9qNITlVnT+hrzJcqFZprC6yx4wOB4i1nv151chXvcsjaKYkej2wGXmsmaNh3V8vLeanZ/A/eziy+oX6Mz5RsR9cFFGRGK3oqBPbIai+82kHHWaKrT8U8z4r8cIvSyN2usLbV6M74X3vRTz3pYmlssxrWZ33YfGDtEBgYW0Wvw06lJy5EIQivIljipqxN5m8oJIxBNCgc+GIVhBlYa7eq+bcsH9eixtuJFkBlI4JT9SkOqnNPTtVzgIiO9A5E/uCgqyFPgynI+iesOdmPSFz3VBM6UbeQ8l5zLIqt5BcPLjpX3g6x6CltlCnCkorjgAxeYFBdXY225axy9G7u1ZubKa5Xx+Lycuo3DKk5WxQZMOE8Jrk= mathieu@fedora


So, I have two different keys with the same name that are valid for the same remote host/username but they do not have the same permissions on the remote host. i.e., I need to be able to load ONLY one OR the other, yet gnome-keyring autoloads both at the same time and ssh-add -D does not allow me to remove them.

I ended up doing this to disable the gnome-keyring ssh support and get back my dear old trusted friend ssh-agent:
sudo rm /etc/xdg/autostart/gnome-keyring-ssh.desktop
systemctl --user enable ssh-agent
systemctl --user start ssh-agent
echo 'export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"' >> ~/.profile

I am sure that this is not really the proper way to do this but, to echo Craig's initial comment, replacing gnome-keyring ssh support with ssh-agent is not very well documented.