Removing an SSH Key: Clear the Agent, Delete the File, or Revoke Access?

“Remove my SSH key” can mean several different things: stop the agent from offering it, delete the local files, or revoke its access on a server. These actions affect different places. Deleting a key from your laptop does not revoke access, and removing it from an agent does not delete the file.

Before running a removal command, decide which copy or authorization you want to change.

Know where the key is

An SSH key pair usually has two files: a private key, such as id_ed25519, and a public key, such as id_ed25519.pub. The private key should stay under your control. Servers and services typically store the public key to decide whether to allow access.

There are other places a key may exist, too:

• ssh-agent can hold a loaded identity in memory.
• A server account's authorized_keys file can grant login access.
• Git hosting or cloud accounts can store a public key in their own settings.
• Your known_hosts file stores server identities, not your login keys.

That last distinction matters: a warning about a changed host identity is not evidence that your own login key needs to be removed.

Stop offering a key: remove it from ssh-agent

If you only want to stop the current agent from offering a key, remove that identity from the agent. Use the public-key path:

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

To clear every identity currently loaded in the agent:

ssh-add -D

These commands remove keys from the agent's memory; they do not delete files or change which keys a server trusts. The agent can load a key again later if another command adds it. The commands are the same in terminals using OpenSSH on Linux, macOS, and Windows. If you need a refresher on what the agent stores and how it fits into authentication, see this SSH agent overview.

Revoke access: remove the key from the server

If the goal is to prevent a key from logging in to a particular account, remove its line from that account's ~/.ssh/authorized_keys file on the server:

ssh user@server
nano ~/.ssh/authorized_keys

Find the line for the key you want to revoke, delete that line, then save the file. Leave other entries in place. Deleting the entire file would remove every key authorized for that account, including keys other people or automation may still need.

The change applies to future connection attempts; you do not need to restart sshd after editing authorized_keys. If the file has many entries, comments such as laptop-2025 or deploy-key make it easier to identify the right one. A guide to authorized_keys covers its format and permissions in more detail.

This revokes the key for that account on that server only. If the same public key is installed on other servers, or registered with GitHub, GitLab, or a cloud provider, those copies need separate removal.

Delete the local key files

Once you no longer need a local copy, remove both files for that key pair. On Linux or macOS:

rm ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

On Windows PowerShell, the OpenSSH key directory is usually under your user profile:

Remove-Item "$env:USERPROFILE\.ssh\id_ed25519", "$env:USERPROFILE\.ssh\id_ed25519.pub"

Replace id_ed25519 with the actual key name. If you are unsure which key a file contains, inspect the public key's fingerprint before deleting it:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Deleting the local files only removes that copy. It does not erase backups, remove a key from an agent, or revoke access anywhere. Anyone with another copy of the private key may still be able to authenticate wherever its public key remains authorized.

Don't confuse login keys with host keys

Your client stores server identities in ~/.ssh/known_hosts. If a server was rebuilt or its host key legitimately changed, you may need to remove its old entry. The command is:

ssh-keygen -R hostname

This removes the matching host entry from known_hosts; it does not affect your login key or revoke your account access. A changed-host-key warning can also indicate a security problem, so verify the server's new fingerprint through a trusted channel before accepting it again.

Retire a key without losing track of access

For a key you are retiring completely, remove access first, while you can still identify the key and check where it is used:

1. Remove its public-key entry from each server account's authorized_keys.
2. Remove it from relevant platform accounts, such as Git hosting or cloud consoles.
3. Remove it from ssh-agent if it is loaded.
4. Delete the local key files when you are confident they are no longer needed.

The key idea is simple: agent removal changes what your client offers; server-side removal changes who can log in; file deletion removes a local copy. Choose the operation that matches your goal, and check every system that separately trusts the key.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.