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?

  • 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 ?
    – Tensibai
    Commented Jun 15, 2018 at 12:02
  • @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?
    – Benubird
    Commented Jun 15, 2018 at 13:21
  • 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....
    – Tensibai
    Commented Jun 15, 2018 at 13:41
  • @Tensibai That sounds it might be an answer - does jenkins have a built-in key that it uses if one is not provided?
    – Benubird
    Commented Jun 15, 2018 at 14:07
  • I think you're mixing machine passwords and key passphrases
    – Tensibai
    Commented Jun 15, 2018 at 14:09

1 Answer 1


According to the source code for the Publish Over SSH plugin, the passphrase is encrypted and decrypted using hudson.util.Secret, 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; however, I don't see any active pull requests for such a change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.