[JSch-users] Jsch stopped working with Java8

Discussion:

Nick

2014-09-11 11:04:35 UTC

Hello,

I have faced with the same issue as discussed here
http://sourceforge.net/p/jsch/mailman/message/32660306 and here
http://stackoverflow.com/questions/25404371/java8-jcraft-key-is-too-long-for-this-algorithm

I had a chance to test it with two different SFTP servers and got
different results. Please find JSch logs (successful and failed) in
attachments.

Could you help me to find the root of the problem and how it can be fixed?

Try the following program
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
public class CheckCrypto {
public static void main(String[] args){
String cryptoAlg = "AES";
try{
SecretKeySpec keyspec = new SecretKeySpec(new byte[32], cryptoAlg);
Cipher c = Cipher.getInstance(cryptoAlg + "/CBC/NoPadding");
c.init(Cipher.ENCRYPT_MODE, keyspec, new IvParameterSpec(new byte[16]));
}
catch(Exception e){
System.err.println("************ The Java Virtual Machine can't handle strong cryptography.\n************ This will lead to problems with some services and subsystems!");
}
}
}
If you get the exception-message, you still need to install the
unlimimted strength cryptography policy files.
Cheers, Lothar

-----
Sincerely,
Nick

Lothar Kimmeringer

2014-09-11 12:53:43 UTC

Permalink

[...]

String cryptoAlg = "AES";

change that to "AES256" and try again. Make sure that you use the
same JVM with this test as you use for your JSCH-call. Your JMV
might implicitly use AES-64 since we haven't specified the length.

JSch logs failed.txt

[...]

aes256-cbc is not available.
aes192-cbc is not available.

[...]

kex: server->client aes128-cbc hmac-md5 none
kex: client->server aes128-cbc hmac-md5 none

The server only accepts CBC-based ciphers that are
not available with this JVM.

JSch logs success.txt

[...]

aes256-cbc is not available.
aes192-cbc is not available.

[...]

kex: server->client aes128-ctr hmac-md5 none
kex: client->server aes128-ctr hmac-md5 none

Here the server also allows CTR-based ciphers that the
JVM allows as well.

My bet still is on the missing policy files. But Java8 seems to
allow a bit more than previous JVMs (the above test was based on).

Cheers, Lothar

Nick

2014-09-11 16:12:32 UTC

Permalink

<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello Lothar, 
 
Thank you for quick response. 
 
<blockquote type="cite">
<pre wrap="">Make sure that you use the same JVM with this test as you use for your JSCH-call.</pre>
</blockquote>
 
I ran all tests from the application also. 
 
 
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> String cryptoAlg = "AES";
</pre>
</blockquote>
</blockquote>
<pre wrap="">change that to "AES256" and try again.</pre>
</blockquote>
 
It is not quite correct to replace "AES" with "AES256" based on the
following reference:
<a class="moz-txt-link-freetext" href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html">http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html</a> 
Anyway I did few tests with 128, 192, 256 key lengths. All of them
are passed successfully. Here are fragments of my code, please write
me if I am mistaken: 
 
final SecretKeySpec keyspec = new SecretKeySpec(new byte[16],
"AES"); 
final Cipher c = Cipher.getInstance("AES_128/CBC/NoPadding"); 
 
final SecretKeySpec keyspec = new SecretKeySpec(new byte[24],
"AES"); 
final Cipher c = Cipher.getInstance("AES_192/CBC/NoPadding"); 
 
final SecretKeySpec keyspec = new SecretKeySpec(new byte[32],
"AES"); 
final Cipher c = Cipher.getInstance("AES_256/CBC/NoPadding"); 
 
 
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">JSch logs failed.txt
</pre>
</blockquote>
<pre wrap="">[...]
</pre>
<blockquote type="cite">
<pre wrap="">aes256-cbc is not available.
aes192-cbc is not available. </pre> </blockquote> <pre wrap="">[...] </pre> <blockquote type="cite"> <pre wrap="">kex: server->client aes128-cbc hmac-md5 none
kex: client->server aes128-cbc hmac-md5 none
</pre>
</blockquote>
<pre wrap="">The server only accepts CBC-based ciphers that are
not available with this JVM.
</pre>
</blockquote>
 
Let us assume that aes256-cbc and aes192-cbc are not available but
It reports nothing about aes128-cbc availability: 
 
<blockquote type="cite">kex: server:
twofish-cbc,twofish128-cbc,3des-cbc,cast128-cbc,aes256-cbc,aes128-cbc</blockquote>
<blockquote type="cite">kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc</blockquote>
 
So why it is failed? 
 
----- 
Sincerely, 
Nick 
 
<div class="moz-cite-prefix">11.09.2014 16:53, Lothar Kimmeringer
wrote: 
</div>
<blockquote cite="mid:***@kimmeringer.de" type="cite">
<pre wrap="">Am 11.09.2014 13:04, schrieb Nick:

</pre>
<blockquote type="cite">
<pre wrap="">Also the following test passes fine without any exception:
</pre>
</blockquote>
<pre wrap="">[...]
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> String cryptoAlg = "AES";
</pre>
</blockquote>
</blockquote>
<pre wrap="">
change that to "AES256" and try again. Make sure that you use the
same JVM with this test as you use for your JSCH-call. Your JMV
might implicitly use AES-64 since we haven't specified the length.

</pre>
<blockquote type="cite">
<pre wrap="">JSch logs failed.txt
</pre>
</blockquote>
<pre wrap="">[...]
</pre>
<blockquote type="cite">
<pre wrap="">aes256-cbc is not available.
aes192-cbc is not available. </pre> </blockquote> <pre wrap="">[...] </pre> <blockquote type="cite"> <pre wrap="">kex: server->client aes128-cbc hmac-md5 none
kex: client->server aes128-cbc hmac-md5 none
</pre>
</blockquote>
<pre wrap="">
The server only accepts CBC-based ciphers that are
not available with this JVM.

</pre>
<blockquote type="cite">
<pre wrap="">JSch logs success.txt
</pre>
</blockquote>
<pre wrap="">[...]
</pre>
<blockquote type="cite">
<pre wrap="">aes256-cbc is not available.
aes192-cbc is not available. </pre> </blockquote> <pre wrap="">[...] </pre> <blockquote type="cite"> <pre wrap="">kex: server->client aes128-ctr hmac-md5 none
kex: client->server aes128-ctr hmac-md5 none
</pre>
</blockquote>
<pre wrap="">
Here the server also allows CTR-based ciphers that the
JVM allows as well.

My bet still is on the missing policy files. But Java8 seems to
allow a bit more than previous JVMs (the above test was based on).

Cheers, Lothar

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk</a>
_______________________________________________
JSch-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:JSch-***@lists.sourceforge.net">JSch-***@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/jsch-users">https://lists.sourceforge.net/lists/listinfo/jsch-users</a>

</pre>
</blockquote>
 
</body>
</html>

Lothar Kimmeringer

2014-09-11 16:35:06 UTC

Permalink

Post by Nick
It is not quite correct to replace "AES" with "AES256" based on
http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html

I found that out later as well. It seems that dependent on
your installed providers this sometimes works.

Post by Nick
Anyway I did few tests with 128, 192, 256 key lengths. All of
them are passed successfully. Here are fragments of my code,

that's OK.

Post by Nick

kex: server: twofish-cbc,twofish128-cbc,3des-cbc,cast128-cbc,aes256-cbc,*aes128-cbc*
kex: client: aes128-ctr,*aes128-cbc*,3des-ctr,3des-cbc,blowfish-cbc

I missed these entries, so my theory is wrong ;-)

Post by Nick
So why it is failed?

Have you tried Atsuhiko's suggestion already? What size is the key
being involved here? Maybe that's what's too big.

Cheers, Lothar

Atsuhiko Yamanaka

2014-09-11 15:03:42 UTC

Permalink

Hi,

+-From: Nick <***@gmail.com> ---------
|_Date: Thu, 11 Sep 2014 15:04:35 +0400 __
|
|I have faced with the same issue as discussed here
|http://sourceforge.net/p/jsch/mailman/message/32660306 and here
|http://stackoverflow.com/questions/25404371/java8-jcraft-key-is-too-long-for-this-algorithm

|I had a chance to test it with two different SFTP servers and got
|different results. Please find JSch logs (successful and failed) in
|attachments.
|Could you help me to find the root of the problem and how it can be fixed?

How about inserting following line,
session.setConfig("kex", "diffie-hellman-group-exchange-sha1");
before session.connect() ?

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
Skype callto://jcraft/

Nick

2014-09-12 08:24:37 UTC

Permalink

Hello Atsuhiko,

Connecting to *.*.*.* port 22
Connection established
Remote version string: SSH-2.0-1.36_sshlib GlobalSCAPE
Local version string: SSH-2.0-JSCH-0.1.51
aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
CheckKexes: diffie-hellman-group14-sha1
SSH_MSG_KEXINIT sent
SSH_MSG_KEXINIT received
kex: server: diffie-hellman-group1-sha1
kex: server: ssh-dss
twofish-cbc,twofish128-cbc,3des-cbc,cast128-cbc,aes256-cbc,aes128-cbc
twofish-cbc,twofish128-cbc,3des-cbc,cast128-cbc,aes256-cbc,aes128-cbc
kex: server: hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96
kex: server: hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96
kex: server: zlib,none
kex: server: zlib,none
kex: client: diffie-hellman-group-exchange-sha1
kex: client: ssh-rsa,ssh-dss
aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
kex: client: none
kex: client: none
Disconnecting from *.*.*.* port 22
Caused by: com.jcraft.jsch.JSchException: Algorithm negotiation fail
at com.jcraft.jsch.Session.receive_kexinit(Session.java:583)
at com.jcraft.jsch.Session.connect(Session.java:320)
at com.jcraft.jsch.Session.connect(Session.java:183)

-----
Sincerely,
Nick

Hi,
|_Date: Thu, 11 Sep 2014 15:04:35 +0400 __
|
|I have faced with the same issue as discussed here
|http://sourceforge.net/p/jsch/mailman/message/32660306 and here
|http://stackoverflow.com/questions/25404371/java8-jcraft-key-is-too-long-for-this-algorithm
|I had a chance to test it with two different SFTP servers and got
|different results. Please find JSch logs (successful and failed) in
|attachments.
|Could you help me to find the root of the problem and how it can be fixed?
How about inserting following line,
session.setConfig("kex", "diffie-hellman-group-exchange-sha1");
before session.connect() ?
Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
Skype callto://jcraft/

Atsuhiko Yamanaka

2014-09-12 09:15:12 UTC

Permalink

Hi,

+-From: Nick <***@gmail.com> ---------
|_Date: Fri, 12 Sep 2014 12:24:37 +0400 __
|
|I got the following:
...
|> Remote version string: SSH-2.0-1.36_sshlib GlobalSCAPE
...

kex: server: diffie-hellman-group1-sha1

Frankly to say, there is no hope to connect to that sshd by using
JSch with Java8. It seems that sshd from GlobalSCAPE will use
the longer(>1024) key for "diffie-hellman-group1-sha1", but 1024 length
key must be used in that key exchage method, as defined in RFC4253[1].
IMHO, it is the implementation bug of GlobalSCAPE.
The second problem is that Java8 has been suddenly changed to reject
long key(>1024) for DSA Signature[2].
If you need to use that sshd, check its configuration or
vote that issue entry[2] to fix that undocumented breaking change.

[1] http://tools.ietf.org/html/rfc4253#section-8.1
[2] https://bugs.openjdk.java.net/browse/JDK-8039921

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
Skype callto://jcraft/

Atsuhiko Yamanaka

2014-12-31 16:14:37 UTC

Permalink

Hi,

+-From: ***@jcraft.com (Atsuhiko Yamanaka) --
|_Date: Fri, 12 Sep 2014 18:15:12 +0900 ______
|
|Frankly to say, there is no hope to connect to that sshd by using
|JSch with Java8. It seems that sshd from GlobalSCAPE will use
|the longer(>1024) key for "diffie-hellman-group1-sha1", but 1024 length
|key must be used in that key exchage method, as defined in RFC4253[1].
|IMHO, it is the implementation bug of GlobalSCAPE.
|The second problem is that Java8 has been suddenly changed to reject
|long key(>1024) for DSA Signature[2].

FYI, I had sent a request[1] for changing that behavior
to security-dev mailing list, and the problem has been fixed[2][3] at last.
Java9 will not have the reported problem.

[1] http://mail.openjdk.java.net/pipermail/security-dev/2014-September/011228.html
[2] https://bugs.openjdk.java.net/browse/JDK-8039921?focusedCommentId=13593153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13593153
[3] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/edd7a67585a5

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
Skype callto://jcraft/
Twitter: http://twitter.com/ymnk
Facebook: http://facebook.com/aymnk

Atsuhiko Yamanaka

2015-01-20 15:46:52 UTC

Permalink

Hi there,

+-From: ***@jcraft.com (Atsuhiko Yamanaka) --
|_Date: Thu, 1 Jan 2015 01:14:37 +0900 _______
|
|FYI, I had sent a request[1] for changing that behavior
|to security-dev mailing list, and the problem has been fixed[2][3]
|at last. Java9 will not have the reported problem.
|[1] http://mail.openjdk.java.net/pipermail/security-dev/2014-September/011228.html
|[2] https://bugs.openjdk.java.net/browse/JDK-8039921?focusedCommentId=13593153&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13593153
|[3] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/edd7a67585a5

FYI, it seems that fix has been backported[1] to JDK8u60.

[1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3212f1631643

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Skype callto://jcraft/
Twitter: http://twitter.com/ymnk
Facebook: http://facebook.com/aymnk