How can I remove an SSH key?

Question

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

Is there a way to completely remove an SSH key?

Solution 1

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

• "Debian Bug report #472477: ssh-add -D does not remove SSH key from gnome-keyring-daemon memory"
• "Ubuntu: ssh-add -D deleting all identities does not work. Also, why are all identities auto-added?"

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.

Solution 2

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

Solution 3

Check if folder .ssh is on your system

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

If not, then

2. Open Terminal.

Paste in the terminal

3. Check user → ssh -T [email protected]

Remove existing SSH keys

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

Create New

5. Create new SSH key → ssh-keygen -t rsa -b 4096 -C "[email protected]"

6. The public key has been saved in "/Users/administrator/.ssh/id_ed25519.pub."

7. Open the public key saved path.

8. Copy the SSH key → GitLab Account → Setting → SSH Key → Add key

9. Test again from the terminal → ssh -T [email protected]

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[user2196728]

What with ssh-add -d ?

[Alexander Mills]

damnit, it is ssh-add -D, uppercase

[Dwight Spencer]

Check your sockets that are being used by your ssh-agent(1).

[Larry]

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.

[user3257693]

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.

[H2ONaCl]

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.

[VonC]

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

[H2ONaCl]

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

[Phil]

@user3257693 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!

[redfive]

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.

[Peter V. Mørch]

Beware that this also deletes them from the directory ~/.ssh

[etandel]

Just got bit by this bug on Ubuntu 18.04. Thanks a lot for this answer!

[joshlsullivan]

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!

[Ryan Lue]

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.

[VonC]

@RyanLue Thank you. Very interesting. I have included your comment in the answer for more visibility.

[L.T]

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

[VonC]

@L.T 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.

[Peter Mortensen]

What is "Unity" (in this context)? The term "Unity" is heavily overloaded. Ubuntu Unity or Ubuntu's Unity? Or something else?

[tagaism]

What if ssh-key is used to connect to remote servers and removing and generating a new key is not an option?

[kimbaudi]

This is the only solution that worked for me on Ubuntu.