How does jenkins publish over ssh store passphrases?

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?

Answer

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 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? 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 That sounds it might be an answer - does jenkins have a built-in key that it uses if one is not provided? I think you're mixing machine passwords and key passphrases @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. 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