<p>I would suggest using the Jenkins Credentials Plugin.</p>

<p>Another method which is more useful in case the Jenkins nodes are not able to connect via SSH is by pushing it to some remote bucket from NodeA and using triggers or a webhook to pull it to NodeB. This might however require access to the internet.</p>

<p>To apply this use <a href="https://wiki.jenkins.io/display/JENKINS/SSH+Credentials+Plugin" rel="nofollow noreferrer">https://wiki.jenkins.io/display/JENKINS/SSH+Credentials+Plugin</a> in conjunction with <a href="https://jenkins.io/doc/book/using/using-credentials" rel="nofollow noreferrer">https://jenkins.io/doc/book/using/using-credentials</a>.</p>

CC BY-SA 4.0
2019-08-29T13:27:48.997Z
Do you have a link to an example or more in depth documentation of the Jenkins Credentials Plugin? I couldn't find it and I've looked before asking this question.
Uberhumus
CC BY-SA 4.0
2019-09-02T19:05:08.307Z
https://wiki.jenkins.io/display/JENKINS/SSH+Credentials+Plugin
Use that in conjunction with https://jenkins.io/doc/book/using/using-credentials/
tnsh
CC BY-SA 4.0
2019-09-03T21:04:13.703Z
@TanishIslam If you are suggesting that NodeA push relevant files that NobeB requires to a bucket, then yes, using some remote file storage is an option. If you are suggesting that the keys for NodeA be pushed to a bucket and pulled by NodeB, I don't think that is a good suggestion. 
1. Exposing your keys in an object store is just as bad if not worse than storing them on an instance.
2. The use case for what you would be using the object store for is exactly the scenario that a secret store is built for, except a secret store manages the secrets for you much more efficiently.
Preston Martin
CC BY-SA 4.0
2019-09-05T05:11:31.410Z
@PrestonM pushing files was implied, and certainly not keys, because as clearly stated, if the nodes don't have SSH access, what keys could you possibly upload?
tnsh
CC BY-SA 4.0
2019-09-07T23:15:46.337Z
The question states that the SSH keys for Node B would be stored on Node A. The nodes have SSH access.
Preston Martin
CC BY-SA 4.0
2019-08-29T13:18:57.580Z
2019-09-05T03:39:16.823Z
2019-09-05T03:39:16.823Z
tnsh
<p>Yes, storing your ssh keys directly on a build node is a bad practice. Nodes can be replicated, deleted, or given access to from other systems, and you don't want to lose track of what systems have access to your secrets.</p>

<p>You should also not pass them directly into the build job, either as a parameter or as an environment variable. This can cause a huge headache with logging and tracking to make sure your keys aren't inadvertently output to places they shouldn't be. Instead, you should:</p>

<ol>
<li>Use a centralized secret store (such as <a href="https://wiki.jenkins.io/pages/viewpage.action?pageId=111837892" rel="nofollow noreferrer">Hashicorp Vault</a>) to retrieve the secrets at build run-time. </li>
<li>Use a plugin (such as the Credentials or <a href="https://wiki.jenkins.io/display/JENKINS/SSH+Credentials+Plugin" rel="nofollow noreferrer">SSH Credentials</a> Plugin) to <a href="https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials" rel="nofollow noreferrer">reference</a> the keys during the build. </li>
</ol>

CC BY-SA 4.0
2019-08-29T10:14:01.587Z
Do you have a link to an example or more in depth documentation of option 2? I couldn't find it and I've looked before asking this question.
Uberhumus
CC BY-SA 4.0
2019-08-29T20:07:54.923Z
I've added the link to the relevant documentation for Jenkins declarative pipelines in the answer.
Preston Martin
CC BY-SA 4.0
2023-03-20T14:43:31.933Z
Would be nice to mention in your answer that you used information that I contributed in my answer. :)   @PrestonMartin
tnsh
CC BY-SA 4.0
2019-08-28T17:17:10.317Z
2019-08-29T20:07:43.470Z
2019-08-29T20:07:43.470Z
Preston Martin
<p>We have a Jenkins Job that builds something on node A and then needs to SCP it to node B. 
You can just put the SSH keys for node B on Node A, and SCP with an <code>execute shell</code> build step, however I suspect that keeping SSH keys on a Jenkins node is a bad practice, and would like to avoid it.
What is the best practice regarding this use case? Is there a plugin or a feature for this? Should we just install Hashicorp Vault on the node and configure the keys there separately?</p>

