camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: sftp with privateKeyFile using camel-ftp
Date Sat, 17 Jul 2010 08:19:31 GMT
Done.

https://issues.apache.org/activemq/browse/CAMEL-2959

<https://issues.apache.org/activemq/browse/CAMEL-2959>/Bengt

2010/7/17 Claus Ibsen <claus.ibsen@gmail.com>

> On Sat, Jul 17, 2010 at 9:40 AM, Bengt Rodehav <bengt@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<ymnk@jcraft.com>tojsch-users@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-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jsch-users
> >
> >
> >
> >
> > 2010/7/2 Bengt Rodehav <bengt@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 <bengt@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.jiang@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 <bengt@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.ibsen@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 <bengt@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 <bengt@rodehav.com>
> >>>>>>>>
> >>>>>>>>  Logging patch is now attached to the JIRA.
> >>>>>>>>>
> >>>>>>>>> /Bengt
> >>>>>>>>>
> >>>>>>>>> 2010/6/23 Bengt Rodehav <bengt@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 <bengt@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.ibsen@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 <
> >>>>>>>>>>>> bengt@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://user@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message