ssh not using StrictHostKeyChecking=no with UserKnownHostsFile=/dev/null

[trini]

Related to #1503 is there a reason to not use both of the above options? The use case I have at the moment is that we have an exporter per device under test and I'm trying to automate in Gitlab testing jobs without having to populate the docker container tests run from with too much prior knowledge. Thanks!

[Emantor]

We still rely on OpenSSHs security model for exporter authentication, so we want to require the user to at least verify that he connects to a trusted host before uploading any artifacts. However I do understand that with modern containers this is currently somewhat of a mismatch. With the current implementation we also override the default in the configuration file, so our usual advice to modify the SSH configuration file is also not possible.

I don't see the prepopulation of the known_hosts file you mentioned on matrix as a workaround, rather as the correct way to ensure that the containers to connect to trusted exporters.

[jluebbe]

If you regularly create new exporters (with new hosts keys), you can avoid having to distribute the public keys by using SSH certificates: https://liw.fi/sshca/
In that case, you only add the cert authority entry in your known_hosts.

[trini]

In this case, we're running the tests from containers, and while the coordinator is a real system, every device has it's own Pi with an OpenEmbedded-based intentionally minimal and insecure OS as the exporter (and it is also a labgrid known device, so it can be power cycled as needed) and so configuration is stored elsewhere and they too aren't "trusted" devices in some sense. For the record, what I've done for now is use ssh-keyscan to populate the known_hosts at runtime and so not have to populate the CI job or container with any possibly "secure" knowledge. Is there some way to make the behavior configurable, with the default being secure but possible to configure as insecure?