We have a Jenkins server that uses the SSH plugin to configure a SSH remote hosts within the global Jenkins configuration. These ssh connections are using a public/private key for authentication to the remote host.
We then use these configured SSH remote hosts in the build step “Execute shell script on remote host using ssh” (I believe this is also part of the SSH plugin) in a number of jobs.
The problem I’m having is that any job using the execute shell script on remote host using ssh must be running on a Windows slave, since I haven’t found a way to put in some sort of relative path to the keyfile.
On windows the file would be located at: C:Users<username>.ssh
On linux the file would be located at: /home/<username>/.ssh/
I’ve tried many iterations of using system environment variables, setting environment variables on the node configuration page and using these as part of the keyfile path without any luck.
Am I missing something? Is there a better way to handle it. There must be a way to manage keyfile locations and differences between ssh remote hosts across slaves.
Advertisement
Answer
Unfortunately, I believe there isn’t a way to specify a relative path — the keyfile path configured must be the same on every build slave. Far from ideal, I know.
I’m not sure how Windows would handle it, but perhaps something like /ssh/whatever.key would work, if you were to place the file at c:sshwhatever.key and /ssh/whatever.key for Windows and Linux machines, respectively.
In any case, the plugin has since been modified to use the Jenkins Credentials plugin, which allows you to manage username/password or private key-based credentials from the Jenkins UI, without having to place files on disk.
However, although this has been integrated into the SSH plugin, there has not yet been a new release containing this functionality, but it looks like it should be coming “soon”.
So if the workaround doesn’t work, you can try to:
- Wait for a new release
- Post on the jenkinsci-users list to ask about a new release
- Download and install a recent build of the plugin
- (though I would be careful to back up the existing job config before trying this; or try it on a separate Jenkins instance)