ronf / asyncssh

AsyncSSH is a Python package which provides an asynchronous client and server implementation of the SSHv2 protocol on top of the Python asyncio framework.
Eclipse Public License 2.0
1.56k stars 156 forks source link

`StrictHostKeyChecking no` SSH config file support #685

Closed craigwalton-dsit closed 2 months ago

craigwalton-dsit commented 2 months ago

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 to asyncssh.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 the known_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 see UserKnownHostsFile=/dev/null after StrictHostKeyChecking 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 be None to disable checking entirely - not recommended) or implement validate_host_public_key() or validate_host_ca_key().

Am I on the right track? Thanks!

ronf commented 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).

ronf commented 2 months ago

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).

craigwalton-dsit commented 2 months ago

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!