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-machines-and-ssh-keys/_compare/3675f...0292bc> > 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
signature.asc
Description: PGP signature
_______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
