[JIRA] [credentials] (JENKINS-18897) ssh-agent & slave: 'JCE cannot authenticate the provider BC', because 'Class is on the bootclasspath'

157 views
Skip to first unread message

Daniel_Jackson@intuit.com (JIRA)

unread,
Jul 23, 2013, 6:24:47 PM7/23/13
to jenkinsc...@googlegroups.com
Issue Type: Bug Bug
Assignee: stephenconnolly
Components: credentials
Created: 23/Jul/13 10:24 PM
Description:

I'm having trouble using the SSH Agent plugin on our Jenkins installation. The job is trying to run on a slave agent, and I'm currently receiving this error:

[ssh-agent] Using credentials My Private key
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent]   Java/JNR ssh-agent
[ssh-agent] Unable to read key: exception using cipher - please check password and data.
org.bouncycastle.openssl.EncryptionException: exception using cipher - please check password and data.
	at org.bouncycastle.openssl.PEMUtilities.crypt(Unknown Source)
	at org.bouncycastle.openssl.PEMUtilities.crypt(Unknown Source)
	at org.bouncycastle.openssl.PEMReader$KeyPairParser.readKeyPair(Unknown Source)
	at org.bouncycastle.openssl.PEMReader$RSAKeyPairParser.parseObject(Unknown Source)
	at org.bouncycastle.openssl.PEMReader.readObject(Unknown Source)
	at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgent.addIdentity(JNRRemoteAgent.java:92)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:275)
	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:256)
	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:326)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
	at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.SecurityException: JCE cannot authenticate the provider BC
	at javax.crypto.Cipher.getInstance(DashoA13*..)
	... 22 more
Caused by: java.util.jar.JarException: Class is on the bootclasspath
	at javax.crypto.SunJCE_c.a(DashoA13*..)
	at javax.crypto.SunJCE_b.b(DashoA13*..)
	at javax.crypto.SunJCE_b.a(DashoA13*..)
	at javax.crypto.SunJCE_b.a(DashoA13*..)
	at javax.crypto.KeyAgreement.getInstance(DashoA13*..)
	at org.apache.sshd.common.util.SecurityUtils$BouncyCastleRegistration.run(SecurityUtils.java:97)
	at org.apache.sshd.common.util.SecurityUtils.register(SecurityUtils.java:77)
	at org.apache.sshd.common.util.SecurityUtils.isBouncyCastleRegistered(SecurityUtils.java:68)
	at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgent.addIdentity(JNRRemoteAgent.java:78)
	... 16 more
[ssh-agent] Started.

When I google, it appears this error is caused when BouncyCastle is bundled inside an unsigned JAR (or similar), because Java requires JCE providers to be in a signed JAR. I don't actually know how BouncyCastle is being provided to the slave, I wasn't able to figure that out.

Is there something I can do to work around this? Or some change you can make that'll get rid of this error?

PS: I appreciate the SSH Agent Plugin v1.1 change, that solved my previous error.

Environment: Jenkins v1.517, SSH Agent Plugin v1.1, running on a Mac 10.8.4 slave using default Java 1.6
Project: Jenkins
Priority: Major Major
Reporter: Dan Jackson
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

carsuzan@fullsix.com (JIRA)

unread,
Mar 19, 2014, 1:05:16 PM3/19/14
to jenkinsc...@googlegroups.com

I also had the same behaviour.
The reason is simple :
The bouncycastle jar is not in the slave.jar classpath.

I think the solution may be to add the bouncycastle.jar in the slave.jar classpath MANIFEST.MF and always launch the slave.jar with the bouncycastle.jar in the same folder =>
When the slave is configured with :
"Launch slave agents on Unix machines via SSH" : The bouncycastle.jar would be copied at the same time as the slave.jar and in the same folder
"Launch slave via execution of command on the Master" : The bouncycastle.jar would be downloaded at http://yourserver:port/jnlpJars/bouncycastle.jar like the slave.jar and would have to be in the same folder

I have not look at other slave start methods.

While waiting for a good resolution, a simple fix is just to copy the bouncycastle jar into your jkd/jre/lib/ext folder.
ex : cp /tmp/jetty-0.0.0.0-8080-jenkins.war-any/webapp/WEB-INF/lib/bcprov-jdk15on-1.47.jar jkd/jre/lib/ext/

I think this is the reason why stephenconnolly did not have any problem (not sure).

wilm.schomburg@lht.dlh.de (JIRA)

unread,
May 23, 2014, 8:38:05 AM5/23/14
to jenkinsc...@googlegroups.com

Hi Thomas,

I've tried your (quick) resolution and copied the bouncycastle jar in the jkd/jre/lib/ext folder, but that doesn't solve the problem for me. Is there more to do?

Best regards,
Wilm

carsuzan@fullsix.com (JIRA)

unread,
May 23, 2014, 9:12:08 AM5/23/14
to jenkinsc...@googlegroups.com

Hi Wilm,

This is normally the only thing to do.
Try to restart your slave and be sure that this is the correct jdk that is used.
If it does not work, then you will have to debug and check the classpath.

Regards,

Thomas

wilm.schomburg@lht.dlh.de (JIRA)

unread,
May 23, 2014, 9:46:05 AM5/23/14
to jenkinsc...@googlegroups.com

Hi Thomas,

the "correct jdk" was the point. With "lsof" I saw the wrong jdk was used. I changed it and now everything is okay.

Thanks for your support.

Regards,
Wilm

courtlandj@gamesalad.com (JIRA)

unread,
Aug 21, 2014, 12:01:57 PM8/21/14
to jenkinsc...@googlegroups.com

This same error happened for me, but the JDK version did not appear to be the issue. I thought I would share, in case anyone else runs across what I did:
At least in some configurations, this error can be caused by using an SSH key that is too long. In my case, I used a 4096-bit RSA key, which ssh/git/GitHub normally have no problem with. Switching to using a 2048-bit RSA key alleviated this problem.

milki@rescomp.berkeley.edu (JIRA)

unread,
Oct 3, 2014, 8:43:19 PM10/3/14
to jenkinsc...@googlegroups.com
milki mlk commented on Bug JENKINS-18897

I have the same behaviour as courtland jones. Switching to a 2048-bit RSA key avoided the problem with SSH Agent v1.1

milki@rescomp.berkeley.edu (JIRA)

unread,
Oct 3, 2014, 8:51:18 PM10/3/14
to jenkinsc...@googlegroups.com
Change By: milki mlk (04/Oct/14 12:49 AM)
Resolution: Cannot Reproduce
Status: Resolved Reopened

milki@rescomp.berkeley.edu (JIRA)

unread,
Oct 3, 2014, 8:56:18 PM10/3/14
to jenkinsc...@googlegroups.com
 
milki mlk edited a comment on Bug JENKINS-18897

I have the same behaviour as courtland jones. A 4096-bit RSA key couldn't be decoded. Switching to a 2048-bit RSA key avoided the problem with SSH Agent v1.1. This only happens on the slave. Master has no issue with the long key.

milki@rescomp.berkeley.edu (JIRA)

unread,
Oct 3, 2014, 8:58:18 PM10/3/14
to jenkinsc...@googlegroups.com
 
milki mlk edited a comment on Bug JENKINS-18897

I have the same behaviour as courtland jones. A 4096-bit RSA key couldn't be decoded. Switching to a 2048-bit RSA key avoided the problem with SSH Agent v1.1. This only happens on the slave. Master has no issue with the long key.

http://www.novell.com/documentation/novellaccessmanager/adminguide/data/b4pq92r.html says 4096 bit keys aren't supported by the JCE policy.

milki@rescomp.berkeley.edu (JIRA)

unread,
Oct 3, 2014, 9:04:20 PM10/3/14
to jenkinsc...@googlegroups.com
 
milki mlk edited a comment on Bug JENKINS-18897

I have the same behaviour as courtland jones. A 4096-bit RSA key couldn't be decoded. Switching to a 2048-bit RSA key avoided the problem with SSH Agent v1.1. This only happens on the slave. Master has no issue with the long key.

http://www.novell.com/documentation/novellaccessmanager/adminguide/data/b4pq92r.html says 4096 bit keys aren't supported by the JCE policy.

http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html also mentions that the Unlimited Strength policy is required for >2048 bit keys.

milki@rescomp.berkeley.edu (JIRA)

unread,
Oct 3, 2014, 9:06:19 PM10/3/14
to jenkinsc...@googlegroups.com
 
milki mlk edited a comment on Bug JENKINS-18897

I have the same behaviour as courtland jones. A 4096-bit RSA key couldn't be decoded. Switching to a 2048-bit RSA key avoided the problem with SSH Agent v1.1. This only happens on the slave. Master has no issue with the long key.

http://www.bouncycastle.org/wiki/display/JA1/Frequently+Asked+Questions and http://www.novell.com/documentation/novellaccessmanager/adminguide/data/b4pq92r.html say 4096 bit keys aren't supported by the JCE policy.

http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html also mentions that the Unlimited Strength policy is required for >2048 bit keys.

This message is automatically generated by JIRA.

milki@rescomp.berkeley.edu (JIRA)

unread,
Oct 13, 2014, 2:30:18 PM10/13/14
to jenkinsc...@googlegroups.com
milki mlk commented on Bug JENKINS-18897

I installed the unlimited policy and verified in the slave node's script console with:

import javax.crypto.Cipher;

int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES");
println(maxKeyLen);

And got output of 2147483647 instead of 128. But I still have the same error.

milki@rescomp.berkeley.edu (JIRA)

unread,
Oct 14, 2014, 1:32:23 AM10/14/14
to jenkinsc...@googlegroups.com
milki mlk commented on Bug JENKINS-18897

The original workaround - copying the bundled bouncycastle jar (plugins/ssh-agent/WEB-INF/lib/bcprov-jdk15on-1.47.jar) from the plugin to $JDKHOME/jre/lib/ext has solved my issue. I will next check to see if this method is compatible with different java versions and if the unlimited policy is needed still. I was unable to use the newest bouncycastle version due to incompatibilities though (java.lang.VerifyError: (class: org/bouncycastle/openssl/PEMReader$EncryptedPrivateKeyParser, method: parseObject signature: (Lorg/bouncycastle/util/io/pem/PemObject;)Ljava/lang/Object Incompatible argument to function)

Reply all
Reply to author
Forward
0 new messages