Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-08-29T13:27:48.997Z
Answers: 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.
Answers: Uberhumus
Answers: CC BY-SA 4.0
Answers: 2019-09-02T19:05:08.307Z
Answers: https://wiki.jenkins.io/display/JENKINS/SSH+Credentials+Plugin
  Use that in conjunction with https://jenkins.io/doc/book/using/using-credentials/
Answers: tnsh
Answers: CC BY-SA 4.0
Answers: 2019-09-03T21:04:13.703Z
Answers: @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.
Answers: Preston Martin
Answers: CC BY-SA 4.0
Answers: 2019-09-05T05:11:31.410Z
Answers: @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?
Answers: tnsh
Answers: CC BY-SA 4.0
Answers: 2019-09-07T23:15:46.337Z
Answers: The question states that the SSH keys for Node B would be stored on Node A. The nodes have SSH access.
Answers: Preston Martin
Answers: CC BY-SA 4.0
Answers: 2019-08-29T13:18:57.580Z
Answers: 2019-09-05T03:39:16.823Z
Answers: 2019-09-05T03:39:16.823Z
Answers: tnsh
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-08-29T10:14:01.587Z
Answers: 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.
Answers: Uberhumus
Answers: CC BY-SA 4.0
Answers: 2019-08-29T20:07:54.923Z
Answers: I've added the link to the relevant documentation for Jenkins declarative pipelines in the answer.
Answers: Preston Martin
Answers: CC BY-SA 4.0
Answers: 2023-03-20T14:43:31.933Z
Answers: Would be nice to mention in your answer that you used information that I contributed in my answer. :)   @PrestonMartin
Answers: tnsh
Answers: CC BY-SA 4.0
Answers: 2019-08-28T17:17:10.317Z
Answers: 2019-08-29T20:07:43.470Z
Answers: 2019-08-29T20:07:43.470Z
Answers: Preston Martin
Body: <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>
  
Tags: <jenkins><jenkins-plugins><key-management><ssh>
Title: How to SSH from Jenkins node to Jenkins node safely?
UserDisplayName: Uberhumus
ThreadText: # 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. :)   @username_2  
  
  ---
  
  ### 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.  
  
  ---
  
  