Closed craigwalton-dsit closed 2 months ago
Yes - that's all correct. One other factor is that AsyncSSH generally tries to avoid interactively prompting the user for anything, which happens for some values of StrictHostKeyChecking, and in cases where it doesn't prompt, you run the risk of man-in-the-middle attacks.
As you said, you can get called back with new host keys by using validate_host_public_key()
or validate_host_ca_key()
, and once you've decided to trust the key you could even potentially write the key to one of the known hosts files. However, that decision is left to the application.
AsyncSSH also recently added support for the OpenSSH "hostkeys" extension, which lets you specify a callback via a new server_host_keys_handler
option that will be called with information about how the server's host keys compare with what's currently in the known hosts files. Host keys are reported as either added, removed, retained, or revoked, and the application can decide what changes, if any, to make to the known hosts files. This requires server support for this option, and only works when the host key presented by the server is present in the current known hosts list (or otherwise confirmed as trusted via the validate callbacks).
One note on the server_host_keys_handler
option: This was added in AsyncSSH 2.16.0, but that version had a regression (introduced in 2.15.0). So, if you want to try that out, I would recommend picking up 2.17.0, (released yesterday).
Thank you so much for the detailed response and description and tradeoffs of available options.
I'm still figuring out how exactly we want to manage known host checking for SSH servers belonging to a collaborator, so I will discuss this with them, armed with these various useful options. I'll close this - thanks!
Thanks for this great library!
I think I've answered my own question by reading the docs and issues, but wanted to check it is intended behaviour and make sure I understood the rationale.
I was hoping that asyncssh would respect the
StrictHostKeyChecking no
in the relevant part of the SSH config file which I pass toasyncssh.connect()
.It doesn't appear to be respected. And this is not one of the documented supported client config options.
I this may be intentional because
StrictHostKeyChecking no
results in theknown_hosts
being modified and asyncssh does not want to be modifying config files (as described in https://github.com/ronf/asyncssh/issues/237). Note: you sometimes seeUserKnownHostsFile=/dev/null
afterStrictHostKeyChecking no
in SSH config files to avoid this behaviour (and to avoid warnings about mismatched keys).Instead, I can use the
known_hosts
parameter (which can even beNone
to disable checking entirely - not recommended) or implementvalidate_host_public_key()
orvalidate_host_ca_key()
.Am I on the right track? Thanks!