On 07.02.2017 21:25, Martin Pitt wrote:
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.
In large and properly setup systems/clusters, all the known hosts will
be made globally available. Either via a shared drop in file ... or a
better example of this is how FreeIPA uses the following configuration
option to lookup known hosts from the directory:
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
So I would be cautious here about having another way to distribute SSH
known hosts. /etc/ssh/known_hosts is a well known format and there's
lots of tooling for populating it.
Note that in the corner case, even if the dashboard machines were
prepopulated and SSH known host were missing, then the user will be
prompted in Cockpit with the fingerprint when accessing the machine.
Lastly, if we do need to add this feature later (ie: an additional host
key field in the machines/foo.json file) we can certainly add it without
backwards compatibility problems.
Stef