2

Just to get this out in front so I am not told not to do this:

  1. The machines in question are all on a local network with little to no internet access (they aren't even well connected to the corporate network)
  2. Everyone who has the ability to setup a man-in-the-middle attack already has root on the machine
  3. The machines are reinstalled as part of QA procedures, so having new host keys is important (we need to see how the other machines react); I am only trying to make my machine nicer to use.

I do a lot of reinstalls on machines which changes their host keys. This necessitates going into ~/.ssh/known_hosts on my machine and blowing away to old key and adding the new key. This is a massive pain in the tuckus, so I have started considering ways to automate this.

I don't want to just blindly accept any host key, so patching OpenSSH to ignore host keys is out. I have considered creating a wrapper around the ssh command the will detect the error coming back from ssh and present me with a prompt to delete the old key or quit. I have also considered creating a daemon that would fetch the latest host key from a machine on a whitelist (there are about twenty machines that are being constantly reinstalled) and replace the old host key in known_hosts.

How would you automate this process?

4 Answers 4

3

Depending on the resons for the reinstall/IPs stay the same I would look at setting up "StrictHostKeyChecking" in ~/.ssh/config for specific Host/IPs/Patterns.

If that's not possible then look at automating the loading of keys on the hosts, perhaps in the reinstall process.

1
  • 1
    This is why I asked, I knew there had to be a better way. I already have a pattern setup in ~/.ssh/config for those hosts (to force root as the user), so adding a StrictHostKeyChecking no to that section solves the problem nicely. Jun 16, 2010 at 14:33
2

If you're using a configuration management system, like Puppet, you can use it to have it keep the /etc/ssh/ssh_known_hosts file updated with the hosts as the client machines check in with the central server. Then you could enable to StrictHostKeyChecking option in the config file.

This is precisely what we do with our Amazon EC2 instances that check in with our Puppet master server. We have the puppet server serve as the bastion jumpbox into our EC2 instances and is the only machine allowed to SSH into them. We then keep the /etc/ssh/ssh_known_hosts file updated with the host keys and the /etc/hosts file to update the EC2's public DNS IP address.

2

You want ssh-keyscan, which is distributed with openssh. From the man page:

 ssh-keyscan is a utility for gathering the public ssh host keys of a num‐
 ber of hosts.  It was designed to aid in building and verifying
 ssh_known_hosts files. 

As part of your reinstall have a machine with an up-to-date list of keys run this, then distribute the updated known_hosts file to the rest of the machines.

Or, as others mentioned, you can turn off StrictHostKeyChecking. That opens you up to man-in-the-middle attacks, though that may not be a worry in your environment.

1

Perhaps you would like to save the host keys before reinstalling, then restore them afterwards.

Alternatively, you can use some configuration management tool like CFengine or Puppet to distribute an authoritative /etc/ssh/ssh_known_hosts to all clients on your site. (OpenSSH consults /etc/ssh/ssh_known_hosts if there is no matching entry in ~/.ssh/known_hosts.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .