Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reinstate known_hosts loading and host key policy configuration #1804

Open
bitprophet opened this issue Jun 18, 2018 · 3 comments
Open

Reinstate known_hosts loading and host key policy configuration #1804

bitprophet opened this issue Jun 18, 2018 · 3 comments

Comments

@bitprophet
Copy link
Member

bitprophet commented Jun 18, 2018

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
Copy link

bb-st commented Dec 14, 2018

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
Copy link

siemer commented Jan 10, 2024

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants