Partially mitigate StrictHostKeyChecking=no issue #1023
Merged
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.
From issue #696:
I by myself have been guilty of using this (added this to the Hetzner backend), because I did actually misunderstand the meaning of setting this option to
no
. My understanding was that it will refuse to connect whenever an existing host key is different from that in known hosts.However, this turns out to be only true for keyboard interactive or password authentication and if we're using pubkey auth, OpenSSH will happily connect.
Now the real fix for this (already deploying with a pre-generated host key) is a bit more involved, but we can mitigate this for now, because since OpenSSH 7.5 there is the
accept-new
option toStrictHostKeyChecking
, which does exactly what I thought "no" would do: