Hi,

   +-From: Marc Logemann <marc.logem...@gmail.com> --
   |_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,
   |diffie-hellman-group14-sha...@ssh.com
   |,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
   |INFO: kex: server: ssh-dss,ssh-dss-sha...@ssh.com
   ...
   |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/

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
JSch-users mailing list
JSch-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jsch-users

Reply via email to