<jenkins><jenkins-plugins><key-management><ssh>
How to SSH from Jenkins node to Jenkins node safely?
Uberhumus
# How to SSH from Jenkins node to Jenkins node safely?

(Asked by: username_0 on 2019-08-28)

We have a Jenkins Job that builds something on node A and then needs to SCP it to node B.
You can just put the SSH keys for node B on Node A, and SCP with an `execute shell` build step, however I suspect that keeping SSH keys on a Jenkins node is a bad practice, and would like to avoid it.
What is the best practice regarding this use case? Is there a plugin or a feature for this? Should we just install Hashicorp Vault on the node and configure the keys there separately?

**Tags:** jenkins, jenkins-plugins, key-management, ssh


---

## 2 answers

### Answer by username_2 on 2019-08-28. Score: 5 | Accepted answer

Yes, storing your ssh keys directly on a build node is a bad practice. Nodes can be replicated, deleted, or given access to from other systems, and you don't want to lose track of what systems have access to your secrets.

You should also not pass them directly into the build job, either as a parameter or as an environment variable. This can cause a huge headache with logging and tracking to make sure your keys aren't inadvertently output to places they shouldn't be. Instead, you should:

1. Use a centralized secret store (such as [Hashicorp Vault](https://wiki.jenkins.io/pages/viewpage.action?pageId=111837892)) to retrieve the secrets at build run-time.
2. Use a plugin (such as the Credentials or [SSH Credentials](https://wiki.jenkins.io/display/JENKINS/SSH+Credentials+Plugin) Plugin) to [reference](https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials) the keys during the build.

> **Comments:**
> **username_0**: Do you have a link to an example or more in depth documentation of option 2? I couldn't find it and I've looked before asking this question.  
> **username_2**: I've added the link to the relevant documentation for Jenkins declarative pipelines in the answer.  
> **username_1**: Would be nice to mention in your answer that you used information that I contributed in my answer. :)   @PrestonMartin  

---

### Answer by username_1 on 2019-08-29. Score: 0

I would suggest using the Jenkins Credentials Plugin.

Another method which is more useful in case the Jenkins nodes are not able to connect via SSH is by pushing it to some remote bucket from NodeA and using triggers or a webhook to pull it to NodeB. This might however require access to the internet.

To apply this use <https://wiki.jenkins.io/display/JENKINS/SSH+Credentials+Plugin> in conjunction with <https://jenkins.io/doc/book/using/using-credentials>.

> **Comments:**
> **username_0**: Do you have a link to an example or more in depth documentation of the Jenkins Credentials Plugin? I couldn't find it and I've looked before asking this question.  
> **username_1**: https://wiki.jenkins.io/display/JENKINS/SSH+Credentials+Plugin Use that in conjunction with https://jenkins.io/doc/book/using/using-credentials/  
> **username_2**: @TanishIslam If you are suggesting that NodeA push relevant files that NobeB requires to a bucket, then yes, using some remote file storage is an option. If you are suggesting that the keys for NodeA be pushed to a bucket and pulled by NodeB, I don't think that is a good suggestion.  1. Exposing your keys in an object store is just as bad if not worse than storing them on an instance. 2. The use case for what you would be using the object store for is exactly the scenario that a secret store is built for, except a secret store manages the secrets for you much more efficiently.  
> **username_1**: @PrestonM pushing files was implied, and certainly not keys, because as clearly stated, if the nodes don't have SSH access, what keys could you possibly upload?  
> **username_2**: The question states that the SSH keys for Node B would be stored on Node A. The nodes have SSH access.  

---

