Paul, Back up /etc/ssh_host_[dsa|rsa]* from the existing one and copy them over on the new one.
Boby Paul Ryland wrote: > > George Horvath (Scotia Capital) wrote: > >> Hello, >> >> I have a large number of servers sending reports to a central >> server using keys to automatically sftp the report in. I >> need to replace the central server without going to each >> client to update the known_host file with a new key so that >> the first transfer doesn't break due to the host being >> replaced. I realize the whole point of strict checking is to >> notify if the server has been replaced or otherwise modified >> but I'm sure I'm not the first one to run into this. We are >> using RSA host keys that get dumped on the client server by >> the package install script. The new server will have the >> same IP address and hostname and I'm hoping this will help >> the situation but I'm assuming the key is generated using a >> finger print of the server and which would be different from >> the new one. >> >> Some of the clients are OpenSSH_3.9p1. The central server >> and most clients are a more recent version of OpenSSH. Sorry >> but I can't be more specific than that. >> >> Any help would be greatly appreciated. >> > > An elegant solution is to install the server's fingerprint in your DNS zone > file (I'm assuming that your internal DNS system is fully DNSSEC enabled). > When you are logged onto the server, "ssh-keygen -r <servername fqdn>" will > generate the appropriate RR. Once this is in place, you can put something > like this in your ssh configuration files: > > Host <regex to match your servers> > UserKnownHostFile /dev/null > StrictHostKeyChecking no > VerifyHostKeyDNS yes > > For the configured hosts, this enforces the use of DNS to store/check ssh > fingerprints and disables the use of a local known_hosts file. > > The only icky bit about this is the zone-file-crawling blunder in the current > DNSSEC standard. > > > Paul >
