ssh-add -D deleting all identities does not work. Also, why are all identities auto-added?

[LimCore]

ssh-add -D seems to NOT remove my identities, even though it says it did.

Also, why are all possible identities auto-added right away (on start?)

rafal@lcwood(22:11:48)~$ ssh-add -l
8192 d1:50:43:64:52:7d:a0:61:ad:e2:bb:17:35:0d:7f:7d rafal1-rafal@lcwood (RSA)
8192 d8:f9:52:6d:d7:44:e2:fe:7d:72:78:f4:09:f7:4a:82 lcac_rafal_2_geovoucher_vm-rafal@aclc (RSA)
8192 1c:de:80:66:b2:c0:59:ff:03:61:58:43:ea:f5:b0:58 rafalsvn-rafal@lcwood (RSA)
8192 1b:7b:5b:a5:bf:40:7c:50:48:6f:5a:9b:f5:b3:43:1b rafaladmin-rafal@lcwood (RSA)

rafal@lcwood(22:11:50)~$ ssh-add -D
All identities removed.

rafal@lcwood(22:11:51)~$ ssh-add -l
8192 d1:50:43:64:52:7d:a0:61:ad:e2:bb:17:35:0d:7f:7d rafal1-rafal@lcwood (RSA)
8192 d8:f9:52:6d:d7:44:e2:fe:7d:72:78:f4:09:f7:4a:82 lcac_rafal_2_geovoucher_vm-rafal@aclc (RSA)
8192 1c:de:80:66:b2:c0:59:ff:03:61:58:43:ea:f5:b0:58 rafalsvn-rafal@lcwood (RSA)
8192 1b:7b:5b:a5:bf:40:7c:50:48:6f:5a:9b:f5:b3:43:1b rafaladmin-rafal@lcwood (RSA)
rafal@lcwood(22:11:53)~$ apport-bug ssh-ad

ProblemType: Bug
Architecture: amd64
Date: Sat Jan 9 22:12:25 2010
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: ssh (not installed)
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: openssh
Uname: Linux 2.6.31-16-generic x86_64

[C de-Avillez (hggdh2)]

Confirming:

cerdea@xango:~/Can$ ssh-add -l
2048 7d:01:74:bd:a6:7f:58:3f:57:e0:1b:da:a0:31:a8:ae hggdh@xango2 (RSA)
cerdea@xango:~/Can$ ssh-add -D
All identities removed.
cerdea@xango:~/Can$ ssh-add -l
cerdea@xango:~/Can$ apt-cache policy openssh-client
openssh-client:
  Installed: 1:5.2p1-1ubuntu1
  Candidate: 1:5.2p1-1ubuntu1
  Version table:
 *** 1:5.2p1-1ubuntu1 0
        500 http://archive.ubuntu.com lucid/main Packages
        100 /var/lib/dpkg/status
cerdea@xango:~/Can$

2048 7d:01:74:bd:a6:7f:58:3f:57:e0:1b:da:a0:31:a8:ae hggdh@xango2 (RSA)
cerdea@xango:~/Canonical$

[C de-Avillez (hggdh2)]

Somehow I overwrote part of the above. The test is here:

cerdea@xango:~/Can$ ssh-add -l
2048 7d:01:74:bd:a6:7f:58:3f:57:e0:1b:da:a0:31:a8:ae hggdh@xango2 (RSA)
cerdea@xango:~/Can$ ssh-add -D
All identities removed.
cerdea@xango:~/Can$ ssh-add -l
2048 7d:01:74:bd:a6:7f:58:3f:57:e0:1b:da:a0:31:a8:ae hggdh@xango2 (RSA)
cerdea@xango:~/Can$

[LimCore (limcore)]

Reported to upstream as https://bugzilla.mindrot.org/show_bug.cgi?id=1695

[LimCore (limcore)]

Upstream says that this is security vulnerability.
I agree.
An important one too!

User can have action (like shortcut, screensaver, timeout, whatever) that does ssh-key -D,
and he expect that his SSH keys are now secure... while they are still accessible!

Upstream also says its most likely a problem with seahorse or other ssh agent; Although when I killed all my agents (seahorse*, ssh-agent) the same problem seemed to exist still - read comments in upstream bug report.

[LimCore (limcore)]

* typo, I ment of course ssh-add -D not ssh-key

[Rafal-maj-it (rafal-maj-it)]

First reported by me as https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/505278

Example:

$ ssh-add -l
2048 7d:01:74:bd:a6:7f:58:3f:57:e0:1b:da:a0:31:a8:ae hggdh@xango2 (RSA)
$ ssh-add -D
All identities removed.
$ ssh-add -l
2048 7d:01:74:bd:a6:7f:58:3f:57:e0:1b:da:a0:31:a8:ae hggdh@xango2 (RSA)

In Ubuntu 9.10 and Lucid (alpha)

[Damien Miller (djm)]

Are you using ssh-agent or the GNOME thing that Ubuntu uses?

[Rafal-maj-it (rafal-maj-it)]

I was not starting myself the ssh-agent.

It seems ssh-agent is alwasy started for logged in user, on Ubuntu 9.04, like:
/usr/bin/ssh-agent /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/userfoo/.gnupg/gpg-agent-info-lcwood /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute gnome-session

After killall ssh-agent (and no ps aux ssh-agent for my user) still there is identical problem, ssh -l shows all keys, -D does not change anything.

[Damien Miller (djm)]

ok, so the problem is with whatever ssh-agent that Debian is using (probably seahorse-agent). They aren't using the OpenSSH one.

The problem is not with OpenSSH's ssh-add - it just sends the "delete all keys" message (specified in [1]) and trusts that the agent does the right thing. OpenSSH's certainly does.

