How can I remove an SSH key?

Asked 23/8, 2014 at 18:13 Answered 8/10, 2022 at 5:9

Solved git ssh git-svn ssh-keys ssh-keygen

270

I currently have an old SSH key uploaded on a server. The problem is I lost my ~/.ssh directory (with the original id_rsa and id_rsa.pub files).

Consequently, I want to remove the old SSH key directly on the server and upload a new one.

I tried the following command without success:

$> ssh-add -D

Enter image description here

Is there a way to completely remove an SSH key?

Hoar answered 23/8, 2014 at 18:13 Comment(3)

What with ssh-add -d ? – Expiate 23/8, 2014 at 18:21

damnit, it is ssh-add -D, uppercase – Overblouse 9/2, 2017 at 6:23

Check your sockets that are being used by your ssh-agent(1). – Habitual 15/3, 2017 at 17:19

200

Note that there are at least two bug reports for ssh-add -d/-D not removing keys:

The exact issue is:

ssh-add -d/-D deletes only manually added keys from gnome-keyring.
There is no way to delete automatically added keys.
This is the original bug, and it's still definitely present.

So, for example, if you have two different automatically-loaded ssh identities associated with two different GitHub accounts -- say for work and for home -- there's no way to switch between them. GitHubtakes the first one which matches, so you always appear as your 'home' user to GitHub, with no way to upload things to work projects.

Allowing ssh-add -d to apply to automatically-loaded keys (and ssh-add -t X to change the lifetime of automatically-loaded keys), would restore the behavior most users expect.

More precisely, about the issue:

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.

This bug is still confirmed in Ubuntu 14.04.4, as recently as two days ago (August 21st, 2014)

A possible workaround:

Do ssh-add -D to delete all your manually added keys. This also locks the automatically added keys, but is not much use since gnome-keyring will ask you to unlock them anyways when you try doing a git push.

Navigate to your ~/.ssh folder and move all your key files except the one you want to identify with into a separate folder called backup. If necessary you can also open seahorse and delete the keys from there.

Now you should be able to do git push without a problem.

Another workaround:

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.

This comments actually suggests:

The solution is to keep gnome-keyring-manager from ever starting up, which was strangely difficult by finally achieved by removing the program file's execute permission.

Ryan Lue adds another interesting corner case in the comments:

In case this helps anyone: I even tried deleting the id_rsa and id_rsa.pub files altogether, and the key was still showing up.

Turns out gpg-agent was caching them in a ~/.gnupg/sshcontrol file; I had to manually delete them from there.

That is the case when the keygrip has been added as in here.

Agaric answered 23/8, 2014 at 18:37 Comment(14)

Another option in Ubuntu 14-16 is to use the gui 'Passwords and keys' (you can seach for ssh to find it) . Choose which eg OpenSS keys, then right click on the key and choose delete. You may need to restart your system to see it that it's removed. – Huxham 21/11, 2016 at 13:45

Why is this info about the ssh-agent and ssh-add the selected answer? The original poster said he wants to remove the old SSH key directly on the server and upload a new one. That sounds like he wants to edit ~/.ssh/authorized_keys on the remote host. – Yeaton 26/1, 2017 at 6:25

@Yeaton I agree ssh-add -D and authorized_keys are two different operations/items, as illustrated in askubuntu.com/a/490107/5470. But the question was centered around the inability to remove that (passphrase-protected) key from the ssh agent. I suppose the authorized_keys update part was done independently. – Agaric 26/1, 2017 at 8:9

@VonC, by the way, to remove the keys on the client host, optionally do this: ssh-add -l and count how many keys there are perhaps by piping to wc. Then rm ~/.ssh/id_rsa ~/.ssh/id_rsa.pub Then optionally do this:ssh-add -l and you will see there is a different count. In other words, deletion from the agent is automatic if you delete from the file system. – Yeaton 26/1, 2017 at 9:2

