Hello,
Stef Walter [2017-02-07 15:49 +0100]:
It's worth noting that Peter Volpe is moving the libssh code
that
consumes SSH keys ... and I believe he has working code for using
/etc/ssh/known_hosts.
Noted, I'll coordinate with him.
> I'd appreciate some feedback about whether this makes sense,
and opinions about
> the per-user → global SSH host key transfer [1].
The intent has been that once the dashboard is setup by a single user on
the system it becomes usable by all users on the system. Hence the
global storage of SSH keys was driven by that.
That's the sort of design feedback I was looking for, I wasn't aware of that
design goal. As this is restricted to admins (I just checked that as a
non-admin I cannot add servers at all), this makes more sense and justifies
being different to ssh's default behaviour. I adjusted the wiki:
<
https://github.com/cockpit-project/cockpit/wiki/Config-format-for-known-m...
However we should have always used /etc/ssh/known_hosts. I believe
/var/lib was an implementation detail from before we had "{ superuser:
true }" [0] style privilege escalation.
Makes sense to use that for new hosts, and either move or always read the file
in /var too.
It still seems that for the purpose of programmatically pre-seeding machines it
makes sense to be able to put a host key right into a machines/foo.json file,
as otherwise we'd have the same "concurrent racy access" problem as for
machines.json itself.
Thanks,
Martin