Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-45312

expose the user of the credentialId used by sshagent

XMLWordPrintable

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • ssh-agent-plugin
    • None

      As described here https://support.cloudbees.com/hc/en-us/articles/218497418-How-to-expose-a-passphrase-authenticated-SSH-key-stored-in-Jenkins-to-the-Docker-instance we can use the sshagent to authenticate to a ssh target, but one still has to provide the username explicitely. If for some reason no only the key, but also the user changes, the script has to be adjusted aswell.

      It would be useful to access the user that is provided in the ssh credential and have it injected as environment variable. e.g.

       

      node {
    sshagent([credentialsId: 'credential-id', usernameVariable: 'SSH_USER']) {
       sh 'ssh -vvv -o StrictHostKeyChecking=no -l $SSH_USER example.org uname -a'
    }
}

      the syntax is very similar to withCredentials and there is also a open pull request to the binding plugin, so I'm so sure if it's the right place to ask for:

      see https://github.com/jenkinsci/credentials-binding-plugin/pull/18

       

       

          [JENKINS-45312] expose the user of the credentialId used by sshagent

          Jesse Glick added a comment -

          JENKINS-28399 would be the workaround.

          Jesse Glick added a comment - JENKINS-28399  would be the workaround.

          Daniel Geißler added a comment -

          jglick I've seen you merging the respective pull request of JENKINS-28399, but i wonder how it would look like if one wants to use a passphrase protected key with that binding.

          Is there a example I've missed?

          Daniel Geißler added a comment - jglick I've seen you merging the respective pull request of JENKINS-28399 , but i wonder how it would look like if one wants to use a passphrase protected key with that binding. Is there a example I've missed?

          Jesse Glick added a comment -

          I do not believe you actually do need to pass the -l option in this case, but at any rate if you do, you would need to use withCredentials with the new binding type and pass -i to point to the (temporary) location of the private key. I will leave the details as an exercise to the reader.

          Jesse Glick added a comment - I do not believe you actually do need to pass the -l option in this case, but at any rate if you do, you would need to use withCredentials with the new binding type and pass -i to point to the (temporary) location of the private key. I will leave the details as an exercise to the reader.

            Unassigned Unassigned
            dageissl Daniel Geißler
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: