As you might have noticed, some time ago, Jenkins was updated to version 2.361. This new release includes new updates to the Git Client Plug-in. SSH host key verification is now enabled by default (see JENKINS-69149).

Configure SSH host key verification

Following a security fix from Jenkins Security Advisory 2022-07-27, the Git Client Plug-in now has SSH host key verification enabled by default using the Known Hosts file strategy. Any Git / checkout step that uses the SSH protocol now performs strict host key verification based on the ~/ssh/known_hosts file in its environment. Impacted builds fail to check out the code and show the following error:

stderr: No host key is known for, and you have requested strict checking.

The Git Client Plug-in README describes the kinds of configurations allowed:

  • Accept first connection: Remembers the first host key encountered for each Git server and requires the same host key to be used for later access. This is usually the most convenient setting for administrators while still providing ssh host key verification.
  • Known hosts file: Uses the existing known_hosts file on the controller and the agent. This assumes the administrator has already configured this file on the controller and all agents.
  • Manually provided keys: Provides a form field where the administrator inserts the host keys for the Git repository servers. This works well when a small set of repository servers meet the needs of most users.
  • No verification: Disables all verification of SSH host keys. Not recommended because it provides no protection from "man-in-the-middle" attacks.

Configure the host key verification strategy by navigating to Manage JenkinsConfigure Global SecurityGit Host Key Verification Configuration (Figure 1).

Host Key Configuration
Figure 1: Host Key Configuration

But how can we automate this in our Jenkins Source-to-Image (S2I) strategy? The next section will describe how you can achieve it.

Jenkins Source-to-Image

Red Hat introduced Jenkins Source-to-Image (S2I) feature, which simplifies customization of the official Jenkins image through the S2I build process. You can use Jenkins S2I to copy your custom Jenkins job definitions and additional plug-ins or replace the provided config.xml file with your own custom configuration. The resulting image is stored in the Red Hat OpenShift registry and can be used to deploy pre-configured Jenkins instances.

Groovy script

We can create a new Groovy script that will be executed each time the image runs. The location of the file needs to be created under the path /configuration/init.groovy.d/.groovy

#!/usr/bin/env groovy

import jenkins.model.*

import org.jenkinsci.plugins.gitclient.verifier.*

import jenkins.*

import hudson.model.*


import java.util.logging.Level

import java.util.logging.Logger

final def LOG = Logger.getLogger("APP")

def hostKey = System.getenv('HOST_KEY')

if (!hostKey) {



LOG.log(Level.INFO,  'running host-key.groovy' )

def instance = Jenkins.getInstance().getDescriptor("org.jenkinsci.plugins.gitclient.GitHostKeyVerificationConfiguration")

//strategy = new NoHostKeyVerificationStrategy()

strategy = new ManuallyProvidedKeyVerificationStrategy(hostKey)


Reviewing the above code, we can see how the script tries to get a value from an environment variable called HOST_KEY. If the variable doesn't exist, we use a default one. The rest of the code retrieves the GitHostKeyVerificationConfiguration object, sets a new manual provided strategy, and adds the key that we retrieved previously. The last sentence saves the configuration.

Configuration as Code plug-in

If you use the Configuration as Code plug-in to set up your Jenkins configuration, there is also a way to set up your host key by updating the above example as follows:

        approvedHostKeys: {HOST_KEY}

I hope that this helps you to automate your Jenkins installation.