Page MenuHomePhabricator

gerrit reviewer-bot should trust global SSH known_hosts
Open, LowPublic

Description

We have a global SSH known_hosts file that is generated and used by other tools such as sre-laptop to populate local known_hosts files.

https://config-master.wikimedia.org/known_hosts

For the recent T240266 - Gerrit host key change we added support for having (multiple) custom keys in there for use cases such as the Gerrit SSH that is separate from regular server SSH on port 22.

And added the new key to it in advance of removing the old key.

If gerrit reviewer-bot could trust this one too then we can avoid future T434075 - Reviewer-bot not adding reviewers due to SSH key change

So this is a feature request for reviewer-bot to trust that data.

Event Timeline

Dzahn renamed this task from gerrit reviewer-bot should trust global knw to gerrit reviewer-bot should trust global SSH known_hosts.Wed, Aug 5, 6:31 PM
Dzahn added a project: Gerrit.
Dzahn updated the task description. (Show Details)

The known hosts file is not provisioned into Toolforge containers, and if it was it would be a point in time copy rather than a live file managed by Puppet or other automation. This makes attempting to use it inside a tool bespoke and likely awkward.

For a tool like https://github.com/valhallasw/gerrit-reviewer-bot (which also uses an external bug tracker currently), I think it is much more reasonable to disable host key validation. There really is not a man-in-the-middle threat to defend against in setting gerrit reviewers or reading an event stream like wikibugs does. When I ported Wikibugs to the asyncssh library I just used it's known_hosts=None connection setting to disable host key checking (src/wikibugs2/gerrit.py). For something shelling out to OpenSSH like gerrit-reviewer-bot currently does I would use -o StrictHostKeyChecking=no -o CheckHostIP=no.

Reported upstream at https://github.com/valhallasw/gerrit-reviewer-bot/issues/30.

Someone start the timer to see how long until @valhallasw replies that it would be great if someone else took over the tool. ;)

Dzahn triaged this task as Low priority.Thu, Aug 6, 10:30 PM

to collab team: wanted to share it but priority low since it's only about next time a host key changes.

Maybe the part that a human is asked and has to approve like it happened here is also the feature for this particular case.

The comments by bd808 make sense to me; though I was about to talk about the option StrictHostKeyChecking accept-new which makes it //automatically add new host keys to the user's known_hosts file, but will not permit connections to hosts with changed host keys//.. (1).

That is what I recently wanted to use when I tried to fix the rename-project plugin replication (gerrit:1311500).

Maybe it also makes sense here.