Pass port to ssh-keyscan when known_hosts not provided #2803
Conversation
|
The following is the coverage report on the affected files.
|
|
I plan to migrate this fix over to #2671 when this is merged. |
|
The following is the coverage report on the affected files.
|
Creds-init performs an ssh-keyscan if no known_hosts file is provided as part of a Secret. When the ssh server is using a custom port ssh-keyscan expects the port to be provided with the -p flag. Currently Tekton does not provide the flag resulting in failure to generate known_hosts. The error for this failure is also very opaque - manifesting as an "invalid flag" message in the creds-init initContainer log and making no mention of ssh-keyscan. This commit: - adds the -p flag to ssh-keyscan calls when a port is specified in the given git URL. - adds an additional note to auth.md mentioning ssh-keyscan - wraps any error returned by ssh-keyscan to mention the utility, hopefully aiding future debugging
|
The following is the coverage report on the affected files.
|
|
/test pull-tekton-pipeline-integration-tests |
1 similar comment
|
/test pull-tekton-pipeline-integration-tests |
|
nicely done @sbwsg /lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Changes
Fixes #2801
Creds-init performs an ssh-keyscan if no known_hosts file is
provided as part of a Secret. When the ssh server is using
a custom port ssh-keyscan expects the port to be provided
with the -p flag. Currently Tekton does not provide the flag
resulting in failure to generate known_hosts. The error for
this failure is also very opaque - manifesting as an "invalid
flag" message in the creds-init initContainer log and making
no mention of ssh-keyscan.
This commit:
in the given git URL.
hopefully aiding future debugging
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes