Plugin info

This Plugin was derived from the very cool SCP Plugin.You can use the SSH Plugin to run shell commands on a remote machine via ssh.

Usage

First go to the global configuration page and add a SSH site.

For your job select a configured site and enter the shell commands that should be executed before and after the build.

Log will look like this.

TODO

i18n

we also need a post deploy script (ask some of the core team how to do that)

investigate stop behavior of Hudson jobs using the ssh Plugin

use same sites as scp plugin (plugin dependencies???)

...

Changelog

Version 2.6.1 (April 13 2018)

[JENKINS-19973] Option to hide ssh command in log

Version 2.6 (April 7 2018)

[JENKINS-46172] Handle NPE when not all fields are specified & save only properly configured sites

[JENKINS-10128] Set build to UNSTABLE when no SSH site is configured instead of NPE

Add Jenkinsfile to plugin

bump ssh-credentials dependency to 1.12

Add ajax validation to essential ssh host fields

INFO: the "Add Credentials" button for SSH Site don't work in recent Jenkins 2.x versions - this will be fixed in upcoming 3.0 version.(major version since plugin will have to migrate it's configuration to new format)

I have an issue. It seems that the SSH plugin presumes that the shell is bourne shell? However, in my case it is actually tcsh and this is causing some problems.

I am interested in some of the jenkins environment variables such as NODE_NAME, and this plugin is smart enough to know that (because I am referencing to this environment variable in the build section of the plugin in order to navigate to a directory on the slave). So it will set the jenkins specific environment variable before the shell scripts and such in the build section are executed. Sounds good so far. However, it tries to do an export NODE_NAME = ${NODE_NAME} and of course it fails as this is not recognized in tcsh. It should have been setenv NODE_NAME ${NODE_NAME}

. Could you update plugin and check what type of shell is default and then set up the environment variables accordingly

That's right. The "export" solution for parameterised builds won't work on VMS either, which would only understand DEFINE PARAMETER ${PARAMETER}

The problem seems to be the hard-coded command in VariableReplacerUtil.java that gets executed before the actual build:

sb.append("export "+variable+"=\""+vars.get(variable)+"\"\n");

The VariableReplacerUtil seems to already replace the parameter references inside the command strings anyway, so exporting these variables seems to be a redundant step that perhaps can be avoided altogether.

Those struggling to execute builds with parameters(esp while running .bat scripts on a remote windows server via ssh plugin) try using a '\' (backslash without quotes) just before the variable name, without any space. See example below:

We run a job on a windows server which does a database import using a .bat file, using a parameterized build

We use use a variable FileName (which is the .dmp file name to be used in import)

When I use this plugin to transfer files from Jenkins to another machine via the "Transfer Set Source files", the execute permissions of the files don't seem to carry over to the destination set of files.

Both Jenkins and the destination server that I've established an SSH connection with are running on Ubuntu 12.04. When I run the scp command manually (i.e. not from the Jenkins app) from my Jenkins server to the destination server the permissions do in fact carry over properly. Does the plugin not use the scp command internally? Does it do something that would cause this to happen?

While trying to install GIT plugins in Jenkin8.5, its failing with ssh-credentails recreation error. Already ssh-credentials is present there. I tried to delete it from jenkins85 folder but It showing error deleting file '.nfsXXXXX'

I would like to use this plugin in a Jenkins Pipeline. Is it possible? I have the plugin installed, and it works perfectly as a build step of a regular project, but I cannot see it available as part of a pipeline.