Bug#472477: ssh-add -D does not remove SSH key from gnome-keyring-daemon memory
Arnaud Cornet
Version: 2.22.0-2
Severity: important
Steps to reproduce:
# ssh-add -l
1024 XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
# ssh-add -D
All identities removed.
# ssh-add -l
1024 XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
I am still able to log in with this key afterwards.
This is a security issue since gnome-keyring-daemon seems to have
transparently taken over ssh-agent. One might think he's key is unloaded
after a ssh-add -D while it's not.
I cannot even find a way to remove the key in gnome-keyring-manager GUI.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gnome-keyring depends on:
ii gconf2 2.22.0-1 GNOME configuration database syste
ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii libc6 2.7-9 GNU C Library: Shared libraries
ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra
ii libdbus-1-3 1.1.20-1 simple interprocess messaging syst
ii libgconf2-4 2.22.0-1 GNOME configuration database syste
ii libgcrypt11 1.4.0-3 LGPL Crypto library - runtime libr
ii libglib2.0-0 2.16.1-2 The GLib library of C routines
ii libgtk2.0-0 2.12.9-2 The GTK+ graphical user interface
ii libhal-storage1 0.5.11~rc2-1 Hardware Abstraction Layer - share
ii libhal1 0.5.11~rc2-1 Hardware Abstraction Layer - share
ii libpango1.0-0 1.20.0-1 Layout and rendering of internatio
ii libtasn1-3 1.3-1 Manage ASN.1 structures (runtime)
Versions of packages gnome-keyring recommends:
ii libpam-gnome-keyring 2.22.0-2 PAM module to unlock the GNOME key
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Loïc Minier
> Steps to reproduce:
> # ssh-add -l
> 1024 XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
> # ssh-add -D
> All identities removed.
> # ssh-add -l
> 1024 XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
>
> I am still able to log in with this key afterwards.
>
> This is a security issue since gnome-keyring-daemon seems to have
> transparently taken over ssh-agent. One might think he's key is unloaded
> after a ssh-add -D while it's not.
>
> I cannot even find a way to remove the key in gnome-keyring-manager GUI.
Are you sure "ssh-add -D" above is removing keys from g-k? I wonder
whether it could be removing keys from ssh-agent but ssh-add -l would
list them from g-k. You could try unsetting the gconf key for the ssh
component of g-k.
--
Loïc Minier
Arnaud Cornet
> whether it could be removing keys from ssh-agent but ssh-add -l would
> list them from g-k.
ssh-agent was not running during the test.
ssh-add says the key is removed, but it is still in g-k.
Marco Ippolito
> On Fri, 19 Sep 2014 20:35:41 +0100 Pedro Beja <alth...@gmail.com> wrote:
> > this is an old bug.
> >
> > Could you please still reproduce this issue with newer gnome-keyring
> version like 3.4.1-5 or 3.12.2-1 ?
>
> Still happening with gnome-keyring 3.14.0-1+b1 and openssh-client
> 1:6.7p1-2 on jessie.
>
> $ echo $SSH_AUTH_SOCK
> /run/user/1000/keyring/ssh
Still happening on: Sun 13 May 17:00:21 CEST 2018
Using: gnome-keyring 3.20.0-3, openssh-client 1:7.4p1-10+deb9u3
ps -o args= "$SSH_AGENT_PID":
/usr/bin/ssh-agent /usr/bin/im-launch x-session-manager
$SSH_AUTH_SOCK:
/run/user/1000/keyring/ssh
Jérôme
I'm using Debian Stretch/Mate and I had SSH Gnome keyring launched at
startup (install default, I guess).
Indeed I do see gnome-keyring in ps ax:
1255 ? Sl 0:03 /usr/bin/gnome-keyring-daemon --daemonize
--login
While testing ssh keys, I created a key and added a .ssh/config file
with this content:
Host github.com
IdentityFile ~/.ssh/github-test.key
I checked I could connect.
Then I removed the file and even the key itself. And I could still
connect (!).
I figured keys must be cached somehow and found out about ssh-agent.
I tried to delete the key cache using
ssh-add -D
And althouth it says
All identities removed.
all the keys in the cache still appear when running
ssh-add -l
echo $SSH_AGENT_PID
1336
ps ax:
1336 ? Ss 0:04 /usr/bin/ssh-agent x-session-manager
gnome-keyring 3.20.0-3
openssh-client 1:7.4p1-10+deb9u4
I have no idea what more I could provide to turn this message into
something helpful...
--
Jérôme
Alex King
I can't log in to some remote machines because there are too many keys
loaded, and gnome-keyring-daemon won't remove them.
I have been affected by this quite a few times over the years, it has
wasted hours of my time. It means I need to use workarounds which just
cause unnecessary effort.
This prevents ssh working. It is a potential security bug. It would be
great if the gnome maintainers could do something about it after 12 years.
Thanks,
Alex
Peter Matulis
Clément Hermann
So, my workaround for this annoying issue was to use gpg-agent instead.
As a nice side effect, you can then use a gpg key to authenticate.
The tricky part for me was to make sure gnome woudn't try to set
SSH_AUTH_SOCK to gnome keyring anyway.
In case others want to go this route, here is what I've done:
- make sure your gpg-agent can handle ssh agent role by including
`enable-ssh-support` in ~/.gnupg/gpg-agent.conf
(you can also set ttls there while you're at it if you want, e,g,
`default-cache-ttl-ssh 1200`, `max_cache_ttl-ssh 7200`)
- disable ssh component of gnome-keyring in systemd user units:
```
systemctl --user mask gcr-ssh-agent.socket --now
systemctl --user mask gcr-ssh-agent.service --now
```
- disable ssh component of gnome-keyring also in XDG autostart by adding
the Hidden property:
```
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
echo "Hidden=true" >> ~/.config/autostart/gnome-keyring-ssh.desktop
```
Then restart the session.
Be aware that when you use ssh-add for the first time when having the
gpg-agent socket in SSH_AUTH_SOCK, you'll be first prompted by ssh-add,
then by gpg-agent. Set a passphrase in gpg-agent when prompted,
otherwise it will be stored in clear in your private keys. Usual
gpg-agent stuff applies, it will lock whenever you lock the session, you
get a timeout, etc.
Cheers,
--
nodens
Henrik Ahlgren
ssh-add -D not removing ed25519 keys still remains in 2023. When
investigating this, I noticed that in the default configuration, there
are at least FIVE separate SSH agent processes running:
1. gnome-keyring-daemon process (the buggy one), listening to socket
/run/user/$UID/keyring/ssh, which $SSH_AUTH_SOCK points by default (at
least in a GNOME session).
2. OpenSSH ssh-agent process forked buy the previous process,
listening to socket /run/user/$UID/keyring/.ssh, and working normally
(if you point $SSH_AUTH_SOCK there).
3. Another OpenSSH ssh-agent process started by ssh-agent.service
(shipped by openssh-client package), listening to socket
/run/user/$UID/openssh_agent, and working as expected.
4. gcr-ssh-agent process listening to socket /run/user/$UID/gcr/ssh
with the same buggy behaviour wrt ed25519 keys.
5. Third OpenSSH ssh-agent process started by the previous process
gcr-ssh-agent, listening to socket /run/user/$UID/keyring/.ssh, again
working normally, since it's just the standard ssh-agent.
ed25519 keys are very common today, so the default configuration
should handle them correctly. And what is the point of having multiple
copies of the same agent running, when none of them are even used
unless the user explicitly change their $SSH_AUTH_SOCK configuration?
Please coordinate with all related package maintainers to fix this mess
before trixie is released.