ameblo.over-update.download

• Jenkins Docker Plugin
• Jenkins Git Ssh Key

Jun 11, 2014  In the docker file it defines the user jenkins:jenkins. However trying to connect from Jenkins to your everga container image using username and password won't work: I needed to create an ssh key pair and modify the /etc/ssh/sshconfig file to point to the private key and /etc/ssh/sshdconfig to point to the authorizedkey file. Su jenkins This gives me access to the shell where I may run ssh-keygen to install ssh keys into jenkins user home directory under /.ssh. After this I exit and the Dockerfile continues. This home directory is /var/lib/jenkins which is also mounted as a volume on the host server. Problem is that the ssh keys appear here but they are not working. Jul 14, 2015  I don't understand how works ssh keys for jenkins. I would like to be able to mount a volume containing jenkins ssh files (idrsa, idrsa.pub, config and knownhosts) so I don't have to configure them manually in the UI. Or configure sev.

With many of the tools commonly used in a Continuous Delivery pipeline, Windows is not the original OS the tool was developed for. Although support and adoption are growing all the time, there can still be some pain points and gotchas in configuring some of them to work as you would expect on a Windows OS.

Feb 12, 2018 Manage Jenkins – configure credentials – credentials – system –Add credentials. Change the credentials “kind” to “SSH Username with private key” in follow with username that is being used in the bitbucket account,private key and passphrase that used to unlock the private key. Now add the public key to bit bucket, Bitbucket – settings – security–ssh keys –add keys.

In this post, we’re going to combine two of the big hitters in this space, Jenkins and Git. Jenkins is the most widely adopted solution for automating build and CI/CD pipelines and Git is the dominant force in source control management. We’re going to get Jenkins talking to a remote Git repository, specifically a private GitHub repository, using SSH authentication.

Git was developed specifically for managing the development of the Linux kernel (by Linus Torvolds himself no less) and was brought to Windows as an afterthought. Git comes bundled with OpenSSH, which does not yet have a production-ready implementation on Windows, although Microsoft is working on one that is currently pre-release [Win32-OpenSSH]. For this reason, Git for Windows is bundled with MINGW, a minimal GNU development environment that runs on Windows.

With that background out of the way, let’s get started.

Requirements

A note on installing Git for Windows

The first “gotcha” is how you install Git on the Jenkins worker in the first place. The Git plugin for Jenkins is not yet compatible with the Git Credential Manager for Windows. Ensure that you uncheck the box for this option at installation time.

If you see Jenkins hanging and timing out after ten minutes when executing a git fetch, this is a sign that you have the Git Credential Manager installed. The job is hanging because the Git Credential Manager has intercepted the command and is ignoring any other preconfigured authentication mechanism.

The only way around this at the moment is to choose not to install it.

Telling Jenkins where to find Git

After installation, our first job is to configure the Tool Location for Git. First, let’s figure out what the location is. Open PowerShell and input:

This will output something similar to:

Copy the path to git.exe.

In Jenkins, click Manage Jenkins then Configure System. In Global properties check Tool Locations, select (Git) Default and enter the path to git.exe in the Home textbox.

Save and exit the page.

Generating SSH keys for the Jenkins service

On Windows, the Jenkins services run as the Local System user by default, not your own user identity. It’s important to understand that Jenkins will be executing the Git commands and authenticating in the context of that user identity. This is important because OpenSSH will look for the SSH keys in the home directory of the user and the Local System account does not use the same home directory that your own personal account has.

Finding the Local System home directory

You probably don’t know what your Local System account considers its home directory. To find out, you need to start a command prompt as the Local System user and resolve %UserProfile%, but that’s easier said than done.

One way to run a process as the Local System account is to use PsExec, a Sysinternals tool that is normally used to execute programs on remote hosts. Using the -s parameter starts the process as Local System, so execute the following from PowerShell:

This will open a command prompt as Local System. Then resolve %UserProfile%:

This will output a path similar to:

So for me, C:WINDOWSsystem32configsystemprofile is the home directory of my Local Service account.

Jenkins Docker Plugin

Generating keys with OpenSSH

One approach to enabling your Local Service account to work over SSH with a remote repo is to copy the .ssh directory from your personal home directory (containing previously generated and configured keys) over to the Local Service home directory, so that it effectively uses the same identity as your personal account over SSH. But I prefer to keep Local Service as a separate identity with its own keys, so generating new SSH keys is what we will be doing next.

From the Local Service command prompt you started with PsExec earlier, execute:

This will start Bash in a MINGW window, the minimal GNU environment for Windows that I mentioned earlier, as the Local System user.

Execute the following to generate a new public and private RSA key with OpenSSH:

The proposed location of the keys will default to the home directory of the Local Service account that you discovered earlier, keep this default. When OpenSSH asks for a passphrase, just press Enter (and again on confirmation) to opt for no passphrase.

It is, of course, better to use SSH keys that are encrypted with a passphrase, but I have found that the Git plugin for Jenkins does not work very well with SSH keys that require a passphrase, even though its Credentials UI does allow you to enter one.

That whole workflow should look similar to the below:

You should see that there is now a .ssh directory in the Local Service home directory containing a public and private key pair. id_rsa.pub is the public key and is_rsa is the private key. The local Jenkins server will use the private key and the remote Git server will use the public key.

Adding the public key in GitHub

This next part is quite simple, we’re going to register the public key with our remote Git server. I’m going to use my personal GitHub, but it should be simple to replace these steps with the equivalents for the likes of BitBucket, etc.

1. In your web browser, log in to GitHub.
2. From your GitHub profile, click Settings, then SSH and GPG keys, then New SSH key.
3. Give the key a name. I like SYSTEM@COMPUTER (substitute the name of your machine) because the name will remind me that it’s associated with the Local System account of my machine.
4. On your local machine, open id_rsa.pub in a text editor, e.g. Notepad++. The contents will begin with: ssh–rsa.
5. Press CTRL+A to select the entire file contents, then CTRL+C to copy it to your clipboard.
6. Paste (CTRL+V) into the Key area in the web UI.
7. Click Add SSH key.

And we’re done. Let’s test that we can now authenticate successfully with the corresponding private key.

Testing the SSH keys

Back in the MINGW shell (still running as our Local Service account) enter the following to connect to GitHub with SSH:

You will probably find that github.com is not yet a known host and you will get a prompt similar to below.

Just enter yes to accept the connection. On successfully connecting you will see:

We can see that the keys are correctly associated with our GitHub account.

Testing with a Jenkins project

Now all that remains is to test everything with a Jenkins project. For this I have a private GitHub repository containing the following Jenkinsfile:

This pipeline script just outputs “Hello, World!” to the console output, so nothing too interesting. Now we just need a Jenkins job to execute it:

The “Pipeline script from SCM” option means that the job definition lives in the SCM system itself and must be fetched to run. Our job won’t work at all if Jenkins isn’t successful in authenticating with GitHub using our SSH keys.

Make sure that the Repository URL is in a form that will use SSH to authenticate. A HTTPS URI, e.g. https://github.com/user/repo.git, will be expecting a username and password. See Git – The Protocols for more information.

Because OpenSSH will default to looking in %UserProfile%.ssh for keys, we don’t actually need to tell Jenkins what the private key is. So I’ve associated no credentials with this test job. Of course, you could choose to if you had a need.

If we run this, we should see:

We can see “Hello, World!” so we successfully fetched the job definition from the private Git repository.

The following plugin provides functionality available throughPipeline-compatible steps. Read more about how to integrate steps into yourPipeline in theStepssection of thePipeline Syntaxpage.

For a list of other such plugins, see thePipeline Steps Referencepage.

• Docker plugin

Docker plugin

Jenkins Git Ssh Key

dockerNode: Docker Node (⚠️ Experimental)

Allocates a new Jenkins agent using a specified Docker image and runs tasks on it. Example:

• image
  • Type:String
• connector (optional)
  Nested Choice of Objects
  • attach
    • user (optional)
      User under that jenkins slave will be run. 'root' if not specified.
      • Type:String
  • jnlp
    • jnlpLauncher
      Nested Object
      • tunnel
        • Type:String
      • vmargs
        If the agent JVM should be launched with additional VM arguments, such as '-Xmx256m', specify those here. List of all the options are available here.
        • Type:String
    • entryPointArgumentsString (optional)
      • Type:String
    • jenkinsUrl (optional)
      If needed, the Jenkins URL can be overwritten with this property (e.g. to support other HTTP(S) endpoints due to reverse proxies or firewalling). By default the URL from the global Jenkins configuration is used.
      • Type:String
    • user (optional)
      User under that jenkins slave will be run. 'root' if not specified.
      • Type:String
  • ssh
    • sshKeyStrategy
      Define how a SSH key pair is configured for ssh authentication in container.
      Nested Choice of Objects
      • $class: 'InjectSSHKey'
        • user
          Injected SSH key will let agent start as root in container. If you want to use another user configure it's name here. Please note such a user must pre-exist in container image.
          • Type:String
      • $class: 'ManuallyConfiguredSSHKey'
        • credentialsId
          • Type:String
        • sshHostKeyVerificationStrategy
          Nested Choice of Objects
          • $class: 'KnownHostsFileKeyVerificationStrategy'

            Checks the known_hosts file (~/.ssh/known_hosts) for the user Jenkins is executing under, to see if an entry exists that matches the current connection.

            This method does not make any updates to the Known Hosts file, instead using the file as a read-only source and expecting someone with suitable access to the appropriate user account on the Jenkins master to update the file as required, potentially using the ssh hostname command to initiate a connection and update the file appropriately.

          • $class: 'ManuallyProvidedKeyVerificationStrategy'

            Checks the key provided by the remote host matches the key set by the user who configured this connection.

            • key

              The SSH key expected for this connection. This key should be in the form `algorithm value` where algorithm is one of ssh-rsa or ssh-dss, and value is the Base 64 encoded content of the key.

              • Type:String
          • $class: 'ManuallyTrustedKeyVerificationStrategy'

            Checks the remote key matches the key currently marked as trusted for this host.

            Depending on configuration, the key will be automatically trusted for the first connection, or an authorised user will be asked to approve the key. An authorised user will be required to approve any new key that gets presented by the remote host.

            • requireInitialManualTrust

              Require a user with Computer.CONFIGURE permission to authorise the key presented during the first connection to this host before the connection will be allowed to be established.

              If this option is not enabled then the key presented on first connection for this host will be automatically trusted and allowed for all subsequent connections without any manual intervention.

              • Type:boolean
          • $class: 'NonVerifyingKeyVerificationStrategy'

            Does not perform any verification of the SSH key presented by the remote host, allowing all connections regardless of the key they present.

    • javaPath (optional)
      • Type:String
    • jvmOptions (optional)
      • Type:String
    • launchTimeoutSeconds (optional)
      • Type:int
    • maxNumRetries (optional)
      The number of times that attempts to connect to the newly-spun Docker container will be retried before the operation is abandoned.

      Note: That this field applies first to checks that the SSH port is open for new TCP connections, and secondly to checks that the SSH service that owns the TCP port is accepting SSH connections.
      Thomson default key generator 2013 download. e.g. a value of 3 would mean that (up to) 4 attempts (1 initial attempt plus 3 retries) would be made to check the availability of the TCP port, followed by (up to) 4 attempts (1 initial attempt plus 3 retries) to check the availability of the SSH service itself.

      • Type:int
    • port (optional)
      • Type:int
    • prefixStartSlaveCmd (optional)
      • Type:String
    • retryWaitTime (optional)
      Number of seconds to wait between attempts to connect to the newly-started Docker container.
      • Type:int
    • suffixStartSlaveCmd (optional)
      • Type:String
