[PATCH] verify against known fingerprints

[Phil Pennock]

On 2014-02-18 at 08:19 -0500, Hubert Kario wrote:
> > I've just written this patch, it's undergone minimal testing and "works
> > for me" and I'm after feedback as to acceptability of approach, anything
> > I should be doing differently for the feature to be acceptable upstream
> > and what I should be doing about automated testing.
> > 
> > Use-case: you have the host's SSH fingerprints via an out-of-band
> > mechanism which you trust and want to be able to connect and have
> > verification use those known-good fingerprints and, if they match,
> > update known_hosts.
> 
> Since you already have an out-of-band communication, why not provide
> a pre-populated ~/.ssh/known_hosts file though it?

That is what this tool is being used to provide; I have out-of-band
trustworthy access to the hostkey fingerprints, nothing else.  I am
_providing_, to my colleagues, out-of-band SSH configuration and
known_hosts.  The intent is not that everyone always use this option,
but that it be used by the person updating known_hosts.  Everyone else
just does a `git pull` and a `merge_ssh` from that repo, reviewing
output as they see fit.  It won't scale to continuously changing sets of
hosts, but it will scale well enough for now, and I suspect that any
improvement will still leverage this patch because, fundamentally, the
only trust anchor information we have access to is the host key
fingerprints.

The OOB links now are "us to Amazon", which gets me fingerprints, and
"between us, using trusted git (with audit history)", which currently
risks being a leap of faith.  This patch lets me link those two OOB
paths, with no leap of faith connecting to machines out in the cloud
across networks which we don't control.

Without this patch, I can connect, accept, copy out the entry from
known_hosts to a file on its own, massage, use ssh-keygen to get a
fingerprint and compare to the trusted form; when done, commit to the
git repo.  It's hassle, I've done it, I want to not make this our
procedure which others, less paranoid than I, follow when others are
depending on the result.

With this change, we're providing the same sort of trust anchoring as
VerifyHostKeyDNS, but from a file, so that any kind of user tooling can
be used to provide the anchors, instead of DNS+DNSSEC.

Work-flow: bring up cluster, use tool to grab hostkey fingerprints for
every machine.  Add IPs to configuration template, invoke tool to
generate/merge SSH configuration.  Use new wrapper tool to repeatedly
invoke ssh using the new option, grabbing the actual public keys in a
verified manner, and prepping an updated configuration for commit.
Review, commit, push.

Apologies for the verbosity of this email, I'm trying to make it very
clear what trust paths do and don't exist and why this patch is Rather
Quite Helpful.  Think of this patch as "scriptable VerifyHostKeyDNS".

-Phil