Skip to content

[JENKINS-69149] Set 'Known hosts file' strategy as default #882

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

Pldi23
Copy link
Contributor

@Pldi23 Pldi23 commented Jul 29, 2022

JENKINS-69149 Set 'Known hosts file' strategy as default

Alternatively to #881.
Change default ssh host key checking strategy to 'Known hosts file' and add hint log for users that uses cli git and 'Accept first connection' to avoid using it on OpenSSH < 7.6.

@github-actions github-actions bot added the test Automated test addition or improvement label Jul 29, 2022
@MarkEWaite
Copy link
Contributor

I prefer this over #881 but want to do some interactive testing with CentOS 7 systems and want to check the upgrade behavior for users that have already installed the git client plugin with the security fix.

@@ -2697,6 +2698,9 @@ private String launchCommandIn(ArgumentListBuilder args, File workDir, EnvVars e

return stdout;
} catch (GitException | InterruptedException e) {
if (getHostKeyFactory() instanceof AcceptFirstConnectionVerifier) {
listener.getLogger().println("If you are using OpenSSH < 7.6 please choose another strategy to verify ssh host key in ‘Manage Jenkins’ -> ‘Configure Global Security’ -> ‘Git Host Key Verification Configuration'");
Copy link
Member

@dwnusbaum dwnusbaum Jul 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we tighten the check for printing this message? For example, if (e.getMessage().contains("unsupported option "accept-new")) { ... }.

Also, it could be nice to make the message into a hyperlink to https://plugins.jenkins.io/git-client/#plugin-content-ssh-host-key-verification using HyperlinkNote.

Also, I think you need to update README.md to update the reference to the default setting. Maybe a help.html file also needs to be updated?

One other thing - for Jenkins instances on fresh servers, KnownHostsFileVerificationStrategy will fail because known_hosts will be empty, right? That was one nice thing about AcceptFirstConnectionVerifier. Maybe we should also check what that error message is like and print a special message here in that case as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we tighten the check for printing this message? For example, if (e.getMessage().contains("unsupported option "accept-new")) { ... }.

Also, it could be nice to make the message into a hyperlink to https://plugins.jenkins.io/git-client/#plugin-content-ssh-host-key-verification using HyperlinkNote.

Also, I think you need to update README.md to update the reference to the default setting. Maybe a help.html file also needs to be updated?

done in 9dea3f2

One other thing - for Jenkins instances on fresh servers, KnownHostsFileVerificationStrategy will fail because known_hosts will be empty, right? That was one nice thing about AcceptFirstConnectionVerifier. Maybe we should also check what that error message is like and print a special message here in that case as well.

In that case the error message would be a 'usual' message, signalling that no host keys was provided for Host, see
console screenshots:

Cli git:
CliGit console

JGit:
JGit console

I guess on fresh servers known_hosts file most likely not exists, what if we manually check it and print hint message in that case? see f8d6af0

@MarkEWaite
Copy link
Contributor

MarkEWaite commented Jul 31, 2022

I'd like to see additional interactive testing to check some cases that I think might hide surprises. I hope to assist with that Monday or Tuesday so that we can merge and release this change this in the first week of August.

Interactive test results I'd like to see:

  • New install of controller on CentOS 7 (or AWS Linux 2 or ...), confirm that known hosts strategy is used as default and that ssh authenticated repository clone fails as expected because the known hosts file is not yet available. Confirm that once the known hosts file is created on the controller, then ssh authenticated repository clone passes
  • New install of agent on CentOS 7, confirm that known hosts is used as default and that ssh authenticated repository clone fails as expected because the known hosts file is not yet available. Confirm that once the known hosts file is created on the agent, then ssh authenticated repository clone passes
  • Upgrade from git client plugin 3.11.0 on CentOS 7 controller, confirm that known hosts is used as default and that it fails until the known hosts file is created (Confirmed upgrade from 3.11.0 to 3.11.2-snapshot used known_hosts when it existed and failed when it did not. This check passed. Note that the known_hosts format accepted by OpenSSH 7.4 is slightly different from the format accepted by newer versions. The simple format I use elsewhere with github.com key-type key-value was not accepted)
  • Upgrade from git client plugin 3.11.0 on CentOS 7 agent, confirm that known hosts is used as default and that it fails until the known hosts file is create
  • Upgrade from git client plugin 3.11.0 on CentOS 7 controller, confirm that known hosts is used as default and that it fails until the known hosts file is created (confirmed that clone fails on new controller until a known_hosts file is created. This check passed)
  • Upgrade from git client plugin 3.11.1 on CentOS 7 controller, confirm that previously configured strategy is not reset by the installation of the new plugin version and that it fails until the known hosts file is create (upgrade from 3.11.1 to the PR build did not retain the previous configuration. I had not saved the previous configuration, so possibly it was not retained because it had never been written to the configuration file. When I saved the previous configuration with git client plugin 3.11.1 then upgraded to this plugin, the previous configuration was retained as expected. This check passed)

@Pldi23
Copy link
Contributor Author

Pldi23 commented Aug 1, 2022

Thanks @MarkEWaite , I’ve tested all 5 cases (p3 and p5 looks the same) locally on MacOS + docker linux agent. Please re-verify fix on CentOS 7.

Could you also please test that hint message for AcceptFirstConnection displayed correctly (I don’t have environment to reproduce unsupported option "accept-new”. exception)?

Steps to quickly test it:

  1. use System with OpenSSH < 7.6.
  2. use cli git as Git installation.
  3. use 'Accept first connection' as strategy.
  4. start a build and check console displays message "If you are using OpenSSH < 7.6 please choose another strategy to verify ssh host key in ‘Manage Jenkins’ -> ‘Configure Global Security’ -> ‘Git Host Key Verification Configuration'".

@@ -54,4 +64,11 @@ public boolean verifyServerHostKey(String hostname, int port, String serverHostK
}
}

private void logHint(TaskListener listener) {
listener.getLogger().println(HyperlinkNote.encodeTo("https://plugins.jenkins.io/git-client/#plugin-content-ssh-host-key-verification/","You're using 'Known host file' strategy to verify ssh host keys," +
" but your known_hosts file not exists, please go to " +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
" but your known_hosts file not exists, please go to " +
" but your known_hosts file does not exist, please go to " +

" but your known_hosts file not exists, please go to " +
"‘Manage Jenkins’ -> ‘Configure Global Security’ -> ‘Git Host Key Verification Configuration' " +
" but your known_hosts file does not exist, please go to " +
"‘Manage Jenkins’ -> ‘Configure Global Security’ -> ‘Git Host Key Verification Configuration " +
Copy link
Contributor

@jimklimov jimklimov Aug 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be non-ASCII "funny quotes" emitted here? I think standard single-quotes can suffice to keep things simple?

Or is there a precedent for using them anyway?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's use simple quotes to be safe

Copy link
Contributor

@MarkEWaite MarkEWaite left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the changes.

@MarkEWaite MarkEWaite self-requested a review August 2, 2022 00:00
@MarkEWaite MarkEWaite self-requested a review August 2, 2022 00:35
Copy link
Contributor

@MarkEWaite MarkEWaite left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're ready to merge and release. Any objections from other reviewers?

Do we need to backport this change to other branches that were used for the security fix?

@MarkEWaite MarkEWaite added bugfix and removed test Automated test addition or improvement labels Aug 3, 2022
@MarkEWaite
Copy link
Contributor

MarkEWaite commented Aug 3, 2022

@Pldi23 I think that we should merge the 3.11.x branch into the master branch rather than merge this pull request. That has the side effect of squashing all the changes made in this pull request into the few that arrived on the 3.11.x branch. Is that OK with you?

That will then allow me to use the master branch for the 3.12.0 release that includes JGit 5.13.1 and can update the minimum required Jenkins version to something much newer than 2.289.1

@Pldi23
Copy link
Contributor Author

Pldi23 commented Aug 3, 2022

@Pldi23 I think that we should merge the 3.11.x branch into the master branch rather than merge this pull request. That has the side effect of squashing all the changes made in this pull request into the few that arrived on the 3.11.x branch. Is that OK with you?

@MarkEWaite yes, sure

@MarkEWaite
Copy link
Contributor

Thankkos @Pldi23 . I'll release 3.10.0.2 now and will try to release 3.11.2 within the next hour.

@MarkEWaite
Copy link
Contributor

Thanks to @Pldi23 for all the work on this one. Included in the master branch from #888. Closing this pull request

@MarkEWaite MarkEWaite closed this Aug 4, 2022
@MarkEWaite MarkEWaite added bug Incorrect or flawed behavior and removed bugfix labels Nov 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect or flawed behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants