Different HostKeys for different hostnames or IPs in the same sshd?..

[Nico Kadel-Garcia]

On Tue, Sep 20, 2011 at 4:12 PM, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
> Hello!
>
> Like many organizations, we have "disaster-recovery" location, where
> separate servers are running ready to take up important services should the
> primary location fail.
>
> Some of the services provided involve accepting files over scp (and sftp),
> and here is the problem... The primary and the secondary hosts use different
> host-keys... If the hosts were accessed as "service-primary.example.net" and
> "host-dr.example.net", this would be fine, but the users (and the automated
> tools) would have to be told, which name to use.
>
> So, we want to use an "umbrella" DNS name "service.example.net" to control
> the destination. Under normal circumstances, it is a CNAME for the
> "service-primary.example.net", but in case of a disaster, it will be changed
> to "service-dr.example.net".
>
> How do we configure things so that the users and the automated scripts
> aren't "freaked-out" by the key of "service.example.net" suddenly changing,
> when the DNS is changed? Other than both machines using the same  hostkey,
> of course...
>
> Can sshd use a different key depending on which name it is contacted under
> -- that is, does the ssh-protocol have anything like HTTP's Host:-header? If
> not, can sshd offer a different key depending on the IP-address, that the
> incoming connection uses?
>
> Thanks for any ideas. Yours,
>
>   -mi

The *system* keys should, ideally, be unique. The *service* related
keys can then be matched, and stored and shared separately, without
changing basic system authentication. This is commonly used,
especially with virtual ports in failover configurations, to swap the
IP address from one host to the other and to keep the SSH keys tied to
that expected hostname, and even that non-standard port in some
configurations.

I've used this in multiple configurations for SSH based backup systems
and svn+ssh access to Subversion repositories, quite successfully. The
same issues also apply to HTTPS access.