Thread: [JSch-users] Jsch stopped working with Java8
Status: Alpha
Brought to you by:
ymnk
Menu
▾
▴
jsch-users
|
From: Marc L. <mar...@gm...> - 2014-07-28 16:18:34
|
Hi, we are using JSch as transport mechanism for EDI data to a different company for about 7 years now. Today we upgraded to Java 8 and now when we try to connect, we get: Session.connect: java.security.InvalidKeyException: Key is too long for this algorithm Currently we use: <dependency org="com.jcraft" name="jsch" rev="0.1.42"/> Our code is like this.. Session session = jsch.getSession(sftpUser, sftpHost); session.setPassword(sftpPassword); UserInfo ui = new SFTPClientWrapper.MyUserInfo(); session.setUserInfo(ui); session.connect(); So some questions arise :-) 1) will upgrade to latest version of JSch help me? 2) do you know the error in general? I dont have any clue because i dont do anything with keys. IMO its some kind of internal issue with java and JSch. Thanks for any hints. Marc |
|
From: Nick <eq...@gm...> - 2014-09-11 11:04:58
Attachments:
JSch logs failed.txt
JSch logs success.txt
|
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? Also the following test passes fine without any exception: > 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 |
|
From: Lothar K. <jo...@ki...> - 2014-09-11 12:53:52
|
Am 11.09.2014 13:04, schrieb Nick: > Also the following test passes fine without any exception: [...] >> 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 |
|
From: Nick <eq...@gm...> - 2014-09-11 16:12:54
|
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello Lothar,<br>
<br>
Thank you for quick response.<br>
<br>
<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>
<br>
I ran all tests from the application also.<br>
<br>
<br>
<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>
<br>
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><br>
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:<br>
<br>
final SecretKeySpec keyspec = new SecretKeySpec(new byte[16],
"AES");<br>
final Cipher c = Cipher.getInstance("AES_128/CBC/NoPadding");<br>
<br>
final SecretKeySpec keyspec = new SecretKeySpec(new byte[24],
"AES");<br>
final Cipher c = Cipher.getInstance("AES_192/CBC/NoPadding");<br>
<br>
final SecretKeySpec keyspec = new SecretKeySpec(new byte[32],
"AES");<br>
final Cipher c = Cipher.getInstance("AES_256/CBC/NoPadding");<br>
<br>
<br>
<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>
<br>
Let us assume that aes256-cbc and aes192-cbc are not available but
It reports nothing about aes128-cbc availability:<br>
<br>
<blockquote type="cite">kex: server:
twofish-cbc,twofish128-cbc,3des-cbc,cast128-cbc,aes256-cbc,<b><font
color="#ff0000">aes128-cbc</font></b></blockquote>
<blockquote type="cite">kex: client: aes128-ctr,<b><font
color="#ff0000">aes128-cbc</font></b>,3des-ctr,3des-cbc,blowfish-cbc</blockquote>
<br>
So why it is failed?<br>
<br>
-----<br>
Sincerely,<br>
Nick<br>
<br>
<div class="moz-cite-prefix">11.09.2014 16:53, Lothar Kimmeringer
wrote:<br>
</div>
<blockquote cite="mid:541...@ki..." 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:JSc...@li...">JSc...@li...</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>
<br>
</body>
</html>
|
|
From: Lothar K. <jo...@ki...> - 2014-09-11 16:35:15
|
Am 11.09.2014 18:12, schrieb Nick: > It is not quite correct to replace "AES" with "AES256" based on > the following reference: > 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. > 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: that's OK. > Let us assume that aes256-cbc and aes192-cbc are not available but It reports nothing about aes128-cbc availability: > >> 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 ;-) > 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 |
|
From: <ym...@jc...> - 2014-09-11 15:03:51
|
Hi, +-From: Nick <eq...@gm...> --------- |_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/ |
|
From: Nick <eq...@gm...> - 2014-09-12 08:24:48
|
Hello Atsuhiko, I got the following: > 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 > CheckCiphers: > 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 > kex: server: > twofish-cbc,twofish128-cbc,3des-cbc,cast128-cbc,aes256-cbc,aes128-cbc > kex: server: > 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: server: > kex: server: > kex: client: diffie-hellman-group-exchange-sha1 > kex: client: ssh-rsa,ssh-dss > kex: client: > aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc > kex: client: > 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 > kex: client: > kex: client: > 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 11.09.2014 19:03, Atsuhiko Yamanaka wrote: > Hi, > > +-From: Nick <eq...@gm...> --------- > |_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/ > |
|
From: <ym...@jc...> - 2014-09-12 09:15:27
|
Hi,
+-From: Nick <eq...@gm...> ---------
|_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/
|
|
From: <ym...@jc...> - 2014-12-31 16:40:12
|
Hi, +-From: ym...@jc... (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 |
|
From: <ym...@jc...> - 2015-01-20 15:47:08
|
Hi there, +-From: ym...@jc... (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 |
|
From: Alan E. <ala...@gm...> - 2014-07-28 16:24:59
|
I am also having trouble using jsch with java8. I already posted my problem to this list earlier. Basically, the jEdit FTP plugin doesn't work for me in Java 8. But your problem is different, and one I might be able to help you with. you may need to install the JCE full key-strength encryption. http://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters On Mon, Jul 28, 2014 at 9:18 AM, Marc Logemann <mar...@gm...> wrote: > Hi, > > we are using JSch as transport mechanism for EDI data to a different > company for about 7 years now. Today we upgraded to Java 8 and now when we > try to connect, we get: > > Session.connect: java.security.InvalidKeyException: Key is too long for > this algorithm > > Currently we use: > > <dependency org="com.jcraft" name="jsch" rev="0.1.42"/> > > Our code is like this.. > > Session session = jsch.getSession(sftpUser, sftpHost); > session.setPassword(sftpPassword); > UserInfo ui = new SFTPClientWrapper.MyUserInfo(); > session.setUserInfo(ui); > session.connect(); > > > So some questions arise :-) > > 1) will upgrade to latest version of JSch help me? > > 2) do you know the error in general? I dont have any clue because i dont > do anything with keys. IMO its some kind of internal issue with java and > JSch. > > > Thanks for any hints. > > Marc > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users > > |
|
From: Marc L. <mar...@gm...> - 2014-07-28 16:56:19
|
Thx for hint. Will try later on. Just downloaded the "JCE strong encryption" package for Java 8. 2014-07-28 18:24 GMT+02:00 Alan Ezust <ala...@gm...>: > I am also having trouble using jsch with java8. I already posted my > problem to this list earlier. > Basically, the jEdit FTP plugin doesn't work for me in Java 8. > > But your problem is different, and one I might be able to help you with. > you may need to install the JCE full key-strength encryption. > > > http://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters > > > > > > On Mon, Jul 28, 2014 at 9:18 AM, Marc Logemann <mar...@gm...> > wrote: > >> Hi, >> >> we are using JSch as transport mechanism for EDI data to a different >> company for about 7 years now. Today we upgraded to Java 8 and now when we >> try to connect, we get: >> >> Session.connect: java.security.InvalidKeyException: Key is too long >> for this algorithm >> >> Currently we use: >> >> <dependency org="com.jcraft" name="jsch" rev="0.1.42"/> >> >> Our code is like this.. >> >> Session session = jsch.getSession(sftpUser, sftpHost); >> session.setPassword(sftpPassword); >> UserInfo ui = new SFTPClientWrapper.MyUserInfo(); >> session.setUserInfo(ui); >> session.connect(); >> >> >> So some questions arise :-) >> >> 1) will upgrade to latest version of JSch help me? >> >> 2) do you know the error in general? I dont have any clue because i dont >> do anything with keys. IMO its some kind of internal issue with java and >> JSch. >> >> >> Thanks for any hints. >> >> Marc >> >> >> ------------------------------------------------------------------------------ >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> _______________________________________________ >> JSch-users mailing list >> JSc...@li... >> https://lists.sourceforge.net/lists/listinfo/jsch-users >> >> > |
|
From: Marc L. <mar...@gm...> - 2014-07-28 18:56:11
|
Hi, just want to report back. I upgraded JSch to latest version and installed the JCE Ext. Security JAR from Oracle without any difference. Error is still the same with Java8. Seems to be a major bug in JSch. Hope someone of the authors can reply to that... Marc 2014-07-28 18:56 GMT+02:00 Marc Logemann <mar...@gm...>: > Thx for hint. Will try later on. Just downloaded the "JCE strong > encryption" package for Java 8. > > > 2014-07-28 18:24 GMT+02:00 Alan Ezust <ala...@gm...>: > > I am also having trouble using jsch with java8. I already posted my >> problem to this list earlier. >> Basically, the jEdit FTP plugin doesn't work for me in Java 8. >> >> But your problem is different, and one I might be able to help you with. >> you may need to install the JCE full key-strength encryption. >> >> >> http://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters >> >> >> >> >> >> On Mon, Jul 28, 2014 at 9:18 AM, Marc Logemann <mar...@gm...> >> wrote: >> >>> Hi, >>> >>> we are using JSch as transport mechanism for EDI data to a different >>> company for about 7 years now. Today we upgraded to Java 8 and now when we >>> try to connect, we get: >>> >>> Session.connect: java.security.InvalidKeyException: Key is too long >>> for this algorithm >>> >>> Currently we use: >>> >>> <dependency org="com.jcraft" name="jsch" rev="0.1.42"/> >>> >>> Our code is like this.. >>> >>> Session session = jsch.getSession(sftpUser, sftpHost); >>> session.setPassword(sftpPassword); >>> UserInfo ui = new SFTPClientWrapper.MyUserInfo(); >>> session.setUserInfo(ui); >>> session.connect(); >>> >>> >>> So some questions arise :-) >>> >>> 1) will upgrade to latest version of JSch help me? >>> >>> 2) do you know the error in general? I dont have any clue because i dont >>> do anything with keys. IMO its some kind of internal issue with java and >>> JSch. >>> >>> >>> Thanks for any hints. >>> >>> Marc >>> >>> >>> ------------------------------------------------------------------------------ >>> Infragistics Professional >>> Build stunning WinForms apps today! >>> Reboot your WinForms applications with our WinForms controls. >>> Build a bridge from your legacy apps to the future. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> JSch-users mailing list >>> JSc...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsch-users >>> >>> >> > |
|
From: Lothar K. <jo...@ki...> - 2014-07-29 09:09:17
|
Am 28.07.2014 20:56, schrieb Marc Logemann: > just want to report back. I upgraded JSch to latest version and > installed the JCE Ext. Security JAR from Oracle without any > difference. Error is still the same with Java8. Seems to be a > major bug in JSch. Hope someone of the authors can reply to that... Here[TM] JSCH runs with Java8 and there are no problems like that. Make sure that you really installed the unlimited strength files into the correct directory (maybe you installed it into the JDK but not the JRE or vice versa). If not, please create a java-class that helps to reproduce the problem or provide more informations like Martin already told you. Cheers, Lothar |
|
From: Marc L. <mar...@gm...> - 2014-07-29 12:03:34
|
Hi, here we go with more info. Everything i can get from client side. I dont have control over the remote server: INFO: Connecting to xxxx.deutschepost.de port 22 INFO: Connection established INFO: Remote version string: SSH-2.0-6.4.4.60 SSH Tectia Server INFO: Local version string: SSH-2.0-JSCH-0.1.51 INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256 INFO: CheckKexes: diffie-hellman-group14-sha1 INFO: SSH_MSG_KEXINIT sent INFO: SSH_MSG_KEXINIT received INFO: kex: server: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1, dif...@ss... ,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256 INFO: kex: server: ssh-dss,ssh...@ss... INFO: kex: server: aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc, see...@ss... INFO: kex: server: aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc, see...@ss... INFO: kex: server: hmac-sha1,hmac-md5 INFO: kex: server: hmac-sha1,hmac-md5 INFO: kex: server: none,zlib INFO: kex: server: none,zlib INFO: kex: server: INFO: kex: server: INFO: kex: client: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 INFO: kex: client: ssh-rsa,ssh-dss INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96 INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96 INFO: kex: client: none INFO: kex: client: none INFO: kex: client: INFO: kex: client: INFO: kex: server->client aes128-cbc hmac-md5 none INFO: kex: client->server aes128-cbc hmac-md5 none INFO: SSH_MSG_KEXDH_INIT sent INFO: expecting SSH_MSG_KEXDH_REPLY INFO: Disconnecting from xxxx.deutschepost.de port 22 Caused by: com.jcraft.jsch.JSchException: Session.connect: java.security.InvalidKeyException: Key is too long for this algorithm at com.jcraft.jsch.Session.connect(Session.java:558) at com.jcraft.jsch.Session.connect(Session.java:183) at de.netversys.util.networking.SFTPClientWrapper.transfer(SFTPClientWrapper.java:107) ... 111 more I dont have much more i can provide. 2014-07-29 10:56 GMT+02:00 Lothar Kimmeringer <jo...@ki...>: > Am 28.07.2014 20:56, schrieb Marc Logemann: > > > just want to report back. I upgraded JSch to latest version and > > installed the JCE Ext. Security JAR from Oracle without any > > difference. Error is still the same with Java8. Seems to be a > > major bug in JSch. Hope someone of the authors can reply to that... > > Here[TM] JSCH runs with Java8 and there are no problems like that. > Make sure that you really installed the unlimited strength files > into the correct directory (maybe you installed it into the JDK > but not the JRE or vice versa). If not, please create a java-class > that helps to reproduce the problem or provide more informations > like Martin already told you. > > > Cheers, Lothar > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users > |
|
From: Lothar K. <jo...@ki...> - 2014-07-29 12:31:43
|
Am 29.07.2014 14:03, schrieb Marc Logemann: > here we go with more info. Everything i can get from client side. > I dont have control over the remote server: > > INFO: Connecting to xxxx.deutschepost.de <http://xxxx.deutschepost.de> port 22 why is the servername secret. This shouzld be a public server. 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 |
|
From: Oberhuber, M. <Mar...@wi...> - 2014-07-29 08:26:53
|
Hi Marc,
It may help if you post the full backtrace of the exception so we get an idea what kind of key algorithm is involved:
try {
session.connect();
} catch(Throwable t) {
t.printStackTrace();
}
Some more information about the kind of remote system may also help. For instance, using a Linux box do this:
$> sftp -vvv your.host.ip > debug .log
And debug.log will contain lots of information about the key exchange process:
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
[…]
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: Marc Logemann [mailto:mar...@gm...]
Sent: Monday, July 28, 2014 6:18 PM
To: jsc...@li...
Subject: [JSch-users] Jsch stopped working with Java8
Hi,
we are using JSch as transport mechanism for EDI data to a different company for about 7 years now. Today we upgraded to Java 8 and now when we try to connect, we get:
Session.connect: java.security.InvalidKeyException: Key is too long for this algorithm
Currently we use:
<dependency org="com.jcraft" name="jsch" rev="0.1.42"/>
Our code is like this..
Session session = jsch.getSession(sftpUser, sftpHost);
session.setPassword(sftpPassword);
UserInfo ui = new SFTPClientWrapper.MyUserInfo();
session.setUserInfo(ui);
session.connect();
So some questions arise :-)
1) will upgrade to latest version of JSch help me?
2) do you know the error in general? I dont have any clue because i dont do anything with keys. IMO its some kind of internal issue with java and JSch.
Thanks for any hints.
Marc
|
|
From: Atsuhiko Y. <ym...@jc...> - 2014-07-29 10:38:38
|
Hi, On Tue, Jul 29, 2014 at 1:18 AM, Marc Logemann <mar...@gm...> wrote: > we are using JSch as transport mechanism for EDI data to a different company > for about 7 years now. Today we upgraded to Java 8 and now when we try to > connect, we get: > > Session.connect: java.security.InvalidKeyException: Key is too long for > this algorithm Could you try https://gist.github.com/ymnk/2318108#file-logger-java on Java7 and Java8? 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/ |
|
From: <ym...@jc...> - 2014-09-17 08:01:33
|
Hi, +-From: Marc Logemann <mar...@gm...> -- |_Date: Tue, 29 Jul 2014 14:03:25 +0200 __________ | |here we go with more info. Everything i can get from client side. I dont |have control over the remote server: |INFO: Connecting to xxxx.deutschepost.de port 22 |INFO: Connection established |INFO: Remote version string: SSH-2.0-6.4.4.60 SSH Tectia Server |INFO: Local version string: SSH-2.0-JSCH-0.1.51 ... |INFO: kex: server: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1, |dif...@ss... |,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256 |INFO: kex: server: ssh-dss,ssh...@ss... ... |INFO: kex: client: |diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 |INFO: kex: client: ssh-rsa,ssh-dss We have recognized that the problem has been caused by a problem reported at JDK-8039921[1]. Through the algorithm negotiations, it seems the key exchange method "diffie-hellman-group1-sha1" has been chosen. The problem is that "Tectia Server" ssh server has used a long key, even if RFC4253[1] has defined to use 1024 bit key for that method. IMHO, it is an implementation bug of "Tectia Server". Java7(and previous) has accepted such a long key, so that bug had not been revealed until now. I guess that the following one line will work around your problem, Session session = jsch.getSession(sftpUser, sftpHost); session.setPassword(sftpPassword); UserInfo ui = new SFTPClientWrapper.MyUserInfo(); session.setUserInfo(ui); session.setConfig("kex", "diffie-hellman-group-exchange-sha1"); // !! session.connect(); [1] https://bugs.openjdk.java.net/browse/JDK-8039921 [2] http://tools.ietf.org/html/rfc4253#section-8.1 Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 Skype callto://jcraft/ |
|
From: Peter B. <pet...@pr...> - 2015-01-17 13:35:14
|
Atsuhiko Yamanaka <ymnk@...> writes: > > Hi, > > On Tue, Jul 29, 2014 at 1:18 AM, Marc Logemann > <marc.logemann@...> wrote: > > we are using JSch as transport mechanism for EDI data to a different company > > for about 7 years now. Today we upgraded to Java 8 and now when we try to > > connect, we get: > > > > Session.connect: java.security.InvalidKeyException: Key is too long for > > this algorithm > > Could you try > https://gist.github.com/ymnk/2318108#file-logger-java > on Java7 and Java8? > > 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/ > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > We had a similar problem, though we are using java version 1.7 After upgrading java from version 1.7.0_55 to 1.7.0_71 the SFTP stopped working with the exception mentioned; InvalidKeyException: Key is too long for this algorithm. We were using OpenJDK on CentOS 6 And trying to update the JCE extension did not help But after changing to Oracle's Java JDK version 1.7.0_71 the problem was resolved, even without the JCE extension. I hope this can help |
Thanks for helping keep SourceForge clean.
X