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 · 1 comment
Open

Reinstate known_hosts loading and host key policy configuration #1804

bitprophet opened this issue Jun 18, 2018 · 1 comment

Comments

@bitprophet
Copy link
Member

@bitprophet 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 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.

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

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.