@Huxham that deletes the key from disk - when one wants to delete a key from one's agent, one does not want to throw away the key forever! – Leibniz 15/2, 2017 at 10:41

This answer lead me to solve a problem showing up with ssh forwarding enabled. Going from an Ubuntu 16.04 machine to a debian system where all ssh credentials are being forwarded a git clone was using the first key in the chain instead of the version in the config file on the Ubuntu box. The bad key was getting sucked in automatically and forwarded to the Debian box. – Lifeboat 16/2, 2017 at 5:51

Just got bit by this bug on Ubuntu 18.04. Thanks a lot for this answer! – Endosmosis 6/11, 2018 at 1:54

This is a real pain in the rear. I'm working on company projects and contracted to work under another company. This just adds wasted time to managing both. I hope a fix comes soon! – Phung 4/3, 2019 at 13:31

In case this helps anyone: I even tried deleting the id_rsa and id_rsa.pub files altogether, and the key was still showing up. Turns out gpg-agent was caching them in a ~/.gnupg/sshcontrol file; I had to manually delete them from there. – Thumbstall 28/1, 2020 at 7:6

@RyanLue Thank you. Very interesting. I have included your comment in the answer for more visibility. – Agaric 28/1, 2020 at 7:11

for ` if you have two different automatically-loaded ssh identities associated with two different GitHub accounts -- say for work and for home -- there's no way to switch between them. GitHubtakes the first one which matches, so you always appear as your 'home' user to GitHub, with no way to upload things to work projects.` , I set IdentitiesOnly to true in my ~/.ssh/config TO ingoring the ssh-agent – Aluino 16/7, 2020 at 18:44

@Aluino Switch between them from within one repository? Because for multiple repos, I always use ~/.ssh/config entry, which allows me to reference the exact key I want. – Agaric 16/7, 2020 at 19:16

you #@$@!#! i ruined all my keys by running -D . – Choosy 9/9, 2022 at 9:23

@SimpleFellow Can you add those keys back to the agent? I mean -D does not delete the actual key file, right? – Agaric 9/9, 2022 at 9:46

Before Remove Identity You need to start ssh-agent with this command

eval `ssh-agent -s`

For Remove All Identity

ssh-add -D

To Remove Specific Identity

ssh-add -d ~/.ssh/sshkeynamewithout.pub

For Find a List of available Identify by using this command

ssh-add -l

Add new ssh key after all delete

ssh-add ~/.ssh/sshkeywithoutpub

Spoony answered 1/9, 2022 at 15:51 Comment(2)

Is it possible to remove a specific key listed by ssh-add -l without referencing it by filename? I have a Yubikey from which SSH keys are added to the agent via ssh-add -K, hence their don't exist any files within the .ssh/ directory. – Denison 13/1, 2023 at 13:12

worked ssh-add -d ~/.ssh/sshkeynamewithout.pub – Sabellian 7/2 at 11:26

If you're trying to perform an SSH-related operation and get the following error:

$ git fetch
no such identity: <ssh key path>: No such file or directory

You can remove the missing SSH key from your SSH agent with the following:

$ eval `ssh-agent -s`  # start ssh agent
$ ssh-add -D <ssh key path>  # delete ssh key

Radial answered 7/6, 2018 at 17:30 Comment(0)

Check if folder .ssh is on your system

Go to folder --> /Users/administrator/.ssh/id_ed25519.pub

If not, then

Open Terminal.

Paste in the terminal

Check user → ssh -T [email protected]

Remove existing SSH keys

Remove existing SSH keys → rm ~/.ssh/github_rsa.pub

Create New

Create new SSH key → ssh-keygen -t rsa -b 4096 -C "[email protected]"
The public key has been saved in "/Users/administrator/.ssh/id_ed25519.pub."
Open the public key saved path.
Copy the SSH key → GitLab Account → Setting → SSH Key → Add key
Test again from the terminal → ssh -T [email protected]

Interflow answered 2/1, 2020 at 8:14 Comment(1)

