customizable host key policy #2076
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
cc @bitprophet . As an aside I think it is well overdue for fabric to offer a sensible & secure default for users and not blindly auto-add ssh keys. Of course changing the default behaviour would require a new major (if following semver) version bump. |
bitprophet
force-pushed
the
main
branch
2 times, most recently
from
67e9029
to
21b24d2
Compare
This is essential in case we want Fabric library consumers and users to override the Paramiko host key policy. One, for example, might want to override the default to prompt users when a new key needs to be added (which is silently done by default right now).
This removes the Fabric-specific host key policy which is to automatically accept new keys. I don't see why Fabric would do anything different than the default here at this stage, especially since we don't seem to be *loading* any keys, let alone saving them. This is a stopgap measure to fix fabric#2071
anarcat
force-pushed
the
host-key-policy
branch
2 times, most recently
from
0003d38
to
19db567
Compare
This has the following consequences:
1. the AutoAddPolicy starts to work correctly, as the
`load_host_keys` call signals that it should save new fingerprints
to the known_hosts file
2. it will also correctly *fail* if the fingerprint on a host
changes, which was *not* the case before, as the known_hosts file
was never loaded
3. it will correctly load the right `UserKnownHostsFile` according to
the rules defined in the ssh configuration
Regarding the last point, that is essential in my setup because I have
a config block like this:
Host *.example.com
UserKnownHostsFile ~/.ssh/known_hosts.example.com
... which allows me to "group" known_hosts file and synchronize them
from remote servers.
This covers the following use case:
Host *.example.org
UserKnownHostsFile ~/.ssh/known_hosts ~/.ssh/known_hosts.example.org
... which is also valid.
This makes it easier to monkeypatch to earlier versions. With this
patch, I can copy-paste the setup_ssh_client() function into my code
and monkeypatch older fabric versions with:
# hack to fix Fabric key policy:
# fabric#2071
def safe_open(self):
SaferConnection.setup_ssh_client(self)
Connection.open_orig(self)
class SaferConnection(Connection):
# this function is a copy-paste from fabric#2072
def setup_ssh_client(self):
# [...]
Connection.open_orig = Connection.open
Connection.open = safe_open
This is otherwise a noop.
The argument here is that it's a really bad idea to silently accept new keys. It's not how SSH works, and it's not how Fabric *should* work. If we'd work like SSH, we'd *prompt* the user, but the WarningPolicy doesn't do that, it just warns. At the very least those policies should noisily warn the user when the host keys get changed, but that's something Paramiko must do.
anarcat
force-pushed
the
host-key-policy
branch
from
22f6a3d
to
2f0108e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current Fabric code does not check or save SSH host keys at all. This PR fixes the problem by ensuring we properly call the Paramiko SSH keys loader when we create our connection object.
We also load the right UserKnownHosts file based on the ssh_config, which paramiko does not do out of the box.
We might want to push the latter into paramiko, but first it seems to me the default Fabric policy of "everything goes" should b fixed.
Note that this also allows callers to override the AutoAddPolicy that is currently in use.
This should fix #2071
This is a rebase of #2072 on top of master (instead of 2.0, see #1929 for that) and with #1960 merged (instead of #2073) to fix the docs.