Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To revoke an SSH key on a self-managed Linux VPS or VDS using OpenSSH, remove that key’s public-key entry from the authorized-keys file for every server account where it was installed. The usual file is ~/.ssh/authorized_keys, but the server may be configured to use another location. Deleting a saved key from your hosting-provider account is a separate action and may not revoke access to existing servers.
What deleting an SSH key changes
OpenSSH checks the target Linux user’s authorized-key configuration when deciding whether a public key may authenticate as that user. Removing a matching entry from that user’s configured file revokes authorization through that entry; it does not establish that the key is absent from other user accounts or other configured key sources.
There are three separate places people may mean when they say “delete an SSH key”:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute- The server’s authorization list: controls whether the key is accepted for the relevant account.
- The provider’s saved-key inventory: stores a key for provider-side reuse or management; deleting it does not necessarily remove it from servers already created.
- Your computer: deleting a local private-key file does not remove the corresponding public key from a server.
Remove the key from the server
- Keep a working way back in. Connect with an administrator account or provider console, and make sure another authorized administrator or recovery route is available. Do not close your current session until you have confirmed that the replacement access path works.
- Identify the login account and key file. In a standard OpenSSH configuration, the default file is
~/.ssh/authorized_keysin the target user’s home directory. The server’sAuthorizedKeysFilesetting can specify a different location. Check the effective server configuration and the account’s files rather than assuming every distribution uses the default path. OpenSSH sshd documentation describes the setting and default. - Match the exact public key. Compare the key type and public-key material against a trusted copy or fingerprint. A trailing comment can help you recognize an entry, but it is only a label and does not prove the key’s identity.
- Remove only the matching entry. Edit the configured authorized-key file and delete the line containing that public key. Save the file and inspect the remaining entries to ensure you did not remove another administrator’s key by mistake.
- Check other accounts. If the same public key may have been installed for more than one username, inspect each account’s configured authorized-key location. Authorization is per account, so removing it for one user does not revoke its use for another.
- Test from a fresh connection. While keeping the current session open, try connecting with the revoked key. If it still authenticates, check other user accounts and alternate configured key locations, and investigate whether a provider or configuration-management process is restoring the entry.
Server-side removal versus provider-account deletion
These operations affect different records. Removing a key from the server changes authorization for the account and file you edited. Deleting a provider’s saved key record changes the provider’s inventory; it does not, by itself, prove that the public key has been removed from existing instances.
#1 Best Overall
| Operation | What it changes | What it does not establish |
|---|---|---|
| Remove the entry from a server user’s configured authorized-key file | Whether that key is accepted for that account through that file | That it is absent from other accounts, alternate configured files, or automation sources |
| Delete a saved key from provider account inventory | The provider’s stored key record | That the public key was removed from existing VPS instances. DigitalOcean explicitly says its command does not delete a key from any Droplets. DigitalOcean doctl command reference |
DigitalOcean’s API reference likewise describes account-level SSH-key operations, including deleting a key by identifier; it is not a universal control-panel workflow for all VPS or VDS providers. DigitalOcean API reference: SSH keys
If you lose access while changing keys
Recovery depends on the provider, server distribution, and available console features. As one provider-specific example, DigitalOcean documents using its Recovery Console to regain SSH access. Its guidance notes that password authentication is disabled by default on Droplets created with an SSH key and that configuration steps can vary by operating-system release, including Ubuntu 22.04 and later and Debian 12 and later. Follow the current instructions for your provider and OS rather than applying those steps to another host. DigitalOcean Recovery Console guidance
Rank #2
If the key may be compromised
After removing the key from every known server account and authorization location, review access associated with the same administrator or system and rotate any other credentials that may also have been exposed. This is incident-response guidance, not a claim that removing one public key revokes unrelated credentials.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Best Value
Rank #4
Rank #3
- HP MicroServer Gen10 Plus Tower Server for Business with Microsoft Windows Server 2019 OS!
- Intel Xeon E-2224 Quad-Core 3.4GHz 8MB CPU, Up To 4.6GHz Turbo
- 32GB (2 x 16GB) DDR4 PC4-21300 2666MHz Unbuffered Memory
- 16TB (4 x 4TB) 7.2K 6Gb/s SATA 3.5" HDDs in RAID
- Hard drives and memory upgrades included separately NOT installed, installation required.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

