Answers: <p>According to the <a href="https://github.com/jenkinsci/publish-over-ssh-plugin/blob/master/src/main/java/jenkins/plugins/publish_over_ssh/BapSshKeyInfo.java#L47-L58h" rel="nofollow noreferrer">source code for the Publish Over SSH plugin</a>, the passphrase is encrypted and decrypted using <a href="http://javadoc.jenkins-ci.org/hudson/util/Secret.html" rel="nofollow noreferrer"><code>hudson.util.Secret</code></a>, and the encrypted value is stored in the plugin's XML configuration file.</p>
  
  <p>Supposedly there is <a href="https://github.com/jenkinsci/publish-over-plugin/pull/4" rel="nofollow noreferrer">ongoing work to switch to using Jenkins' built-in credentials store</a>; however, I don't see any active pull requests for such a change.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-15T16:10:54.617Z
Answers: 2018-06-15T16:10:54.617Z
Answers: jayhendren
Body: <p>When I look in jenkins.plugins.publish_over_ssh.BapSshPublisherPlugin.xml I can see several entries, that have secretPassphrase populated with a string 44 characters long. By using hudson.util.Secret.fromString in the /script tool, I can decrypt them and see that password. Fine so far.</p>
  
  <p>However... I also have an entry there where the secretPassphrase is populated with a string only 24 characters long, which cannot be decrypted. Trying gets me an empty result, which is strange, because decrypting "asdfasdf" returns "asdfasdf". So there must be something special about this string which is preventing the decryption for working, or from returning the default. But deployments to this server work; so the passphrase is correct. But the secretPassphrase is NOT the actual password on the server.</p>
  
  <p>Which means jenkins must be using some other method of decrypting that passphrase, besides the standared hudson.util one. What is it? How can I recover this password?</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-06-15T12:02:40.463Z
Comments: How do you think we can guess how your server is configured and what is the passphrase of the private key and if there's even one on this key ?
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-15T13:21:57.440Z
Comments: @Tensibai The question is how does JENKINS know what it is? I'm not familiar with the internal coding of jenkins, but it seems obvious that if it's not using hudson.util.Secret to decrypt the passphrase, it must be using something else - so what else does jenkins use?
Comments: Benubird
Comments: CC BY-SA 4.0
Comments: 2018-06-15T13:41:21.933Z
Comments: Or just that the private key used for this case has no passphrase, and as such it decrypts a null value which is okay to use the private key....
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-15T14:07:17.223Z
Comments: @Tensibai That sounds it might be an answer - does jenkins have a built-in key that it uses if one is not provided?
Comments: Benubird
Comments: CC BY-SA 4.0
Comments: 2018-06-15T14:09:41.250Z
Comments: I think you're mixing machine passwords and key passphrases
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-15T15:34:37.517Z
Comments: @Tensibai It is a little bit confusing that jenkins config file uses the term secretPassphrase for both cases, but I am not uses keys anywhere - it's all typed-in passwords.
Comments: Benubird
Comments: CC BY-SA 4.0
Comments: 2018-06-15T19:48:13.873Z
Comments: Then you may wish to [edit] your question to avoid this kind of ambiguity for all readers. Abusing Jenkins to make it do system orchestration duties is so easy that it often bites in ways sysadmins can not help with because things are named out of their real meanings and no one can help because we all work on our own assumptions
Comments: Tensibai
Tags: <jenkins><jenkins-plugins><passwords>
Title: How does jenkins publish over ssh store passphrases?
UserDisplayName: Benubird
ThreadText: # How does jenkins publish over ssh store passphrases?
  
  (Asked by: username_0 on 2018-06-15)
  
  When I look in jenkins.plugins.publish\_over\_ssh.BapSshPublisherPlugin.xml I can see several entries, that have secretPassphrase populated with a string 44 characters long. By using hudson.util.Secret.fromString in the /script tool, I can decrypt them and see that password. Fine so far.
  
  However... I also have an entry there where the secretPassphrase is populated with a string only 24 characters long, which cannot be decrypted. Trying gets me an empty result, which is strange, because decrypting "asdfasdf" returns "asdfasdf". So there must be something special about this string which is preventing the decryption for working, or from returning the default. But deployments to this server work; so the passphrase is correct. But the secretPassphrase is NOT the actual password on the server.
  
  Which means jenkins must be using some other method of decrypting that passphrase, besides the standared hudson.util one. What is it? How can I recover this password?
  
  **Tags:** jenkins, jenkins-plugins, passwords
  
  > **Comments:**
  > **username_1**: How do you think we can guess how your server is configured and what is the passphrase of the private key and if there's even one on this key ?  
  > **username_0**: @username_1 The question is how does JENKINS know what it is? I'm not familiar with the internal coding of jenkins, but it seems obvious that if it's not using hudson.util.Secret to decrypt the passphrase, it must be using something else - so what else does jenkins use?  
  > **username_1**: Or just that the private key used for this case has no passphrase, and as such it decrypts a null value which is okay to use the private key....  
  > **username_0**: @username_1 That sounds it might be an answer - does jenkins have a built-in key that it uses if one is not provided?  
  > **username_1**: I think you're mixing machine passwords and key passphrases  
  > **username_0**: @username_1 It is a little bit confusing that jenkins config file uses the term secretPassphrase for both cases, but I am not uses keys anywhere - it's all typed-in passwords.  
  > **username_1**: Then you may wish to [edit] your question to avoid this kind of ambiguity for all readers. Abusing Jenkins to make it do system orchestration duties is so easy that it often bites in ways sysadmins can not help with because things are named out of their real meanings and no one can help because we all work on our own assumptions  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-06-15. Score: 1
  
  According to the [source code for the Publish Over SSH plugin](https://github.com/jenkinsci/publish-over-ssh-plugin/blob/master/src/main/java/jenkins/plugins/publish_over_ssh/BapSshKeyInfo.java#L47-L58h), the passphrase is encrypted and decrypted using [`hudson.util.Secret`](http://javadoc.jenkins-ci.org/hudson/util/Secret.html), and the encrypted value is stored in the plugin's XML configuration file.
  
  Supposedly there is [ongoing work to switch to using Jenkins' built-in credentials store](https://github.com/jenkinsci/publish-over-plugin/pull/4); however, I don't see any active pull requests for such a change.
  
  
  ---
  
  