I suggest that you follow up with the developers of seahorse-agent - this is a significant security bug as it could leave keys exposed when the user thought they deleted them.

[1] http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD

[Rafal-maj-it (rafal-maj-it)]

Hmm but killing everything reported by ps aux | grep ssh-agent and grep seahorse, including dbus session, did not help, still ssh-add -l lists all my keys.

killall seahorse-daemon seahorse-agent ssh-agent

If all of this are killed then who is still keeping my keys?

[Colin Watson (cjwatson)]

As described upstream, this appears to be the fault of seahorse, not openssh.

[Sebastien Bacher (seb128)]

the issue is rather a gnome-keyring one, seahorse does gpg not ssh...

[Martin von Wittich (martin.von.wittich)]

I'm having the same issue on a Fedora 10 machine; Seahorse is not installed and ssh-agent is not running. I believe the buggy agent that is causing this is gnome-keyring-daemon.

[Sebastien Bacher (seb128)]

The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

[Damien Miller (djm)]

Mass move of bugs RESOLVED->CLOSED following the release of openssh-5.5p1

[Rafal-maj-it (rafal-maj-it)]

This bug looks like medium priority since it can totally block some ssh connections in following way:
user with many keys connects to some server(s) and all his keys are cached.

When he tries to ssh to another server, or filezilla sftp into it, or sshfs, or many other pubkey usecases, then often first all the keys will be tried, often resulting in server disconnecting (instead of tyring the correct key or instead of using the given plain password).

In example Firezilla appears to first try all pubkeys of the user that started firezilla and that are in the agent (as seen on debug on server-side) instead of first using the given plain password.
Then ssh-agent -D does not help to resolve the problem.

[Jim Shankland (jas-shankland)]

The culprit is gpg-keyring-daemon. It subverts the normal operation of ssh-agent, mostly just so that it can pop up a pretty box into which you can type the passphrase for an encrypted ssh key. And it paws through your .ssh directory, and automatically adds any keys it finds to your agent. And it won't let you delete those keys. How do we hate this? Let's not count the ways -- life's too short.

The failure is compounded because newer ssh clients automatically try all the keys in your ssh-agent when connecting to a host. If there are too many, the server will reject the connection. And since gnome-keyring-daemon has decided for itself how many keys you want your ssh-agent to have, and has autoloaded them, AND WON'T LET YOU DELETE THEM, you're toast.

What you really want to do is to turn off gpg-keyring-daemon altogether. Go to System --> Preferences --> Startup Applications, and unselect the "SSH Key Agent (Gnome Keyring SSH Agent)" box -- you'll need to scroll down to find it.

You'll still get an ssh-agent, only now it will behave sanely: no keys autoloaded, you run ssh-add to add them, and if you want to delete keys, you can. Imagine that.

[Marty Combs (cdpqbln4t)]

Has this bug been fixed in gpg-keyring-daemon? Neither solution proposed is workable for me. Leaving Gnome Keyring running hits the error of too many authentication attempts. Disabling the Gnome Keyring SSH Agent disables ssh-agent on Ubuntu login (10.04 64-bit AMD) - 'ps' shows no agent running.

It seems an important feature to be able to disable automatic loading of all keys in .ssh for users like myself who have multiple keys stored for different binaries/processes.

[Andres Riancho (andres-riancho)]

Confirmed in 12.04 LTS. It's awful to see that this has been around since January 2010.

[Derek Simkowiak (derek-x)]

Confirmed in 14.04.4

[Seth Arnold (seth-arnold)]

Derek, what is 14.04.4? 12.04.4 or 14.04.1? Thanks

[Eduard Hasenleithner (eduard-hasenleithner)]

Confirmed on 14.04.1. I'm irritated that security related bugs can have "low" priority.

[Nathan Neulinger (nneul-0)]

For those that are winding up at this bug report from searches looking to resolve the problem - regardless of platform, here's a quick "fix":

  * Move the keys out of ~/.ssh
  * gnome-keyring-daemon -r -d

It's certainly not an actual fix, but will at least resolve the immediate annoyance.

More info here:

https://wiki.archlinux.org/index.php/GNOME_Keyring

[kayandus (bierfiltertje)]

This isn't a bug, it's a feature. Read the gnome-keyring website carefully, https://wiki.gnome.org/Projects/GnomeKeyring/Ssh

[quote]
This assumes some familiarity with the ssh-add command. See its man page for more info.
    You can use ssh-add to manually add keys for use in the SSH agent. These will be in addition to the automatically loaded keys.
    The ssh-add -D will remove any keys you've added manually.
    The ssh-add -D will lock any automatically loaded keys.
    ssh-add -l and ssh-add -L will always list automatically loaded keys.
[/quote]

This is exactly what happens in 14.04; automatically loaded keys get locked, manually added keys get removed from the agent.

Automatically loaded keys are:
[quote]
The SSH agent automatically loads files in ~/.ssh which have corresponding *.pub paired files. Additional SSH keys can be manually loaded and managed via the ssh-add command.
[/quote]

On a side note, it seems 14.04 also starts the openssh 'ssh-agent' automatically, so effectively running two agents by default (is this intentional?). Ssh-agent stores its socket in /tmp. Try something like:

SSH_AUTH_SOCK=/tmp/ssh-ABCDEF123456/agent.12345 ssh-add

[kayandus (bierfiltertje)]

Nevermind the last part, it seems I hit a very actual discussion/fix: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1271591

[lepidas blades rompolos (lepidas)]

16.04 still this bug. and this is not a bug, not a back door but a front one.
Look at this scenario.
Iam at home with people, I do create keys and store passphrase to agent to connect to remote host.
One moment later I decide to remove passphrase from agent ssh-add -D ok great now server is safe.
History | grep ssh
ssh idiot_server and voile!