Introduction.
This little tutorial aims to cover a simple, but vital process, that may be required if your secure shell (ssh) key becomes invalid.
How could this occur?
A simple explanation could be a corrupted file, but in my case, it was the result of implementing a clean installation of Debian Squeeze on my main production computer.
I use this machine as a backup for my server(s) via secure copy (scp) and they in turn, expect a valid key to be transmitted within the secure socket layer (ssl) connection initialisation. When I carried out a clean installation of Debian Squeeze, it destroyed the existing key and therefore when I wanted to backup files from the server, it not unreasonably refused. That will teach me to back-up my keys!!!
Debian is brilliant for not loading a load of rubbish that you don't want and as part of that philosophy, openssh-server is not installed by default. Therefore, on a fresh installation and when you install openssh-server, it will produce a brand new key for you.
The problem is, the old key stored on the server, does not match the new key produced as a result of the fresh installation and so you get a mismatch and a rather frightening message like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
(finger print is stated here)
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
RSA host key for ras.example.com has changed and you have requested strict checking.
Host key verification failed.
You are now essentially locked out from doing file transfers via scp.
The first thing to note from the warning above, is the offending key is stored in:
/home/user/.ssh/known_hosts
but it could be a different path completely. However, in Debian, it will be wherever .ssh resides. The message helpfully gives you that information.
If you look in known_hosts, all the keys are in a hashed format, so there is no way of telling which one is actually the one you want to get rid of.
I should qualify that a bit. If you access the server as I do via multiple machines, there will be a valid key for each machine. That is not at all unusual on a server. After all, you could in some circumstances have hundreds of people accessing the machine and so it's not really an option to just delete everything within it and hope for the best. You need to find a way of deleting that one key and allowing the server to validate the new one.
Note: if you do just access your server via only one machine, you can simple delete the known_hosts file. Personally I wouldn't recommend it, but in theory, it's a perfectly valid solution. The next time you attempt to use ssh, it will generate a new file for you.
Command line to the rescue.
If the machine the server is connecting to has a valid server domain name, you could use that. But I find it easier to use the connecting machines Internet Protocol (ip) address. This most commonly on a small private network will be a private address such as (for example):
192.168.0.1
but on a major public network, could be just about anything.
So for our example, I'm going to make a fictitious network to demonstrate how the process is completed.
In our example, the server is 192.168.0.20
and the computer I'm trying to connect to and the one that has had a fresh installation is 192.168.0.1
Both are on the same internal network and normally communicate with each other with no issues.
Remember Linux is always case sensitive and this is an example. Substitute your own ip address to suit.
To get rid of the old invalid key on the server (192.168.0.20), either go physically to the server, or log in from a valid machine and at the command prompt, type;
ssh-keygen -R 192.168.0.1
and hit Enter.
What have we just done? We've told the server (192.168.0 .20) to use ssh-keygen and remove (-R) the key for 192.168.0.1
You will get a known_hosts updated message and a backup of the original file will be automatically generated.
Now when you use scp (or whatever) to try and copy files across the network, the server will see the new key on 192.168.0.1 and as it no longer has a key associated with that machine, ask if it can accept it.
Providing you're happy it's the correct machine and key, tell the server yes and it will store it in a hashed form, to be used for all future transmissions.
Job done!
