openssh unix dev - Sep 2011 - Different HostKeys for different hostnames or IPs in the same sshd?..

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

Mikhail T. wrote:
> 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?
Counter-question: How do you want to still have protection against
malicious DNS data, or simply TCP MITM attacks?

> Other than both machines using the same  hostkey, of course...
Why not do this?

> does the ssh-protocol have anything like HTTP's Host:-header?
Thankfully no.

> If not, can sshd offer a different key depending on the IP-address,
> that the incoming connection uses?
In theory sure, in practise OpenSSH can't. You could always patch it.


//Peter

On 9/20/11 1:12 PM, Mikhail T. wrote:
> 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...
That's the easiest way - if you want the machines to appear identical, 
make the host keys identical.
> 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?
Run 2 sshd masters with 2 different config files, one listening on the 
VIP with shared keys and one listening on non-VIP with host specific keys.

-- 
Carson

On Tue, Sep 20, 2011 at 8:12 PM, Mikhail T. <mi+thun at aldan.algebra.com>
wrote:
> 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...
In the cases where I've had a handful of boxes behind a single DNS RR,
I took the poor man's way out and ensured that all six boxes in that
farm had the same hostkeys via an administrative process.

--
Coy

On Tue, 20 Sep 2011, Mikhail T. 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.
If these machines are replicas of each other and are subject to similar
security controls then there is no reason they cannot have the same key.

Unless you store keys in DNSSEC, OpenSSH doesn't have a mechanism to allow
two hosts with the sane name to use different keys.

-d

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.