Had some issues with Jenkins when trying to checkout a project with Git nested submodules. It failed with a permission error when cloning the submodules:

hudson.plugins.git.GitException: Command "git submodule update --init --recursive some/path" returned status code 128:
stdout: Submodule path 'some/path': checked out '34e663c11661b5153076c1d624ead25137df0783'

stderr: Cloning into 'some/other/path'...
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of '[email protected]:foo/foo.git' into submodule path 'some/other/path' failed
Failed to recurse into submodule path 'some/path'

In the Jenkins job, checking out submodules is enabled: In the Git plugin under Advanced sub-modules behaviours, the options Recursively update submodules and Use credentials from default remote of parent repository are enabled. All git repositories are private Github repositories, but the Jenkins user has read access to them.

The only way to get it working as by replacing git@... URLs by https://.... For instance, this here would fail

[submodule "foo"]
    path = some/path
    url = [email protected]:foo/foo.git

... but this would work

[submodule "foo"]
    path = some/path
    url = https://github.com/foo/foo.git

I cannot rule out that there is a misconfiguration on our end. But still I have some generic understanding question:

  • Does the Jenkins Git plugin support git@ URLs? Or is it a known limitation that you need to use https://... URLs?
  • Why does the choice of the protocol make a difference on Jenkins? Is it because git@ assumes that SSH keys of Jenkins were added to the Github repository?
  • Host key verification failed
    – 030
    Apr 16, 2018 at 13:57
  • @030 My guess is that "git@" fails because the SSH key is not properly installed. That would mean it is a configuration error and not a limitation of Jenkins. Apr 16, 2018 at 14:00
  • What happens if you do a git clone on the Jenkins server?
    – 030
    Apr 16, 2018 at 14:02
  • @030 Have not access to the machine myself. But I'll try to look into that direction. Looks like that is the root of the problem. Apr 16, 2018 at 14:03

2 Answers 2


As a reference, it works for our system, submodules over SSH. We use deploy keys for this purpose. In Gitlab they can be found under Settings --> Repository --> Deploy Keys. The used key has to be marked as Enable in each used Git repository (main and submodules).


Are the credentials you are using a username/pass or token? If so, that will work for http cloning, but will fail for git@ since that uses ssh keys to authenticate.

There is another option you can select called "Checkout over SSH" that comes from the Github Branch Source Plugin. You will need to add a new "SSH Username with Private Key" credential to Jenkins where you can select to either upload a private key, use a file, or use the one on jenkins master (usually ~/.ssh/id_rsa). The corresponding public key will need to be added to your Github profile or repo settings.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.