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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
