How can I authenticate SSH connections on slaves without copying the SSH key to the slave?
- CloudBees Jenkins Enterprise
DEV@cloud's default configuration is designed for the convenience and simplicity of small / new users where a single shared credential is shared by all jobs. Typically this configuration is suitable where the Jenkins is used by a small team of trusted users.
DEV@cloud exposes a single shared
id_dsa SSH private-key as a file to all jobs.
This SSH private-key is transferred directly to remote slaves for use in jobs.
Security / Compartmentalisation
For customers who require a higher level of compartmentalisation and control, the job administrator can configure SSH keys at a folder level using the Credentials plugin.
This will help mitigate risks of the SSH private-key being compromised intentionally or unintentionally by a job administrator.
Using the Credentials plugin allows the user to
- configure an SSH key in a folder - and allow access to all jobs contained within that folder or below
- configure the job to pass the SSH private-key using an SSH agent
This allows the user to securely provide access to remote resources (using SSH authentication) without exposing the SSH private-key material to the job.
Note: while the SSH private-key content is not directly exposed to the job, this key (via the agent) can be used to authenticate to any remote resource while the agent connection is open (i.e. the job is running)
Separate your environments into folders
You can create a folder “deploy-app”, and then sub-folders for
production folder will have production credentials, and the
staging folder will have staging credentials.
Passphrase protect your SSH keys
Due to how the Credentials plugin works, your SSH private key can be copied back out of the credential configuration - while the passphrase can not. This provides an extra layer of protection.
It is possible for a suitably motivated Jenkins administrator to recover the passphrase.
Generate a 4096 bit key
ssh-keygen -t rsa -b 4096 -f test-key
Generating an SSH key
The detailed steps for generating an SSH key are out of scope for this article.
Note: To ssh successfully, SSH Agents needs the public key (matching with the SSH private keys which injects) included into the
~/.ssh/authorized_keys in the remote server to connect.
Configuring an SSH Agent
1. Select Folder
Navigate to the top level folder that requires SSH keys.
3. Select “Credentials”
On the bottom left navigation, select the “Credentials” link.
4. Select “Folder”
On the bottom left navigation, select the “Folder” link.
5. Select “Global credentials”
On the main display, select the “Global Credentials” link.
6. Select “Add credentials”
On the left navigation, select the “Add Credentials” link.
7. Select “SSH Username with private key”
From the dropdown, select “SSH Username with private key”
Fill in all the required settings. Use globally unique names for simplicity in configuring jobs.
Consider a naming scheme like
<env>-<purpose>-id_rsa - which expands to
8. Navigate back to folder
Select the main folder from the breadcrumb bar at the top of the page.
9. Create a new job
Add a new “item”
10. Add freestyle job
Note that you will need to configure each job separately - the SSH agent is not automatically added to each of the contained jobs.
11. Add shell step
12. Confirm that the SSH private-key was used