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

Reply via email to