<p>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 <em>Settings</em> --> <em>Repository</em> --> <em>Deploy Keys</em>. The used key has to be marked as <em>Enable</em> in each used Git repository (main and submodules).</p>

CC BY-SA 3.0
2018-04-23T06:52:54.380Z
2018-04-23T06:52:54.380Z
Moritz
<p>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. </p>

<p>There is another option you can select called "Checkout over SSH" that comes from the <a href="https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Branch+Source+Plugin" rel="nofollow noreferrer">Github Branch Source Plugin</a>. 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 <code>~/.ssh/id_rsa</code>). The corresponding public key will need to be added to your Github profile or repo settings.</p>

CC BY-SA 3.0
2018-04-19T22:48:56.830Z
2018-04-19T22:48:56.830Z
Ilya
<p>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:</p>

<pre><code>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 'git@github.com:foo/foo.git' into submodule path 'some/other/path' failed
Failed to recurse into submodule path 'some/path'
</code></pre>

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

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

<pre><code>[submodule "foo"]
    path = some/path
    url = git@github.com:foo/foo.git
</code></pre>

<p>... but this would work</p>

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

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

<ul>
<li>Does the Jenkins Git plugin support <code>git@</code> URLs? Or is it a known limitation that you need to use <code>https://...</code> URLs?</li>
<li>Why does the choice of the protocol make a difference on Jenkins? Is it because <code>git@</code> assumes that SSH keys of Jenkins were added to the Github repository?</li>
</ul>

CC BY-SA 3.0
2018-04-16T13:57:25.023Z
Host key verification failed
030
CC BY-SA 3.0
2018-04-16T14:00:40.210Z
@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.
Philipp Claßen
CC BY-SA 3.0
2018-04-16T14:02:02.550Z
What happens if you do a git clone on the Jenkins server?
030
CC BY-SA 3.0
2018-04-16T14:03:02.517Z
@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.
Philipp Claßen
<jenkins><git><jenkins-plugins>
Does Jenkins support cloning git submodules with "git@" (not "https") URLs?
Philipp Claßen
# Does Jenkins support cloning git submodules with "git@" (not "https") URLs?

(Asked by: username_0 on 2018-04-16)

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 'git@github.com: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 = git@github.com: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?

**Tags:** jenkins, git, jenkins-plugins

> **Comments:**
> **username_1**: Host key verification failed  
> **username_0**: @username_1 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.  
> **username_1**: What happens if you do a git clone on the Jenkins server?  
> **username_0**: @username_1 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.  

---

## 2 answers

### Answer by username_2 on 2018-04-23. Score: 2 | Accepted answer

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).


---

### Answer by username_3 on 2018-04-19. Score: 1

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](https://wiki.jenkins-ci.org/display/JENKINS/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.


---

