I can’t be the first person to try and do this[1], but didn’t get any Google love when trying to solve this problem, so here is my attempt to fix that.

Jenkins has support for Git through, unsurprisingly, the Git plugin, but unlike its SVN plugin, there is no configuration option to say ‘use this public key whilst trying to access the repo’. This is not a problem if the user Jenkins is running as has their keys all correct — as is usually the case for me and my local-to-my-laptop instance.

Things are not that straight forward when you get remote nodes and Windows into the mix.

The problem is that if you let Jenkins manage the node, which I think you should, then it runs as the LocalSystem user (even though you have to give it user credentials to access the machine…). This is of course a magic user in the Windows [XP] scheme of things and so does not have a user directory — thus no .ssh/id_rsa* files. The trick here is to change the user that the service runs as from LocalSystem to a ‘real’ one — one that has ssh working. There are two ways to do this. The easiest is to open the properties of the service and in the ‘Log On’ tab, change things as you would like. The other way is to use the ‘sc’ command.

<pre lang="batch">sc config service_name obj= username password= password type= own

Yes, you need the space after the =. The type= says that this server does not interact with the desktop as only LocalSystem services can do that. I also believe you need to include the domain of the user (foo\username) even if it is not attached to a domain (.\username).

It is probably easier to just use the UI for this.

After restarting the service and the Jenkins node you should be able to clone that private Github repo. Right? Well, no. See, there is a apparently a bug with Windows remote nodes where the home directory isn’t set correctly so it still has no idea where to find the .ssh directory. That is easily addressed though in the node configuration screen by setting an Environment Variable pair.

  • Name: HOME
  • Value: $USERPROFILE

Now you should be able to access private repos using certificates.

[1] Actually, I know I’m not since the solution was cobbled together from a couple people in #jenkins