Handling ssh to generic hostnames

April 7, 2009

(This idea is not from me, it's from R Francis Smith. It is just sufficiently nifty and wrong that I'm going to write it up for posterity.)

Suppose that you have a generic hostname, a hostname that either is multiple machines (with multiple IP addresses) or a virtual host that gets pointed to different physical machines from time to time. Further suppose that inside your environment, your users ssh to that machine, or at least want to. The traditional problem with this is that for good reasons ssh's host key checking will start screaming about mismatching host keys the moment that you wind up talking to a different physical machine that has, of course, different host keys.

So, the ingenious evil solution for this problem is to have a Host stanza for the generic hostname in your /etc/ssh/ssh_config that turns off the various ssh host key verification options, so that ssh never even notices the mismatched host keys and thus never complains about them. Yes, this is kind of unpleasant, but it is better than the alternative (which is very close to not having useful generic hostnames), and you can make it less risky by turning off password-based authentication methods and other dangerous things.

This is a somewhat limited solution to the problem, since it only works within your systems. But that's probably the only place that you want it to work anyways.

(The simple evil solution to the problem is to give all of the physical hosts for the generic hostname the same host key. You probably don't want to do this.)

Sidebar: how to turn off ssh's host key checking

The options that you want are:

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

With these set, ssh can do all of the host key checking it wants to but it's never going to get anywhere, and so never gets in the way.

(I will assume that the generic hostname is not in your global known hosts file, because there is no reason to put it there since it doesn't have a constant key.)


Comments on this page:

From 76.103.56.154 at 2009-04-08 01:34:30:

so wrong...

From 88.171.200.213 at 2009-04-08 04:37:40:

bad idea to change this config option system wide... why not alias "ssh" to "ssh -o StrictHostKeyChecking=no" in your ~/.bashrc (or equivalent) ?

From 76.10.173.95 at 2009-04-08 09:32:59:

It's a much worse idea to turn off host key checking for all hosts. If you're worried about other users of the same system, the Host block solution could be confined to ~/.ssh/config

From 64.88.176.254 at 2009-04-08 09:43:25:

In the event that you administer those real hosts behind the generic host, you could have them all use the same host key.

From 24.99.225.240 at 2009-04-08 11:19:12:

Why not just synchronize the host keys between the machines? We have had to do this in a few cases were hosts were placed behind a load-balancer, and it works like a charm.

- Ryan

By rdump at 2009-04-08 15:15:07:

When you have a number of nodes in a high availability cluster, and your users will hit a random node while trying to reach the service name, then you probably won't be able to get them all to put in the relevant Host stanza to turn off key checking. Besides, in such situations you probably want key checking and warnings of changes. It makes more sense there to ensure each node has the same host key.

From 82.46.76.43 at 2009-04-08 16:42:33:

On a related, but not quite related note, I really wish Host matching in ~/.ssh/config (and known hosts) used the fully resolved version of the hostname, rather than whatever the user typed (without the domain or search path).

I guess it's a bit late now as changing it would break a lot of people's configs, but it would be more flexible. (e.g. if I do 'ssh host', and have two entries in search, currently there's no way to match on the domain that host is in).

By cks at 2009-04-09 00:41:02:

Ssh can't use the fully resolved versions of hostnames for checking host keys, because the resolution process might be manipulated by an attacker and thus you might be connecting to something other than what you think you are. Checking the host key for the literal name that you typed at least insures that 'ssh host' goes to the same place it did last time.

(The attacker's change would have to be to a machine that you already have a host key for, but there are still situations where this is dangerous.)

From 128.33.22.52 at 2009-06-26 10:17:02:

You write:

The simple evil solution to the problem is to give all of the physical hosts for the generic hostname the same host key. You probably don't want to do this.

This is the solution I've usually seen. What's wrong with it?

Written on 07 April 2009.
« The technical problems with 'sender stores messages' schemes
Why ssh needs to verify host keys »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Apr 7 22:48:26 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.