What if ssh-key is used to connect to remote servers and removing and generating a new key is not an option? – Lusk 18/12, 2020 at 2:44

Unless I'm misunderstanding, you lost your .ssh directory containing your private key on your local machine and so you want to remove the public key which was on a server and which allowed key-based login.

In that case, it will be stored in the .ssh/authorized_keys file in your home directory on the server. You can just edit this file with a text editor and delete the relevant line if you can identify it (even easier if it's the only entry!).

I hope that key wasn't your only method of access to the server and you have some other way of logging in and editing the file. You can either manually add a new public key to authorised_keys file or use ssh-copy-id. Either way, you'll need password authentication set up for your account on the server, or some other identity or access method to get to the authorized_keys file on the server.

ssh-add adds identities to your SSH agent which handles management of your identities locally and "the connection to the agent is forwarded over SSH remote logins, and the user can thus use the privileges given by the identities anywhere in the network in a secure way." (man page), so I don't think it's what you want in this case. It doesn't have any way to get your public key onto a server without you having access to said server via an SSH login as far as I know.

Uzzia answered 23/8, 2014 at 18:47 Comment(1)

I deleted this file and I can still connect. So it definitely was not contained in here... It was an automatically added key but still doesn't exist anywhere. – Hideandseek 26/2, 2015 at 0:46

I opened "Passwords and Keys" application in my Unity and removed unwanted keys from Secure Keys -> OpenSSH keys And they automatically had been removed from ssh-agent -l as well.

Ague answered 13/6, 2017 at 11:21 Comment(3)

Beware that this also deletes them from the directory ~/.ssh – Diphenylhydantoin 10/12, 2017 at 14:49

What is "Unity" (in this context)? The term "Unity" is heavily overloaded. Ubuntu Unity or Ubuntu's Unity? Or something else? – Brassie 23/8, 2020 at 17:19

This is the only solution that worked for me on Ubuntu. – Ulcer 19/10, 2021 at 13:16

I can confirm that this bug is still present in Ubuntu 19.04 (Disco Dingo). The workaround suggested by VonC worked perfectly, summarizing for my version:

Click on Activities tab on top left corner
On the search box that comes up, begin typing "startup applications"
Click on the "Startup Applications" icon
On the box that pops up, select the gnome key ring manager application (can't remember the exact name on the GUI but it is distinctive enough) and remove it.

Next, I tried ssh-add -D again, and after reboot ssh-add -l told me The agent has no identities. I confirmed that I still had the ssh-agent daemon running with ps aux | grep agent. So I added the key I most frequently used with GitHub (ssh-add ~/.ssh/id_ecdsa) and all was good!

Now I can do the normal operations with my most frequently used repository, and if I occasionally require access to the other repository which uses the RSA key, I just dedicate one terminal for it with export GIT_SSH_COMMAND="ssh -i /home/me/.ssh/id_rsa.pub". Solved! Credit goes to VonC for pointing out the bug and the solution.

Tropo answered 25/7, 2019 at 11:2 Comment(0)

In ubuntu, if your current ssh-agent already loaded some keys, I found there is no way to remove it.

You have to kill the current ssh-agent by eval "$(ssh-agent -k)"

Then, start a new ssh-agent by eval "$(ssh-agent -s)"

Ok, now you are free to add a preferred key like ssh-add ~/.ssh/id_preferred_key

Glee answered 8/10, 2022 at 5:9 Comment(1)

This workaround is simpler than most mentioned here. But you don't need to kill the current ssh-agent. You can just start a new agent, and it will have the same effect. – Disjoin 22/7, 2023 at 18:1

The solution for me (openSUSE Leap 42.3, KDE) was to rename the folder ~/.gnupg which apparently contained the cached keys and profiles.

After KDE logout/logon the ssh-add/agent is running again and the folder is created from scratch, but the old keys are all gone.

I didn't have success with the other approaches.

Shudder answered 21/10, 2019 at 13:23 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags