We are trying to improve automation of some server processes; we use Fabric. I anticipate having to manage multiple hosts, and that means that SSH connections must be made to servers that haven't been SSH'd into before. If that happens, SSH always asks for verification of connection, which will break automation.
I have worked around this issue, in the same process, using the -o stricthostkeychecking=no
option on an SSH command that I use to synchronize code with rsync
, but I will also need to use it on calls with Fabric.
Is there a way to pass ssh-specific options to Fabric, in particular the one I mentioned above?
The short answer is:
env.reject_unknown_hosts
defaults to False
env.disable_known_hosts = True
will decide to proceed connecting to changed hosts.Read ye olde docs: http://docs.fabfile.org/en/1.5/usage/ssh.html#unknown-hosts
The paramiko library is capable of loading up your known_hosts file, and will then compare any host it connects to, with that mapping. Settings are available to determine what happens when an unknown host (a host whose username or IP is not found in known_hosts) is seen:
Whether to reject or add hosts, as above, is controlled in Fabric via the env.reject_unknown_hosts option, which is False by default for convenience’s sake. We feel this is a valid tradeoff between convenience and security; anyone who feels otherwise can easily modify their fabfiles at module level to set env.reject_unknown_hosts = True.
http://docs.fabfile.org/en/1.5/usage/ssh.html#known-hosts-with-changed-keys
The point of SSH’s key/fingerprint tracking is so that man-in-the-middle attacks can be detected: if an attacker redirects your SSH traffic to a computer under his control, and pretends to be your original destination server, the host keys will not match. Thus, the default behavior of SSH (and its Python implementation) is to immediately abort the connection when a host previously recorded in known_hosts suddenly starts sending us a different host key.
In some edge cases such as some EC2 deployments, you may want to ignore this potential problem. Our SSH layer, at the time of writing, doesn’t give us control over this exact behavior, but we can sidestep it by simply skipping the loading of known_hosts – if the host list being compared to is empty, then there’s no problem. Set env.disable_known_hosts to True when you want this behavior; it is False by default, in order to preserve default SSH behavior.
Warning Enabling env.disable_known_hosts will leave you wide open to man-in-the-middle attacks! Please use with caution.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With