hostkeys and ssh2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

In my home directory, /app/mbx51/.ssh2/hostkeys, I have one key for each
host that I connect to.

drwx------   2 mbx51    users       8192 May 18 13:45 .
drwxr-xr-x   3 mbx51    users       8192 Sep 27  2004 ..
-rw-------   1 mbx51    users        751 Feb  3 16:00
-rw-------   1 mbx51    users        750 May 18 13:45
-rw-------   1 mbx51    users        749 Feb  3 16:11
-rw-------   1 mbx51    users        748 Feb  3 16:08

europa, callisto, and thebe are physical servers. cdrxfr is the hostname
(with an ip address) of a cluster service running on either europa,
callisto, or thebe. When the cluster service moves between the cluster
nodes, connecting to it with ssh2 will fail because ssh2 notices that
the hostkey has changed.

With OpenSSh I can just have differnt keys in the same hostkeys file,
like this:

/app/mbx51/.ssh/ known_hosts2

cdrxfr ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA4urcrqMGy0ZqgGqt04d ...
cdrxfr ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAyj49axLVHYN6k2jZvBz ...
cdrxfr ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAq5GxvSRL8vNpcLATpAv ...

but I seem unable to concatenate the hostkeys of europa, callisto, and
thebe above with ssh2 into one file. ssh2 still thinks that the key has

How do I put the keys of the three servers into one keyfile? How should
the format of that combined file be?


Ole M.

Re: hostkeys and ssh2

I've never found a way to do this with Tectia.  The keys are indexed by
filename, and it only reads one key per file -- so I don't see how to
indicate more than one key per destination name.  I don't recall asking
SCS about it explicitly.  On the other hand, they've reviewed two editions
of the book which said you can't do this with their software, and have
never indicated how...

  Richard Silverman

Re: hostkeys and ssh2

Quoted text here. Click to load it

If feasible, you could arrange for the hostkey to be the same no matter
which node the production service is on.

There's a couple of ways of doing this:

a) The easy way: use the same host key on each physical node.  This means
that anyone compromising one host can perform an MITM between the client
and any other server.  This may or may not be a problem depending on your
configuration (eg, if all of the servers are under the same administrative
control then it's probably an acceptable risk).

b) Arrange for a dedicated SSH service to be running on the production
node, and fail this service over with the rest of your cluster services.
For an OpenSSH server, this means running two sshd's, one with a
ListenAddress of the host address and the host's keys, and another with a
ListenAddress of the cluster address and separate keys for the service's
key (configuration details for other software will vary).  This is
probably only feasible if you have an active/standby configuration.

Darren Tucker (dtucker at
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Site Timeline