Fail fast on SSH hostkey mismatch on remote-exec provisioning#38881
Fail fast on SSH hostkey mismatch on remote-exec provisioning#38881akaokunc wants to merge 2 commits into
Conversation
|
Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement Learn more about why HashiCorp requires a CLA and what the CLA includes Have you signed the CLA already but the status is still pending? Recheck it. |
…mporary and retrying until timeout.
8ca4c5d to
7706e9a
Compare
|
Hi @akaokunc, thanks for this submission. A few points of consideration. First, for this PR to be reviewable you will need to sign the CLA per this comment: #38881 (comment) Second, typically a PR needs to be connected to an existing issue and the discussion of the solution posted to that issue before implementation. Please see our Contributing.md, specifically the Proposing a Change section: https://github.com/hashicorp/terraform/blob/main/.github/CONTRIBUTING.md#proposing-a-change Finally, the provisioners are not being prioritized for improvement at this time, so it may be unlikely that this PR will be reviewed. All of that said, please sign the CLA and I will raise this in triage for consideration as it seems like a simple fix. Thanks! |
|
the bastion path still retries though — a bad bastion_host_key comes back through c.config.connection() as a plain err and returns up at the c.conn, err = c.config.connection() check, never reaching this fatalError guard. and BastionConnectFunc wraps it as |
Hello, I have noticed that when using the SSH hostkey checking in remote exec provisioner terraform spins in a loop until the timeout period passes on the resource if the SSH hostkey does not match. This is pretty inconvenient especially when connecting to servers using fail2ban, because it leads to instant blocking of the caller. I have found the code used for handling the errors and seems that it is quite simple to convert the hostkey mismatch errors to fatal error. Built the codebase with this patch and verified in our usecase. Now I can see almost immediately after applying that the resource fails with useful error message, so the operator can go ahead and fix the issue before getting locked out.
Target Release
1.16.x
Rollback Plan
Changes to Security Controls
CHANGELOG entry