You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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!?
These are technically two separate things but they're so closely related there's no point breaking them up.
AutoAddPolicy
onSSHClient
)reject_unknown_hosts
option (defaulted toFalse
)SSHClient.connect
and thus v2'sconnect_kwargs
~/.ssh/known_hosts
SSHClient.load_system_host_keys
load_host_keys
(which can take arbitrary filename)disable_known_hosts
env/cli/etc/ssh/ssh_known_hosts
or other systemwide known_hosts filesystem_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)./etc/ssh/ssh_known_hosts
".Please note: obvious follow-ups from this include honoring a lot more of
ssh_config
such asStrictHostKeyChecking
, the options for user and system known_hosts file locations, the nuances around when/whether to write back to one'sknown_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.The text was updated successfully, but these errors were encountered: