"ssh-add -d" refused to remove identity

Question

In order to forget private keys passphrase (id_rsa) i usually run:

ssh-add -D # to forget all loaded identities
ssh-add -d # to forget primary identity ($HOME/.ssh/id_rsa)

Now with macOS Sierra v10.12.1 i get this error:

$ ssh-add -D
All identities removed.
$ ssh-add -d
Could not remove identity "/Users/user/.ssh/id_rsa": agent refused operation
Could not remove identity "/Users/user/.ssh/id_dsa": agent refused operation

I searched google with no luck!

score 11 · Accepted Answer · edited Mar 19 '20 at 16:43

11

I had the same issue with Sierra. Try removing id_rsa from $HOME/.ssh/ and then restarting (I removed id_rsa.pub as well - therefore the two keys private and public). It solved my problem.

edited Mar 19 '20 at 16:43

vonbrand

18,156
2
37
59

answered Dec 30 '16 at 00:28

Ali Cirik

226
2
5

That helped (High Sierra), thanks a lot! I have custom host redirects in ~/.ssh/config that weren't working coreclty. No restart needed... – CodingYourLife Jul 18 '18 at 12:15

Nels · Answer 2 · 2022-01-06T06:35:30.923

In my case, I had a slightly different problem. When I invoked ssh-add -D the agent appeared to succeed and responded with All identities removed. but in fact, when listing the agent keys ssh-add -l the unwanted keys remained listed, and of course, when attempting to use the agent to authenticate to a remote host the agent would prompt me using my configured pin program for a passphrase to the unwanted keys. Annoying.

The cause of the problem was that my gpg-agent daemon had cached the keys in a file at the path ~/.gnupg/sshcontrol:

$ cat ~/.gnupg/sshcontrol
# List of allowed ssh keys.  Only keys present in this file are used
# in the SSH protocol.  The ssh-add tool may add new entries to this
# file to enable them; you may also add them manually.  Comment
# lines, like this one, as well as empty lines are ignored.  Lines do
# have a certain length limit but this is not serious limitation as
# the format of the entries is fixed and checked by gpg-agent. A
# non-comment line starts with optional white spaces, followed by the
# keygrip of the key given as 40 hex digits, optionally followed by a
# caching TTL in seconds, and another optional field for arbitrary
# flags.   Prepend the keygrip with an '!' mark to disable it.

# RSA key added on: 2021-06-03 16:23:25
# Fingerprints:  MD5:c1:[elided]:24
#                SHA256:+Mj[elided]E4
21[elided]C9 0
# Ed25519 key added on: 2021-06-03 22:11:36
# Fingerprints:  MD5:[elided]:24:da
#                SHA256:EL[elided]Zs
E0[elided]47 0

Deleting those keys from the ~/.gnupg/sshcontrol allowed me to resume use of the gpg-agent to authenticate to remote hosts without the agent demanding a passphrase for keys which I was no longer using.

This is absolutely underrated. Thank you a lot. – Birkhoff Lee Dec 22 '21 at 13:55 — Birkhoff Lee, Dec 22 '21 at 13:55

score 6 · Answer 3 · answered Mar 04 '19 at 07:53

This error happened to me when the identity being referenced was different from the one that was added. The -d option removes a specific key. If that key was never loaded it refuses to remove it. You can check the keys loaded with ssh-add -l and check key signatures with ssh-keygen -lf <path-to-private-key>

score 4 · Answer 4 · answered Aug 12 '20 at 02:23

4

Had the same Issue, fixed with

  killall ssh-agent

  ssh-add -l

The agent has no identities.

answered Aug 12 '20 at 02:23

Touten

49
3

score 3 · Answer 5 · answered Mar 02 '21 at 09:00

I found that Ubuntu 18.04 still have this bug.

Here is my simple way to remove unwanted key(s) from ssh-agent without any significant effort:

Find the key you want to remove

ssh-add -l
2048 SHA256:qzJYF7AJAJsLsJn7ZFPcJ+w78ZJVoPZI9TzXCq2cf5 .ssh/bad-key.pem (RSA)

Go into your ~/.ssh directory and create sub-directory called for example, disabled
```
cd ~/.ssh
mkdir disabled
```
Move the key you want to disable into that directory.
```
mv bad-key.pem disabled/
```

That's it. The key should be no longer available in the ssh-agent, but you can still have it and add it back if you need to.

I found you have to move not just the private keys but the public keys as well. — jdhildeb, Aug 30 '22 at 22:16

score 0 · Answer 6 · answered May 17 '23 at 03:56

0

I just added a sudo at the beginning and that was the charm:

$ sudo ssh-add -d
Password:
$ ssh-add -l     
The agent has no identities.

answered May 17 '23 at 03:56

Miguel Zenteno

1

score 0 · Answer 7 · answered Jul 26 '23 at 23:55

I use hardware tokens (Yubikeys, etc) to manage much of my SSH auth (in combination with my GnuPG keychain).

I found that gpg-agent was handling the key, eventually leading me to the~/.gnupg/private-keys-v1.d directory.

~/.gnupg/private-keys-v1.d 
➜ ls

showed:

077E23C791B157F018B6BB44B0AEA9A1CDBF3633.key
2E60E50110529C5B53B6195AB8D9D05CB4D7075F.key
C2D6F78AF80269781836D70000B59FD21CF278DC.key
FD1EBAC7DCE8B6BD4C9A1B39CB36D284ACA21F2B.key

I deleted 2E60E50110529C5B53B6195AB8D9D05CB4D7075F.key (your fingerprint will be different).

After I did that, I ran:

ssh-add -D

All identities removed.

I noticed that the cache was clear:

~/.gnupg/private-keys-v1.d 
➜ ssh-add -L

The agent has no identities.

I got tipped off when I ssh-added the key, a window popped up asking if I wanted the key stored "within gpg-agent's key storage."

score -1 · Answer 8 · answered Jun 29 '20 at 08:04

-1

If none of the above works, for me it was the ~/.gnupg/sshcontrol where the keys got "cached".

https://wiki.archlinux.org/index.php/GnuPG#SSH_agent

answered Jun 29 '20 at 08:04

BrutalBirdie

1

1

Welcome to the site and thank you for your contribution. Would you mind editing your post to summarize the steps necessary to solve the OPs problem? Answers that rely (mostly) on external links are less useful because the link (and the linked content) can change, making the answer invalid. – AdminBee Jun 29 '20 at 08:55

"ssh-add -d" refused to remove identity

8 Answers8