• credentialsId (optional)
  • Type:String
• dockerHost (optional)
  • Type:String
• remoteFs (optional)
  Use a specific root directory for the Jenkins agent. This includes a workspace subdirectory as well as various control files. If not specified, uses the WORKDIR from the image.
  • Type:String

step([$class: 'DockerBuilderControl']): Start/Stop Docker Containers

• option
  Nested Choice of Objects
  • $class: 'DockerBuilderControlOptionProvisionAndStart'
  • $class: 'DockerBuilderControlOptionRun'
    • cloudName
      • Type:String
    • image
      • Type:String
    • pullCredentialsId
      • Type:String
    • dnsString
      • Type:String
    • network
      • Type:String
    • dockerCommand
      • Type:String
    • volumesString
      • Type:String
    • volumesFrom
      • Type:String
    • environmentsString
      • Type:String
    • hostname
      • Type:String
    • user
      • Type:String
    • extraGroupsString
      • Type:String
    • memoryLimit
      • Type:int
    • memorySwap
      • Type:int
    • cpuShares
      • Type:int
    • shmSize
      • Type:int
    • bindPorts
      • Type:String
    • bindAllPorts
      • Type:boolean
    • privileged
      • Type:boolean
    • tty
      • Type:boolean
    • macAddress
      • Type:String
  • $class: 'DockerBuilderControlOptionStart'
  • $class: 'DockerBuilderControlOptionStop'
    • cloudName
      • Type:String
    • containerId
      • Type:String
    • remove
      • Type:boolean
  • $class: 'DockerBuilderControlOptionStopAll'

step([$class: 'DockerBuilderPublisher']): Build / Publish Docker Image

• dockerFileDirectory
  • Type:String
• fromRegistry
  Nested Object
  • url
    URL to the Docker registry you are using. May be left blank to use the public DockerHub registry (currently https://index.docker.io/v1/).
    • Type:String
  • credentialsId
    • Type:String
• cloud
  Cloud to do the build on - or, if empty, use the cloud that the build was performed on.
  • Type:String
• tagsString
  Repository name (and optionally a tag) to be applied to the resulting image in case of success.
  Multiple entries are permitted if separated by newlines.
  Environment variable substitution is performed on the strings so you can use e.g. ${BUILD_NUMBER} as part of each entry.
  Each entry must be of the form IMAGE[:TAG] as per the docker tag command.
  • Type:String
• pushOnSuccess
  If enabled (and the docker image builds successfully), the resulting docker image will be pushed to the registry (or registries) specified within the 'Image' field.
  • Type:boolean
• pushCredentialsId
  • Type:String
• cleanImages
  • Type:boolean
• cleanupWithJenkinsJobDelete
  • Type:boolean
• noCache (optional)
  If set, builds the image with --no-cache which disables caching of layers. See the docker build command for more information.
  • Type:boolean
• pull (optional)
  If set, builds the image with --pull to pull the latest version of the base image, instead of using the local one. See the docker build command for more information.
  • Type:boolean

Please submit your feedback about this page through thisquick form.

Alternatively, if you don't wish to complete the quick form, you can simplyindicate if you found this page helpful?

See existing feedback here.