Linux удалить ssh key

Command to remove a ssh authorized key on server

Is there a command (or a one-liner) to remove a ssh key on a server? Something like the opposite of ssh-copy-id?

Some SSH server software support the RFC 4819 protocol for managing authorized SSH keys, but it’s so rare it’s almost nonexistent on Linux 🙁

Its worth noting that ssh-keygen does provide the -R option for removing keys from known_hosts , but sadly ssh-keygen -R -f ~/.ssh/authorized_keys doesn’t work. I would use the sed option below, instead.

4 Answers 4

As Ignatio suggested this can be done with grep -v .

Here is a example which removes the key containing some unique string or just deletes the authorized_keys file when no other key remains.

if test -f $HOME/.ssh/authorized_keys; then temp_file=$(mktemp) if grep -v "some unique string" $HOME/.ssh/authorized_keys > $temp_file; then cat $temp_file > $HOME/.ssh/authorized_keys && rm $temp_file; else rm $HOME/.ssh/authorized_keys && rm $temp_file; fi; fi 

Replace some unique string with something that only exists in the key you wish to remove.

As a oneliner over ssh this becomes

ssh hostname 'if test -f $HOME/.ssh/authorized_keys; then temp_file=$(mktemp); if grep -v "some unique string" $HOME/.ssh/authorized_keys > $temp_file; then cat $temp_file > $HOME/.ssh/authorized_keys && rm $temp_file; else rm $HOME/.ssh/authorized_keys && rm $temp_file; fi; fi' 

Tested on Linux (SLES) and HP-UX.

Источник

how to remove my key (ssh-keygen) when I do not know hostname? (But I know other things)

Nothing to do, except remove the keys you created ( ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub ). A quick summary of how SSH works and the purpose of the various files.

• SSH without passwords works with «assymetric keys».
• This requires a pair of keys that you generate, one private ( ~/.ssh/id_rsa ) and one public ( ~/.ssh/id_rsa.pub ).
• During the login process, SSH uses you local private key to do something that can be checked on the other system using your public key.
• The public key doesn’t need to be kept securely. On the other hand the private key should never leave your local system. You can protect it with a password if you think your local system (and its backups) isn’t secure enough and someone else could get access to the key.
• To identify yourself on other systems, you give them your public key. On these other systems, the userids that you can login to have your public key added to their ~/.ssh/authorized_keys file, which, as its name implies, collects the public keys of all the people that can log in as that userid. This is done either manually with an editor or using the ssh-copy-id utility.
• As an added protection (mostly useful when you use a password login AFAIK), the systems you connect to have an identifier. This identifier is sent to your system during the login process. If the identifier is not in your known_hosts file (which is the case the first time you connect to them), you are asked if you accept that identifier, and if so, it is added to your local ~/.ssh/known_hosts . Normally this identifier should never change, so if you are asked again later to accept the identifier, better ask confirmation to some admin.

So, where you are: you have just generated a couple of public/private keys on your local system.

• As long as they aren’t used anywhere you can just erase them, sight unseen.
• If you copied the public key on a system, you can remove it for cleanliness, but it is not a security risk as long as the private key hasn’t been compromised.
• If someday you suspect that your private key has been compromised (you keep it without a password and somebody accessed your system or your backups), then you should in earnest have the matching public keys removed from the authorized_keys of ids/systems where you copied it (from that point of view, the known_hosts file is a good clue of which systems hold a copy of your public key). Then you can generate a new pair, and copy the new public key to the necessary systems.
• Normally you have no local ~/.ssh/authorized_keys unless you also login on your local system using SSH (but this is rare, and is best avoided)
• One case where you want to remove a host from the known_hosts file, is when the identifier of that host changes for legitimate purposes (host is reinstalled or upgraded and the old identifier gets lost in the process, but you should be told by an admin). You then want to be able to add the new id to your known_hosts but this cannot be done as long as the previous id is there. One solution is to erase known_hosts but you’ll have to re-accept the keys of all your remote hosts, or you use ssh-keygen -R to remove only the relevant obsolete key.

Источник

How to Add and Delete SSH Keys

Changing SSH keys on a running server using the Customer Portal will reinstall and wipe all data on the server. You can manually change SSH keys without reinstalling the server by following this Quickstart Guide.

Prerequisites

• To follow this guide, you must have an SSH key in OpenSSH format. See our guide to create an SSH key.
• This guide applies to Linux and BSD servers.
• This guide is suitable for Linux, Mac, or Windows workstations.

Add SSH Key to Vultr Instance

Deploy a new SSH key from a Linux or Mac workstation with ssh-copy-id .

Linux and Mac workstations

The ssh-copy-id utility is pre-installed on most Linux distributions. Mac workstations can install it via Homebrew, MacPorts, or using Curl.

Use the utility to add your public key to the server.

