putty with multi-homed services
LeB...@mcc.ac.uk
sometimes with the same IP addresses on different machines.
For example, I have a 'service' called 'publish.man.ac.uk'
with the IP address 130.88.203.156, which is actually
being served by two hosts with different ssh identities.
Now ssh and openssh allow me to have known_hosts files with
different entries for the keys, which means that I can ssh to
such a service and it will work without complaint, no matter
which host I reach. But putty puts this information into
the registry, and the host name there has to be unique, so I
can't have, for example, two different keys for publish.man.ac.uk.
There are overlapping services on 18 hosts with various levels
of security. Short of having the same key on all 18 hosts,
I don't see how putty can deal elegantly with this: for example,
the first time I use putty to contact publish.man.ac.uk it
saves the key, and on half the subsequent times it complains
that something is wrong, because it connects to a different host.
Any ideas on how to deal with this?
-- Owen
LeB...@mcc.ac.uk
Simon Tatham
> For example, I have a 'service' called 'publish.man.ac.uk'
> with the IP address 130.88.203.156, which is actually
> being served by two hosts with different ssh identities.
> the first time I use putty to contact publish.man.ac.uk it
> saves the key, and on half the subsequent times it complains
> that something is wrong, because it connects to a different host.
I do plan to do something drastic to PuTTY's host key management at
some point, but I'm not yet sure what. OpenSSH caches by
(hostname,IP) if I remember rightly, which sounds like the ideal
solution to this particular sort of problem but I can't immediately
work out a good way to differentiate legitimate multihoming from
DNS-based attacks.
That is: suppose you connect to publish.man.ac.uk and it gives you
an IP address you've never seen before, together with an SSH host
key you've never seen before either. How on earth can you possibly
tell whether (a) this is another legitimate IP address for the same
service and you should accept the host key, or (b) this is a
completely bogus IP address and host key invented by a malicious
hacker and if you accept it you're in serious trouble?
(b) is precisely the sort of situation host keys are designed to
present; a scenario that makes it look exactly the same as a
perfectly legitimate case seems to me to be a Bad Thing. I haven't
really looked into this yet (in particular, I haven't checked to see
how OpenSSH deals with this problem) but I'd be interested if anyone
has any good ideas.
--
Simon Tatham "Thieves respect property; they only wish the property to
<ana...@pobox.com> be their own, that they may more properly respect it."
Per Hedeland
> Short of having the same key on all 18 hosts,
>I don't see how putty can deal elegantly with this: for example,
>the first time I use putty to contact publish.man.ac.uk it
>saves the key, and on half the subsequent times it complains
>that something is wrong, because it connects to a different host.
>
>Any ideas on how to deal with this?
Well, there's nothing obviously wrong with *having* the same key on all
18 hosts, I think.
--Per Hedeland
p...@bluetail.com
Richard Silverman
Per> Well, there's nothing obviously wrong with *having* the same key
Per> on all 18 hosts, I think.
If an intruder compromises one of them, he automatically gains the ability
to impersonate all of them.
--
Richard Silverman
sl...@shore.net
Per Hedeland
<r...@des.jhy.us.ml.com> writes:
>>>>>> "Per" == Per Hedeland <p...@bluetail.com> writes:
>
> Per> Well, there's nothing obviously wrong with *having* the same key
> Per> on all 18 hosts, I think.
>
>If an intruder compromises one of them, he automatically gains the ability
>to impersonate all of them.
Yes of course, and I certainly wouldn't recommend that you have the same
host key on all your hosts as a general mode of operation.:-) But Owen's
question was about some type of "cluster" service, where even the same
host name *and* IP address could land you at different physical hosts on
different occasions.
I'm not sure that being able to impersonate all of the hosts in such a
cluster is all that more interesting than being able to impersonate one
of them, but perhaps more importantly I don't see a way that an SSH
client could handle such a scenario in a way that would give more
security than having the same host key on all hosts.
E.g. Owen said that the OpenSSH client allowed for having multiple keys
for a given hostname/IP-address, and was satisfied if any of them
matched (I haven't verified this) - clearly this would also allow an
intruder to - for all practical, cluster-related purposes - impersonate
all the actual hosts if he had the key from one of them.
What might muddy the water a bit is that I got the impression that there
were multiple services partially overlapping in different ways across
the 18 hosts, i.e. the cluster wasn't quite homogenous, in which case
having the same host key for all services on all hosts might reduce
security a bit (also I'd guess there is "unclustered" access to
individual hosts for other purposes).
This could perhaps be handled by having multiple instances of the SSH
server running on the hosts, one for each "clustered" service (on that
host) and one for the "unclustered host", listening on different IP
addresses (or ports perhaps). They would have different host keys on any
given host, but the host key for a given service would be the same
across the hosts that are part of the cluster for that service.
There may be problems with this if there is a "service IP address" that
actually migrates between the hosts though (depending on the OS and its
configuration, the SSH server may not be able to listen on an IP address
that isn't bound to a local interface) - if there is some sort of load-
balancing box frontending the hosts, and it's the one that actually
"owns" the "service IP address", it should work fine though. The
"migrating IP address" case *can* be handled too, but perhaps it'll be a
bit awkward (e.g. you may need to fire up the SSH server when the IP
address "arrives").
--Per Hedeland
p...@bluetail.com
LeB...@mcc.ac.uk
>E.g. Owen said that the OpenSSH client allowed for having multiple keys
>for a given hostname/IP-address, and was satisfied if any of them
>matched (I haven't verified this) - clearly this would also allow an
>intruder to - for all practical, cluster-related purposes - impersonate
>all the actual hosts if he had the key from one of them.
>What might muddy the water a bit is that I got the impression that there
>were multiple services partially overlapping in different ways across
>the 18 hosts, i.e. the cluster wasn't quite homogenous, in which case
>having the same host key for all services on all hosts might reduce
>security a bit (also I'd guess there is "unclustered" access to
>individual hosts for other purposes).
Yes, the cluster is by no means homogeneous, having at the moment
18 machines offering at the moment 11 distinct services, most using
between 2 and 5 machines. If there were a way to have a key per
service, I would try that, but how can you configure an sshd to
use a different key depending on the incoming IP address? You could
have n different sshds, of course.
In the present case an intruder could mimic one machine, but not
the whole cluster. There is 'unclustered' access to individual
hosts only for administration.
Thanks for the comments.
-- Owen
LeB...@mcc.ac.uk
Per Hedeland
>Yes, the cluster is by no means homogeneous, having at the moment
>18 machines offering at the moment 11 distinct services, most using
>between 2 and 5 machines. If there were a way to have a key per
>service, I would try that, but how can you configure an sshd to
>use a different key depending on the incoming IP address? You could
>have n different sshds, of course.
Yes, that would be the way to do it - not a huge problem I think (of
course there would be no actual code difference between the n sshd
daemons, you'd just point them at different config files).
>In the present case an intruder could mimic one machine, but not
>the whole cluster.
Yes, but you have a serious problem with the keys being different
between hosts that "appear" to the client to be the same - and even the
OpenSSH client accepting any key out of a "set" is a problem. (I.e. the
intruder could intercept a connection that "should" have gone to host A
and present the key for host C, and the client will be happy if A and C
are both in the "service cluster" the user tried to connect to -
effectively he *can* mimic any machine in any "service cluster" that the
compromised host is part of.)
--Per Hedeland
p...@bluetail.com
Richard Silverman
The SSH protocol doesn't say anything about how server authentication is
done from a policy perspective -- the question of how a client is
satisfied as to the server's identity is entirely client-side and
unspecified. The protocol merely provides the means for identification
(the authenticated key exchange).
SSH implementations differ in how much flexibility they give the user in
defining adequacy of server authentication. For instance, the server's IP
address is not necessarily relevant (as it should not be, since not all IP
addresses are statically assigned). In OpenSSH, if you set "CheckHostIP
no" and do not include the IP address in the known-hosts lists, then you
rely entirely on verification of the host key. Similarly, the host's fqdn
is not necessarily relevant. OpenSSH looks up the host key by the
user-supplied server name, which is need not be a hostname; it can be
simply a label in ~/.ssh/config.
If you give all the hosts the same key, then you have weakened the
strongest server authentication method available to you. This solves the
problem at hand, but at a cost in granularity.
On the other hand, if they all have separate keys, you can do the
following. {foo,bar}.baz.org are individual cluster hosts;
cluster.baz.org is a load-balancing name which rotates over the cluster
members(e.g. round-robin DNS, a Cisco DistributedDirector, etc.).
[/etc/ssh_config]
host ONE
hostname foo.baz.org
HostKeyAlias ONE
host TWO
hostname bar.baz.org
HostKeyAlias TWO
host CLUSTER
hostname cluster.baz.org
[/etc/ssh_known_hosts]
ONE,CLUSTER ssh-dss AAAAB3NzaC1kc3MAAACBAPjbBYB...
TWO,CLUSTER ssh-dss AAAAB3NzaC1kc3MAAACBAKk7Cds...
"ssh cluster" means, "connect to cluster.baz.org and accept any of the
keys for hosts ONE, TWO, etc. as verification" (i.e., accept a connection
to any of those hosts). If an intruder captures the host key for
foo.baz.org, then yes, "ssh cluster" commands may be vulnerable to an
impersonated server, but "ssh two" is still safe.
This setup also abstracts out the real hostnames, so that they can change
without affecting existing typed or scripted SSH commands (which would be
"ssh one", "ssh cluster", etc.), and omits IP addresses. This is just an
example which is separate from the topic at hand; you may or may not want
to do that.
--
Richard Silverman
sl...@shore.net