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 >
