Reinstate known_hosts loading and host key policy configuration

[bitprophet]

These are technically two separate things but they're so closely related there's no point breaking them up.

• Rejection/ignoring of unknown host keys
  • v1 ignored by default (by setting an AutoAddPolicy on SSHClient)
  • v1 allowed users to turn that off via env/cli reject_unknown_hosts option (defaulted to False)
  • v2 currently also ignores by default, but needs to reinstate configuration somehow, since this is not a behavior controllable via SSHClient.connect and thus v2's connect_kwargs
• Loading of ~/.ssh/known_hosts
  • v1 loaded by default by calling SSHClient.load_system_host_keys
    • P.S. that is an incredibly confusing name since it loads user level host keys and seems to only be named that to differentiate from the little-used load_host_keys (which can take arbitrary filename)
  • v1 allowed disabling of that default via disable_known_hosts env/cli
  • v2 does not load anything by default, so needs an option to do so
  • Double check what OpenSSH does; IIRC OpenSSH always loads known hosts by default so we should follow that, even if it means that behavior goes into a 3.0 milestone.
• Loading of /etc/ssh/ssh_known_hosts or other systemwide known_hosts file
  • v1 optionally allowed this as a wholly configurable system_known_hosts option (i.e. it required the user to always supply a value, and did not care whether it conformed to OpenSSH standards or not).
  • v2 doesn't do this at all; I suspect that it should follow OpenSSH as with user known hosts loading, which seems to be "load /etc/ssh/ssh_known_hosts".

Please note: obvious follow-ups from this include honoring a lot more of ssh_config such as StrictHostKeyChecking, the options for user and system known_hosts file locations, the nuances around when/whether to write back to one's known_hosts files when encountering new host keys, and so forth. That sort of thing should probably live in other tickets unless the implementer of this ticket is super enthusiastic.

[bb-st]

Does this mean fabric v2 does not support checking of known_hosts at all? If so that sounds like a critical security problem as MITM attacks are then trivial. Surely there is a way to enable StrictHostKeyChecking and specify a known hosts file such as /etc/ssh/ssh_known_hosts?
Without this it will prevent me from upgrading from 1.x if I can't ensure security of the connection.

[siemer]

Does this mean fabric v2 does not support checking of known_hosts at all? If so that sounds like a critical security problem as MITM attacks are then trivial. Surely there is a way to enable StrictHostKeyChecking and specify a known hosts file such as /etc/ssh/ssh_known_hosts? Without this it will prevent me from upgrading from 1.x if I can't ensure security of the connection.

...roughly five years later: is it still as insecure as this comment + issue text suggests in v2!?

[codeananda]

We are now on v3 but this is still not implemented. @bitprophet any update?

Seems like quite a fundamental thing missing. How can we disable host checking?

I've had to resort to using pysftp to connect which is a shame. See this SO answer