known_hosts file on trusted server

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

Threaded View
I have a server (server a)  that needs to login via ssh to other
freshly imaged servers (server b).

Part of the imaging process copies authorized_keys from a to b. so the
clients are happy.  Once server b is reimaged I have to delete the
known_hosts file on server a.

This is no good, I need to set it and forget it.. whats the quick and
dirty fix?

Re: known_hosts file on trusted server

Quoted text here. Click to load it

The easiest is to copy back old SSH keys when you image the machine.
This can be done via any number of means, including an rsync server
that is IP address specifically configured: individual hosts get
individual downloadable keys.

SSH keys are useful, but their reliability for identifying hosts
is..... not thought out end-to-end. There is no good mechanism for
expiring and replacing the host keys in an authenticated fashion,
there is no central signature authority or chain of trust to establish
them as there are for SSL and PGP keys, and people are far too willing
to accept the keys of unknown hosts. This actually represents a very
real attack vector for man-in-the-middle attacks, and a monitoring
technology for some of the more sophisticated network tools to monitor
all your traffic. SSH is very powerful and effective for protecting
the traffic from casual monitoring, but it's not currently that
effective for authenticating the actual server, itself. Without robust
protection of the host keys on the server, and without reliable
authentication of those keys, it's not effective against governments
willing to subpoena, or steal, hostkeys and set themselves up for man-

And don't get me *STARTED* on the casual "D000dz! Use My SSH Pr0xy t0
pr0teC7 y0ur An0nyM0us3 3ecr3tZ!!!!" sites I've seen popping up during
my career.

Re: known_hosts file on trusted server

Quoted text here. Click to load it

Hi Nico,

There's an important point to be made here: everywhere in your
discussion, you sould replace "SSH" with "OpenSSH."  The problems you're
discussing are limitations of the OpenSSH software, not SSH as a
protocol.  There are several commercial implementations which support
robust, manageable, scalable methods of server authentication.  Both
Tectia and VanDyke have Unix SSH servers which implement both X.509
certificate and Kerberos key exchange mechanisms, and have done so for a
long time.  By comparison, although OpenSSH has had Kerberos *client*
authentication for some time, the OpenSSH project has for ages refused
to integrate Simon Wilkinson's excellent patches for GSSAPI key exchange
-- though this lack is mitigated by the fact that the major Unix players
*do* integrate his work into their distributions, so this feature is in
fact widely available.  It's a shame more people aren't comfortable
deploying Kerberos; it provides effortless single-signon and server
authentication, and across many more platforms and technologies than
just SSH (I've been working a great deal with Kerberos over the past few

Failing Kerberos, the OpenSSH folks have recently gotten around to
providing server public-key certificates -- but, they decided to
completely eschew standards, inventing their own certificate format and
system rather than using X.509.  This ensures that, even if you've
already deployed a PKI, you can't leverage that work.

The whole point of Kerberos and PKI is to build it once, addressing the
distributed trust and authentication problem in an overall fashion, and
then get everything you possibly can to use it.  OpenSSH ignores both
technologies, pretty much the only games in town these days.  It's an
odd set of choices.

- Richard

Site Timeline