• Specify the correct public key with the -i [path to public key] parameter.
• Specify the username and server IP address (or domain name) as shown. For example, the root user at 192.0.2.123:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.0.2.123 

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/example_user/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@192.0.2.123's password: 

Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'root@192.0.2.123'" and check to make sure that only the key(s) you wanted were added. 

Windows workstations

Windows workstations can mimic the ssh-copy-id utility with a one-line PowerShell command. The example shown pipes the the public key through SSH from the current user’s profile to the root user’s ~/.ssh/authorized_keys.

PS> type $env:USERPROFILE\.ssh\id_rsa.pub | ssh root@192.0.2.123 "cat >> .ssh/authorized_keys" 

Alternate method for any workstation type

1. SSH to the server.
2. Edit ~/.ssh/authorized_keys.
3. Append your public key to the file.
4. Save and exit.

Delete SSH Key

There are no common automatic methods to delete a public key, you must remove it manually.

1. SSH to your server.
2. Edit ~/.ssh/authorized_keys.
3. Remove the line containing your key.
4. Save and exit.

Manage SSH Keys via API

The Vultr API offers several endpoints to manage SSH keys.

• Create a new SSH key for use with future instances. This does not update any running instances.
• List all SSH keys in your account.
• Get information about an SSH key.
• Update an SSH key.
• Delete an SSH key.

More Information

For more information about managing SSH keys, see our other guides:

Want to contribute?

You could earn up to $600 by adding new articles.

Источник

Remove ssh key Mac, Unix and Linux

Remove ssh key mac, is needed to remove ssh keys when trying to connect to a host where remote host identification has changed. There should however be some thoughts to go thru before you try to connect to such a host. Why was the host key changed? If it’s your own server you should definitely be worried unless you changed the host IP address. Because as the warning says someone might be doing something nasty like the man in the middle attack.

Remote host identification has changed

To get a copy of this error message I changed the IP on one of my Linux servers at home. I changed to an IP address I already was using on one of my other hosts.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for gitlab.home has changed, and the key for the corresponding IP address 192.168.2.162 has a different value. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. Offending key for IP in /Users/john/.ssh/known_hosts:8 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:cTU/0LDw0ywVquhsmkVuOYJNXsN1Ivmdnz/ozej4WOo. Please contact your system administrator. Add correct host key in /Users/john/.ssh/known_hosts to get rid of this message. Offending RSA key in /Users/john/.ssh/known_hosts:15 RSA host key for gitlab.home has changed and you have requested strict checking. Host key verification failed.

What happened?

What actually happens here is that our system gives two warnings. First, it gives us a warning about that either there is DNS Spoofing or the host IP address have changed. Here we know it is because I changed the IP address to an IP address that is used for another host. A host I have previously logged on to.

The second warning is that host identification has changed. That is quite logical since it’s not the same server and therefore, has a different host identification. All host identifications are unique.

SSH on my mac terminal now refuses me to log on. We will have to delete the host key from the known_host file before the system let us log on again. Other users that have never logged on to the server before will not be refused to log on. Even if the users are using the same computer as you. That is because each user has their own known hosts file. The host public key is sent to each user and the private key is only stored on the host.

Remove RSA key with ssh-keygen

We will use the same tool used to generate ssh key to delete the ssh key instead of create ssh key. To remove the ssh key from our mac we will use the keygen with the following command line:
ssh-keygen -R 192.168.2.162

In my case this will output the following response:
ssh-keygen -R 192.168.2.162

Host 192.168.2.162 found: line 8

/Users/john/.ssh/known_hosts updated.
Original contents retained as /Users/john/.ssh/known_hosts.old

I can also use the hostname to remove the key. Since I have used the IP address and the hostname before it would be best to remove both.

Host gitlab.home found: line 15

/Users/john/.ssh/known_hosts updated.
Original contents retained as /Users/john/.ssh/known_hosts.old

Next time I try to connect to that server it will say the RSA key fingerprint can’t be found. Then it will ask if I want to store the key permanently.

Remove RSA key manually

You can also remove the key manually without using the keygen remove command. A standard text editor can be used. On a Unix system like MacOS, the mac known_hosts default path is /Users/john/.ssh/known_hosts. If your name is John.

Open up the terminal and go to the .ssh folder. Terminal opens by default in your home directory. Then we can open the known_hosts file by just typing: open known_hosts.

TextEditor will now open the known host ssh key file. And we can manually remove the offending ssh key. If we follow the same example and remove gitlab.home or 192.168.2.162 we will have to look for that. In the picture below is an example of a known_hosts file.

So at the bottom, we find this line:
gitlab.home,192.168.2.162 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDcgoUfLjbM/94X/KVd5dzNt27d08A27phzGW6gcQu0HzId0Ha0opjWJzb5KBbFeImIipywHRONnq0ZN5Jb4YpE=

If you remove that line, that will be the same as running the ssh-keygen -R command.

Don’t believe the windows users. The cloud is just someone else computer.
You could also check out the How to show hard drive on mac .

Источник