Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- hostkeys and ssh2
- Ole Michaelsen
May 18, 2005, 2:59 pm
rate this thread
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 key_22_callisto.pub
-rw------- 1 mbx51 users 750 May 18 13:45 key_22_cdrxfr.pub
-rw------- 1 mbx51 users 749 Feb 3 16:11 key_22_europa.pub
-rw------- 1 mbx51 users 748 Feb 3 16:08 key_22_thebe.pub
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,
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?
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...
Re: hostkeys and ssh2
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 zip.com.au)
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.
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum