On Sat, Jul 17, 2010 at 9:40 AM, Bengt Rodehav <be...@rodehav.com> wrote: > I just got an announcement email regarding JSch 0.1.43. I include it below. > Will you try to incorporate this new version of JSch into Camel (with the > necessary OSGi repackaging)? >
Could you create a ticket in JIRA about the upgrade. > Best regards, > > /Bengt > > --- > > fromAtsuhiko Yamanaka<y...@jcraft.com>tojsch-us...@lists.sourceforge.net > date16 july 2010 10.43subject[JSch-users] ANNOUNCE: JSch 0.1.43 > > Hi there, > > JSch 0.1.43 has been released. > It is available at > https://sourceforge.net/projects/jsch/files/jsch/jsch-0.1.43.zip/download > and its md5sum is ccf75ce1ee6e2eba717602ff8c344c74 > And you can get its byte code in jar file format at > https://sourceforge.net/projects/jsch/files/jsch/jsch-0.1.43.jar/download > and its md5sum is 565c4bf1ff1b2816df4e898bbe693ec4 > > Changes since version 0.1.42: > - bugfix: the remote window size must be in unsigned int. FIXED. > - bugfix: support for EBCDIC environment. FIXED. > - bugfix: data may be written to the closed channel. FIXED. > - bugfix: NPE in closing channels. FIXED. > - bugfix: the private key file may include garbage data before its header. > FIXED. > - bugfix: the session down may not be detected during the re-keying process. > FIXED. > - change: try keyboard-interactive auth with the given password if UserInfo > is not given. > - change: working around the wrong auth method list sent by some SSHD > in the partial auth success. > - change: working around the CPNI-957037 Plain-text Recovery Attack. > - change: in searching for [host]:non-default port in known_hosts, > host:22 should be also checked. > - change: updating copyright messages; 2009 -> 2010 > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > JSch-users mailing list > jsch-us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jsch-users > > > > > 2010/7/2 Bengt Rodehav <be...@rodehav.com> > >> The latest I heard, Atsuhiko is hoping to release 0.1.43 of Jsch by the end >> of next week. I think it has been delayed a bit compared to what he >> initially told me. >> >> /Bengt >> >> 2010/7/1 Bengt Rodehav <be...@rodehav.com> >> >> Willem, >>> >>> No not yet. Just sent an email to Atsuhiko asking about an ETA. Will let >>> you know. >>> >>> /Bengt >>> >>> 2010/7/1 Willem Jiang <willem.ji...@gmail.com> >>> >>> Hi Bengt, >>>> >>>> Did the jsch 0.1.43 release? >>>> If so, I will head to update the OSGi feature and bundles. >>>> >>>> Willem >>>> >>>> >>>> >>>> Bengt Rodehav wrote: >>>> >>>>> Claus, >>>>> >>>>> A little update on this matter... >>>>> >>>>> Atsuhiko at Jcarft gave me a fix version to test. It seems to solve the >>>>> problems I had encountered. The fix was included in a release candidate >>>>> for >>>>> Jsch 0.1.43. I'm hoping they release this very soon. When they do, I >>>>> wonder >>>>> what has to be done in order to incorporate the new Jsch version into >>>>> Camel? >>>>> >>>>> It seems like Camel uses a repackaged (for OSGi) version of Jsch. The >>>>> repackaging seems to be done by the ServiceMix team. I would of course >>>>> want >>>>> the Jsch fix to be part of the next Camel release (is there a planned >>>>> date >>>>> for 2.4?). I imagine it is just a matter of directing the dependencies >>>>> to >>>>> the new Jsch version since I don't think the API is changed. Will you >>>>> (or >>>>> someone on the Camel team) ask the ServiceMix guys to repackage the new >>>>> Jsch >>>>> version - or how does it usually work? >>>>> >>>>> /Bengt >>>>> >>>>> 2010/6/24 Bengt Rodehav <be...@rodehav.com> >>>>> >>>>> Glad to be of help - as others help me. >>>>>> >>>>>> BTW just got an answer from Atsuhiko at Jcraft. He will try to fix this >>>>>> tonight while watching Japan vs Denmark. Had to wish him good luck >>>>>> against >>>>>> Denmark - sorry... Being Swedish I normally support Denmark and Norway >>>>>> when >>>>>> we're not represented ourselves. But this time you were the ones who >>>>>> kicked >>>>>> us out of the world cup :-) >>>>>> >>>>>> /Bengt >>>>>> >>>>>> >>>>>> 2010/6/24 Claus Ibsen <claus.ib...@gmail.com> >>>>>> >>>>>> Hi Bengt >>>>>> >>>>>>> Thanks for sharing this information. Nice that you got the attention >>>>>>> from JCraft. Then they may fix this in the near future. >>>>>>> And thanks for helping out with the FTP component of Camel. Its now >>>>>>> better thanks to you. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 24, 2010 at 8:53 AM, Bengt Rodehav <be...@rodehav.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Claus, >>>>>>>> >>>>>>>> It seems I stumbled on a bug in Jsch - must be in my genes... >>>>>>>> >>>>>>>> I have a conversation on their mailing list. Here is a link to the >>>>>>>> >>>>>>> archives. >>>>>>> >>>>>>>> The latest messages are not yet in the archives but you can have a >>>>>>>> look >>>>>>>> >>>>>>> in a >>>>>>> >>>>>>>> day or two. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> http://sourceforge.net/mailarchive/forum.php?thread_name=201006231155.UAA11635%40jcraft.com&forum_name=jsch-users >>>>>>> >>>>>>>> Basically, it seems like Jsch cannot handle situations where the >>>>>>>> server >>>>>>>> requires more than one authentication method. In my case I required >>>>>>>> both >>>>>>>> >>>>>>> a >>>>>>> >>>>>>>> private key AND a password. If I only require a private key or only >>>>>>>> >>>>>>> require >>>>>>> >>>>>>>> a password then Jsch (and camel-ftp) works. Hope they will fix this >>>>>>>> >>>>>>> promptly >>>>>>> >>>>>>>> but I have no insight as to how quick they release new versions of >>>>>>>> Jsch. >>>>>>>> >>>>>>>> /Bengt >>>>>>>> >>>>>>>> >>>>>>>> 2010/6/23 Bengt Rodehav <be...@rodehav.com> >>>>>>>> >>>>>>>> Logging patch is now attached to the JIRA. >>>>>>>>> >>>>>>>>> /Bengt >>>>>>>>> >>>>>>>>> 2010/6/23 Bengt Rodehav <be...@rodehav.com> >>>>>>>>> >>>>>>>>> Claus, >>>>>>>>>> >>>>>>>>>> I'll try to get some help regarding this on the Jsch mailing list. >>>>>>>>>> >>>>>>>>>> Remember I told you nothing turns up in the log. I've looked at the >>>>>>>>>> >>>>>>>>> source >>>>>>> >>>>>>>> code for camel-ftp (SftpOperations.java) and there is no logger >>>>>>>>>> >>>>>>>>> attached to >>>>>>> >>>>>>>> Jsch. I created a JIRA for that: >>>>>>>>>> https://issues.apache.org/activemq/browse/CAMEL-2842 >>>>>>>>>> >>>>>>>>>> <https://issues.apache.org/activemq/browse/CAMEL-2842>I have a >>>>>>>>>> patch >>>>>>>>>> >>>>>>>>> that >>>>>>> >>>>>>>> I'll attach to the JIRA. I need to do a SVN update locally to be able >>>>>>>>>> >>>>>>>>> to >>>>>>> >>>>>>>> create a diff file but I cant currently connect to the SVN >>>>>>>>>> repository. >>>>>>>>>> >>>>>>>>> I'll >>>>>>> >>>>>>>> attach the patch as soon as possible. >>>>>>>>>> >>>>>>>>>> /Bengt >>>>>>>>>> >>>>>>>>>> 2010/6/23 Bengt Rodehav <be...@rodehav.com> >>>>>>>>>> >>>>>>>>>> Hi Claus, >>>>>>>>>> >>>>>>>>>>> Unfortunately I get nothing in the log. If it were the 256 limit I >>>>>>>>>>> >>>>>>>>>> was >>>>>>> >>>>>>>> kind of expecting some kind of Exception. I've also been "bitten" by >>>>>>>>>>> >>>>>>>>>> it in >>>>>>> >>>>>>>> the past and normally you get some kind of security related >>>>>>>>>>> >>>>>>>>>> exception. Maybe >>>>>>> >>>>>>>> it's caught somewhere... >>>>>>>>>>> >>>>>>>>>>> To be sure I'll download the updated policy files and also try a >>>>>>>>>>> >>>>>>>>>> separate >>>>>>> >>>>>>>> client like you suggest. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> /Bengt >>>>>>>>>>> >>>>>>>>>>> 2010/6/23 Claus Ibsen <claus.ib...@gmail.com> >>>>>>>>>>> >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>>> The key length restriction have bitten me in the past. You had to >>>>>>>>>>>> download a special extension and override some files in the JRE >>>>>>>>>>>> to >>>>>>>>>>>> >>>>>>>>>>> be >>>>>>> >>>>>>>> able to use longer keys. I think the restriction was very low at the >>>>>>>>>>>> time, like 256 or so. >>>>>>>>>>>> >>>>>>>>>>>> Since its JCraft that does the SFTP stuff you may have to google >>>>>>>>>>>> a >>>>>>>>>>>> >>>>>>>>>>> bit >>>>>>> >>>>>>>> and try reading some of their documentation how to do this. Maybe >>>>>>>>>>>> there is some help there. >>>>>>>>>>>> >>>>>>>>>>>> And I assume you dont get any errors or the likes in the log / >>>>>>>>>>>> >>>>>>>>>>> console? >>>>>>> >>>>>>>> And have you tried outside OSGi, eg from a plain unit test also? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 22, 2010 at 11:08 PM, Bengt Rodehav < >>>>>>>>>>>> be...@rodehav.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm trying to get sftp private key authentication to work with >>>>>>>>>>>>> >>>>>>>>>>>> sftp >>>>>>> >>>>>>>> with no >>>>>>>>>>>> >>>>>>>>>>>>> luck. I have a route similar to the following: >>>>>>>>>>>>> >>>>>>>>>>>>> from("file:datadir").to("sftp://u...@localhost >>>>>>>>>>>>> /datadir?password=password&privateKeyFile=user.key"); >>>>>>>>>>>>> >>>>>>>>>>>>> The sftp server is Serv-U. I generate key pairs using Serv-U. >>>>>>>>>>>>> The >>>>>>>>>>>>> >>>>>>>>>>>> public key >>>>>>>>>>>> >>>>>>>>>>>>> is used by Serv-U while camel-ftp is configured with the private >>>>>>>>>>>>> >>>>>>>>>>>> key. >>>>>>> >>>>>>>> Camel >>>>>>>>>>>> >>>>>>>>>>>>> manages to connect to Serv-U but never to log in. The key type >>>>>>>>>>>>> is >>>>>>>>>>>>> >>>>>>>>>>>> DSA >>>>>>> >>>>>>>> and >>>>>>>>>>>> >>>>>>>>>>>>> the key length is 1024. The private key looks lilke this: >>>>>>>>>>>>> >>>>>>>>>>>>> -----BEGIN DSA PRIVATE KEY----- >>>>>>>>>>>>> MIIBugIBAAKBgQCR+zLyBwj0gcvNh6xmauvc2YdYYEjjoXdIUpzb01zmwFzqia9q >>>>>>>>>>>>> nWCTL5t3iwqgBrZIxOa75M322OsG99+7JsBn1YaTxDJ4hSnX0dyheS620HsMFbP1 >>>>>>>>>>>>> 27LjYFX2mee8jeZN8GIUAdPLDHPkvGnlGfFFvj8f/IKfjAexECrBhlyhyQIVAI+1 >>>>>>>>>>>>> CU2hfXqiLDuIPKruy17wrzyVAoGAB7qCoD8vJPq4jMZ77Scv4dfWgz6F+LMImcl8 >>>>>>>>>>>>> QOIh+3f3JhJvR9f+hw1MGsg3l/z57GlfgXkqt420vTPI6OghELv/hauFNSExCKqv >>>>>>>>>>>>> kJW+J7Hyoa0sGuf7Ihy9vC6PJnoNkopqqecwpAUUpvKahcZ1uvNnGfRDc5SGmuzn >>>>>>>>>>>>> ZhKHy5ICgYBv94YBWdxGXWwcUKAmJrC+u3Xdnb8t1RY0RcrbKYqQe5Eekza4gh8B >>>>>>>>>>>>> iGdLMBdX3CZlXINJRhsK0UU7E+edEIk+aCtAnFE2+S4zPqtpFGOLIjOQ+i2W5XZv >>>>>>>>>>>>> MOHoxrse7qNvstZRc0BMaEKuKd9DW4wy9JMMZC7xChF8590rCaWA5gIURVR0jghL >>>>>>>>>>>>> lZpwVaJtN6Yo7kUe9S8= >>>>>>>>>>>>> -----END DSA PRIVATE KEY----- >>>>>>>>>>>>> >>>>>>>>>>>>> Is this a format that camel-ftp recognises? Can anyone suggest >>>>>>>>>>>>> how >>>>>>>>>>>>> >>>>>>>>>>>> to >>>>>>> >>>>>>>> create >>>>>>>>>>>> >>>>>>>>>>>>> a key pair that camel-ftp will recognise. I can then try to see >>>>>>>>>>>>> if >>>>>>>>>>>>> >>>>>>>>>>>> Serv-U >>>>>>>>>>>> >>>>>>>>>>>>> also supports that? >>>>>>>>>>>>> >>>>>>>>>>>>> To verify that Serv-U works, I tried connecting with Filezilla >>>>>>>>>>>>> >>>>>>>>>>>> client. >>>>>>> >>>>>>>> It >>>>>>>>>>>> >>>>>>>>>>>>> converted the private key to Putty format but then it worked. >>>>>>>>>>>>> >>>>>>>>>>>>> Could it have anything to do with US export limitations? Is the >>>>>>>>>>>>> >>>>>>>>>>>> key to >>>>>>> >>>>>>>> long? >>>>>>>>>>>> >>>>>>>>>>>>> /Bengt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Claus Ibsen >>>>>>>>>>>> Apache Camel Committer >>>>>>>>>>>> >>>>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/ >>>>>>>>>>>> Open Source Integration: http://fusesource.com >>>>>>>>>>>> Blog: http://davsclaus.blogspot.com/ >>>>>>>>>>>> Twitter: http://twitter.com/davsclaus >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Claus Ibsen >>>>>>> Apache Camel Committer >>>>>>> >>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/ >>>>>>> Open Source Integration: http://fusesource.com >>>>>>> Blog: http://davsclaus.blogspot.com/ >>>>>>> Twitter: http://twitter.com/davsclaus >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus