jsch-users Mailing List for JSch (Page 8)

Status: Alpha

Brought to you by: ymnk

jsch-users — For JSch users : support, suggestions, announcments, etc.

You can subscribe to this list here.

2002	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (17)	Nov (3)	Dec (5)
2003	Jan (34)	Feb (70)	Mar (18)	Apr (17)	May (21)	Jun (20)	Jul (27)	Aug (12)	Sep (10)	Oct (7)	Nov (21)	Dec (5)
2004	Jan (18)	Feb (13)	Mar (35)	Apr (8)	May (26)	Jun (32)	Jul (19)	Aug (37)	Sep (14)	Oct (20)	Nov (41)	Dec (48)
2005	Jan (44)	Feb (60)	Mar (62)	Apr (42)	May (26)	Jun (55)	Jul (29)	Aug (21)	Sep (56)	Oct (20)	Nov (17)	Dec (9)
2006	Jan (33)	Feb (49)	Mar (27)	Apr (27)	May (67)	Jun (28)	Jul (64)	Aug (45)	Sep (39)	Oct (52)	Nov (36)	Dec (45)
2007	Jan (60)	Feb (44)	Mar (57)	Apr (18)	May (15)	Jun (37)	Jul (27)	Aug (32)	Sep (48)	Oct (52)	Nov (48)	Dec (17)
2008	Jan (28)	Feb (6)	Mar (29)	Apr (27)	May (10)	Jun (33)	Jul (27)	Aug (15)	Sep (46)	Oct (18)	Nov (10)	Dec (8)
2009	Jan (22)	Feb (17)	Mar (10)	Apr (14)	May (20)	Jun (28)	Jul (9)	Aug (8)	Sep (12)	Oct (22)	Nov (23)	Dec (18)
2010	Jan (32)	Feb (18)	Mar (30)	Apr (54)	May (25)	Jun (22)	Jul (26)	Aug (54)	Sep (15)	Oct (24)	Nov (53)	Dec (11)
2011	Jan (45)	Feb (40)	Mar (47)	Apr (28)	May (30)	Jun (58)	Jul (13)	Aug (27)	Sep (41)	Oct (7)	Nov (18)	Dec (22)
2012	Jan (36)	Feb (71)	Mar (30)	Apr (25)	May (32)	Jun (15)	Jul (12)	Aug (8)	Sep (16)	Oct (21)	Nov (4)	Dec
2013	Jan (9)	Feb (6)	Mar (27)	Apr (16)	May (16)	Jun (10)	Jul (5)	Aug (1)	Sep (7)	Oct (12)	Nov (25)	Dec (10)
2014	Jan (4)	Feb (24)	Mar (7)	Apr (12)	May (14)	Jun (7)	Jul (13)	Aug (3)	Sep (21)	Oct (10)	Nov (4)	Dec (6)
2015	Jan (8)	Feb (8)	Mar (6)	Apr (5)	May (2)	Jun (4)	Jul (2)	Aug	Sep (2)	Oct (16)	Nov (6)	Dec (9)
2016	Jan (7)	Feb (7)	Mar (3)	Apr (1)	May (12)	Jun (7)	Jul (7)	Aug (6)	Sep (5)	Oct (15)	Nov (6)	Dec (1)
2017	Jan	Feb	Mar (2)	Apr	May (2)	Jun (1)	Jul (1)	Aug	Sep (3)	Oct	Nov (3)	Dec
2018	Jan (1)	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2019	Jan (4)	Feb	Mar (2)	Apr (4)	May (2)	Jun	Jul	Aug	Sep	Oct (2)	Nov (2)	Dec (1)
2020	Jan	Feb	Mar	Apr	May	Jun (3)	Jul	Aug	Sep	Oct	Nov	Dec
2023	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

<< < 1 .. 6 7 8 9 10 .. 154 > >> (Page 8 of 154)

[JSch-users] Jsch key exchange protocols

From: Karbas, R. <rei...@un...> - 2015-01-07 17:22:38

We are using Gerrit for our code review which as of now is using jsch 0.1.50

However when we changed the recipient server for the replication to openssh 6.7p1 the replication failed because of an error during negotiating the key exchange algorithm

Based on the changelog an additional algorithm (diffie-hellman-group-exchange-sha256) was added to jsch

I just downloaded the source files for 0.1.51 and looked at file keyExchange.java
I only see the following:

  static String kex="diffie-hellman-group1-sha1";

However based on the documentation for openssh 6.7p1 only following kex values are supported by default:

* cur...@li...
* ecdh-sha2-nistp256
* ecdh-sha2-nistp384
* ecdh-sha2-nistp521
* diffie-hellman-group-exchange-sha256
* diffie-hellman-group14-sha1

What happened to the supposed addition in version 0.1.50?

Did this get lost somewhere?

Thanks a lot

Reinhard

Re: [JSch-users] Jsch stopped working with Java8

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

Re: [JSch-users] PassPhrase for privateKey fail

From: Alan E. <ala...@gm...> - 2014-12-18 15:03:56

I have noticed this too.
http://sourceforge.net/p/jedit/plugin-bugs/1726/

And in another case, I got "Auth Cancel".
http://sourceforge.net/p/jedit/plugin-bugs/1787/

First, double-check you have JCE unlimited key strength encryption
installed.

But if you do and still have this problem, I believe some very old SSH keys
can not be read by java 1.8+jsch due to new restrictions in crypto. For
example, 2048-bit DSA keys can't be created anymore from current versions
of ssh-keygen but are still recognized by older ssh clients. And also by
jsch + Java 1.7.

However, in my experience, once you start using Java 1.8, some of those old
keys have to be regenned with more current versions of ssh-keygen.

On Thu, Dec 18, 2014 at 3:33 AM, sodiska saw <so...@ho...> wrote:
>
> Hi,
>
>     I have downloaded Jsch version 1.51 and started to using it to connect
> a remote server using private key which has passphrase. Funny thing is when
> I use the private key and with the passphrase via a Terminal, it works
> fine, but when I use a JAVA app that I wrote, it keep asking me to key in
> passphrase for 3 times, and then reply error message: Auth Fail.
>
>     I am pretty sure the private key and the passphrase is correct since I
> have tested it in a terminal. Anyone has the same experience?
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users
>
>

[JSch-users] PassPhrase for privateKey fail

From: sodiska s. <so...@ho...> - 2014-12-18 11:33:30

Hi,
    I have downloaded Jsch version 1.51 and started to using it to connect a remote server using private key which has passphrase. Funny thing is when I use the private key and with the passphrase via a Terminal, it works fine, but when I use a JAVA app that I wrote, it keep asking me to key in passphrase for 3 times, and then reply error message: Auth Fail.
    I am pretty sure the private key and the passphrase is correct since I have tested it in a terminal. Anyone has the same experience?

Re: [JSch-users] SFTP RFCs

From: Jung, V. <vol...@so...> - 2014-12-12 09:18:42

Hello Flavio,

to my knowledge SFTP is not covered by the mentioned RFC 1350 (TFTP) and there is no RFC which does. As of today there are only a number of drafts specifying the SFTP protocol.

The FileZilla-Project wiki has a page [1] with links to most or all relevant RFCs and SFTP specification drafts (English Wikipedia entry for 'SSH File Transfer Protocol' is also a good starting point). Please see for yourself whether SFTP does specify the ominous final packet.

Cheers
Volker

[1] https://wiki.filezilla-project.org/SFTP_specifications

Von: Flavio Orfano [mailto:fo...@ho...]
Gesendet: Freitag, 12. Dezember 2014 01:49
An: jsc...@li...
Betreff: [JSch-users] SFTP RFCs

Hello Lads,

I do use JSCH(version 1.0.50) for SFTP on my application .
Running our component against a Sterling Integrator(IBM) to do a SFTP pooling is failing due to the following:

According to them when the SFTP is done with a file, their Sterling Integrator (IBM) sends a final packet and waits for a ACK from my component (which uses JSCH) but as it never get the ACK from us saying all is fine then their Sterling Integrator resend the file again and again (infinite loop).

They mention that this is according to an RFC (have to confirm with them). Doing a quick search in google I could find the RFC 1350 https://tools.ietf.org/html/rfc1350. in this RFC it mention about normal termination:
Normal Termination

The end of a transfer is marked by a DATA packet that contains

between 0 and 511 bytes of data (i.e., Datagram length < 516). This

packet is acknowledged by an ACK packet like all other DATA packets.

The host acknowledging the final DATA packet may terminate its side

of the connection on sending the final ACK. On the other hand,

dallying is encouraged. This means that the host sending the final

ACK will wait for a while before terminating in order to retransmit

the final ACK if it has been lost. The acknowledger will know that

the ACK has been lost if it receives the final DATA packet again.

The host sending the last DATA must retransmit it until the packet is

acknowledged or the sending host times out. If the response is an

ACK, the transmission was completed successfully. If the sender of

the data times out and is not prepared to retransmit any more, the

transfer may still have been completed successfully, after which the

acknowledger or network may have experienced a problem. It is also

possible in this case that the transfer was unsuccessful. In any

case, the connection has been closed.

My QUESTION IS: Do JSCH follow any RFC related to TFTP, FTP etc? Or would it only follow the SSH RFCs? Also would any RFC for SSH have similar normal termination as described above?

So I am trying to understand if their comment makes any sense or not. I would appreciate any input here.

Cheers!

Flavio

[JSch-users] SFTP RFCs

From: Flavio O. <fo...@ho...> - 2014-12-12 00:49:09

Hello Lads,

I do use JSCH(version 1.0.50) for SFTP on my application .
Running our component against a Sterling Integrator(IBM) to do a SFTP pooling is failing due to the following:

Normal Termination

The end of a transfer is marked by a DATA packet that contains
between 0 and 511 bytes of data (i.e., Datagram length < 516). This
packet is acknowledged by an ACK packet like all other DATA packets.
The host acknowledging the final DATA packet may terminate its side
of the connection on sending the final ACK. On the other hand,
dallying is encouraged. This means that the host sending the final
ACK will wait for a while before terminating in order to retransmit
the final ACK if it has been lost. The acknowledger will know that
the ACK has been lost if it receives the final DATA packet again.
The host sending the last DATA must retransmit it until the packet is
acknowledged or the sending host times out. If the response is an
ACK, the transmission was completed successfully. If the sender of
the data times out and is not prepared to retransmit any more, the
transfer may still have been completed successfully, after which the
acknowledger or network may have experienced a problem. It is also
possible in this case that the transfer was unsuccessful. In any
case, the connection has been closed.

My QUESTION IS: Do JSCH follow any RFC related to TFTP, FTP etc? Or would it only follow the SSH RFCs? Also would any RFC for SSH have similar normal termination as described above?

So I am trying to understand if their comment makes any sense or not. I would appreciate any input here.

Cheers!

Flavio

[JSch-users] unsubscribe

From: Bruce C. <bru...@ne...> - 2014-12-10 01:03:30

Attachments: imageb1fe53.JPG




Bruce Chapman
Software Engineer
NEC New Zealand Limited
NEC House, Level 6, 40 Taranaki Street, PO Box 1936, Wellington 6140, New Zealand
T: 043816279  M: 0293816279  F: +6443811110
bru...@ne...<mailto:bru...@ne...>
<http://nz.nec.com/>nz.nec.com<http://nz.nec.com>

[cid:imageb1fe53.JPG@c0831a43.4c8c2ccb]

Please consider the environment before printing this email

Attention:
The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material.  Any review, retransmission, dissemination, copying or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. NEC has no liability for any act or omission in reliance on the email or any attachment.  Before opening this email or any attachment(s), please check them for viruses. NEC is not responsible for any viruses in this email or any attachment(s); any changes made to this  email or any attachment(s) after they are sent; or any effects this email or any attachment(s) have on your network or computer system.

Re: [JSch-users] Concurrency with JSch

From: Bogdan S. <bog...@gm...> - 2014-11-18 08:15:34

Hello, Guillaume!

I had the same issues with JSCH, and still haven't figured out a proper way
to handle the thread safety, besides executing in multiple threads and
using a retry mechanism.

I would also be interested to find a better way, though.

Kind regards,
Bogdan


On Mon, Nov 17, 2014 at 6:22 PM, guillaume cornet <
cor...@gm...> wrote:

> Hi Lahiru !
>
>
> I'm creating many SftpChannel in multiple Session and I'm facing the same
> issue (e.g. 'Packet corrupt' or 'connection is closed by foreign host').
>
> In order to solve this issue, I've introduce an retry mechanism in my
> code, so that a new Session is created an openend when such error are
> detected.
>
> I know it is not the best solution, but it was easier to do this rather
> than modifying JCraft source code to make it thread safe.
>
>
> Does anybody encounter such concurrency issue ?
>
>
>
> G.
>
> 2014-10-07 20:34 GMT+02:00 Lahiru Gunathilake <gl...@gm...>:
>
>> Hi Users,
>>
>> And when I remove the threadpool an still submit a very large load I can
>> see I am getting the following error intermittently,
>>
>> com.jcraft.jsch.JSchException: Packet corrupt
>>
>>
>>         at com.jcraft.jsch.Session.start_discard(Session.java:1049)
>>
>>         at com.jcraft.jsch.Session.read(Session.java:956)
>>
>>         at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:56)
>>
>>         at com.jcraft.jsch.Session.connect(Session.java:389)
>>
>>         at com.jcraft.jsch.Session.connect(Session.java:183)
>>
>>
>> Regards
>>
>> Lahiru
>>
>> On Tue, Oct 7, 2014 at 2:18 PM, Lahiru Gunathilake <gl...@gm...>
>> wrote:
>>
>>> Hi All,
>>>
>>> I have extended the JCraft library to authenticate my servers with a
>>> token and everything works fine when I use in the serial mode. But when I
>>> moved to a thread pool and try to share the JCraftSession and try to create
>>> multiple channels in large number of threads (I have already increased my
>>> maxSessionCount in sshd_config) I get the following error and I am not sure
>>> what is really going on.
>>>
>>> Every 20-30 request I get the below error.
>>>
>>>
>>>  "com.jcraft.jsch.JSchException: channel is not opened."
>>>
>>>
>>> Anybody using the sessions and creating channels concurrently ? I am not
>>> synchronizing the session in each thread ? Should I synchronize the session
>>> object if I am using in multi-threaded mode ?
>>>
>>> Regards
>>> Lahiru
>>>
>>> --
>>> Research Assistant
>>> Science Gateways Group
>>> Indiana University
>>>
>>
>>
>>
>> --
>> Research Assistant
>> Science Gateways Group
>> Indiana University
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> JSch-users mailing list
>> JSc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsch-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users
>
>

Re: [JSch-users] Concurrency with JSch

From: Lahiru G. <gl...@gm...> - 2014-11-17 17:45:37

Hi guillaume,

I was able tohandle it in my code level by synchronizing the code.
Everything works fine, I share sessions but synchronized the methods.

Lahiru

On Mon, Nov 17, 2014 at 11:22 AM, guillaume cornet <
cor...@gm...> wrote:

> Hi Lahiru !
>
>
> I'm creating many SftpChannel in multiple Session and I'm facing the same
> issue (e.g. 'Packet corrupt' or 'connection is closed by foreign host').
>
> In order to solve this issue, I've introduce an retry mechanism in my
> code, so that a new Session is created an openend when such error are
> detected.
>
> I know it is not the best solution, but it was easier to do this rather
> than modifying JCraft source code to make it thread safe.
>
>
> Does anybody encounter such concurrency issue ?
>
>
>
> G.
>
> 2014-10-07 20:34 GMT+02:00 Lahiru Gunathilake <gl...@gm...>:
>
>> Hi Users,
>>
>> And when I remove the threadpool an still submit a very large load I can
>> see I am getting the following error intermittently,
>>
>> com.jcraft.jsch.JSchException: Packet corrupt
>>
>>
>>         at com.jcraft.jsch.Session.start_discard(Session.java:1049)
>>
>>         at com.jcraft.jsch.Session.read(Session.java:956)
>>
>>         at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:56)
>>
>>         at com.jcraft.jsch.Session.connect(Session.java:389)
>>
>>         at com.jcraft.jsch.Session.connect(Session.java:183)
>>
>>
>> Regards
>>
>> Lahiru
>>
>> On Tue, Oct 7, 2014 at 2:18 PM, Lahiru Gunathilake <gl...@gm...>
>> wrote:
>>
>>> Hi All,
>>>
>>> I have extended the JCraft library to authenticate my servers with a
>>> token and everything works fine when I use in the serial mode. But when I
>>> moved to a thread pool and try to share the JCraftSession and try to create
>>> multiple channels in large number of threads (I have already increased my
>>> maxSessionCount in sshd_config) I get the following error and I am not sure
>>> what is really going on.
>>>
>>> Every 20-30 request I get the below error.
>>>
>>>
>>>  "com.jcraft.jsch.JSchException: channel is not opened."
>>>
>>>
>>> Anybody using the sessions and creating channels concurrently ? I am not
>>> synchronizing the session in each thread ? Should I synchronize the session
>>> object if I am using in multi-threaded mode ?
>>>
>>> Regards
>>> Lahiru
>>>
>>> --
>>> Research Assistant
>>> Science Gateways Group
>>> Indiana University
>>>
>>
>>
>>
>> --
>> Research Assistant
>> Science Gateways Group
>> Indiana University
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> JSch-users mailing list
>> JSc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsch-users
>>
>>
>


-- 
Research Assistant
Science Gateways Group
Indiana University

Re: [JSch-users] Concurrency with JSch

From: guillaume c. <cor...@gm...> - 2014-11-17 16:22:26

Hi Lahiru !


I'm creating many SftpChannel in multiple Session and I'm facing the same
issue (e.g. 'Packet corrupt' or 'connection is closed by foreign host').

In order to solve this issue, I've introduce an retry mechanism in my code,
so that a new Session is created an openend when such error are detected.

I know it is not the best solution, but it was easier to do this rather
than modifying JCraft source code to make it thread safe.


Does anybody encounter such concurrency issue ?



G.

2014-10-07 20:34 GMT+02:00 Lahiru Gunathilake <gl...@gm...>:

> Hi Users,
>
> And when I remove the threadpool an still submit a very large load I can
> see I am getting the following error intermittently,
>
> com.jcraft.jsch.JSchException: Packet corrupt
>
>
>         at com.jcraft.jsch.Session.start_discard(Session.java:1049)
>
>         at com.jcraft.jsch.Session.read(Session.java:956)
>
>         at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:56)
>
>         at com.jcraft.jsch.Session.connect(Session.java:389)
>
>         at com.jcraft.jsch.Session.connect(Session.java:183)
>
>
> Regards
>
> Lahiru
>
> On Tue, Oct 7, 2014 at 2:18 PM, Lahiru Gunathilake <gl...@gm...>
> wrote:
>
>> Hi All,
>>
>> I have extended the JCraft library to authenticate my servers with a
>> token and everything works fine when I use in the serial mode. But when I
>> moved to a thread pool and try to share the JCraftSession and try to create
>> multiple channels in large number of threads (I have already increased my
>> maxSessionCount in sshd_config) I get the following error and I am not sure
>> what is really going on.
>>
>> Every 20-30 request I get the below error.
>>
>>
>>  "com.jcraft.jsch.JSchException: channel is not opened."
>>
>>
>> Anybody using the sessions and creating channels concurrently ? I am not
>> synchronizing the session in each thread ? Should I synchronize the session
>> object if I am using in multi-threaded mode ?
>>
>> Regards
>> Lahiru
>>
>> --
>> Research Assistant
>> Science Gateways Group
>> Indiana University
>>
>
>
>
> --
> Research Assistant
> Science Gateways Group
> Indiana University
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users
>
>

Re: [JSch-users] End of IO Stream Read, no response after SSH_MSG_SERVICE_REQUEST sent

From: Paul J. <pau...@gm...> - 2014-11-06 14:54:22

Hello! I'm using jsch-0.1.51.jar, and have implemented a client in an
Oracle database which works very well from SID A, but not from SID B, with
the exact same code. When trying from SID B it ends with an
"Session.connect: java.io.IOException: End of IO Stream Read" exception.
>From the log:

Host 'sftp.bringdialog.no' is known and mathces the DSA host key
SSH_MSG_NEWKEYS sent
SSH_MSG_NEWKEYS received
SSH_MSG_SERVICE_REQUEST sent
Disconnecting from <server>

As you see, a SSH_MSG_SERVICE_REQUEST is sent, but it does not get any
answer, and it disconnects.... It's no such problems on SID A

The SFTP server is a regular commerial one, and I've no problems to reach
it using Filezilla etc, from several PC's..

Appreciate any help.

- brgds Paul Jorstad

Re: [JSch-users] Using diffie-hellman-group-exchange-sha256

From: Ville S. <suo...@gm...> - 2014-10-28 17:30:52

Got this figured out, Just in case someone else is having the same question:

Session session = null;
Channel channel = null;
ChannelSftp channelSftp = null;

try{
JSch jsch = new JSch();
session = jsch.getSession(SFTPUSER,SFTPHOST,SFTPPORT);
session.setPassword(SFTPPASS);
java.util.Properties config = new java.util.Properties();
config.put("kex",
"diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,
diffie-hellman-group-exchange-sha256");
config.put("StrictHostKeyChecking", "no");
   session.setConfig(config);

On Mon, Oct 27, 2014 at 9:42 AM, Ville Suoranta <suo...@gm...>
wrote:

> Hello,
>
> I have a question about key exchange algorithms:
>
> According to the release notes diffie-hellman-group-exchange-sha256 is
> supported, and looking at the source it looks like this is otherwise in
> place, but it is not added in the kex list in the config.
>
> How should I go about adding  diffie-hellman-group-exchange-sha256 to the
> kex list?
>
> --Ville
>

[JSch-users] Using diffie-hellman-group-exchange-sha256

From: Ville S. <suo...@gm...> - 2014-10-27 15:42:37

Hello,

I have a question about key exchange algorithms:

According to the release notes diffie-hellman-group-exchange-sha256 is
supported, and looking at the source it looks like this is otherwise in
place, but it is not added in the kex list in the config.

How should I go about adding  diffie-hellman-group-exchange-sha256 to the
kex list?

--Ville

Re: [JSch-users] Jsch issue with compression algorithm

From: Baweja, K. <kes...@jp...> - 2014-10-20 04:55:20

Looking at the code in SftpOperations.java in createSession()

        // compression
        if (sftpConfig.getCompression() > 0) {
            LOG.debug("Using compression: {}", sftpConfig.getCompression());
            session.setConfig("compression.s2c", "zl...@op..., zlib, none");
            session.setConfig("compression.c2s", "zl...@op..., zlib, none");
            session.setConfig("compression_level", Integer.toString(sftpConfig.getCompression()));
        }

So, the JSch session is set with "zl...@op..., zlib, none" for "compression.s2c", even though zl...@op... might not be configured on sshd for server to client communication. Could this be causing the behavior I encounter below?

Regards
Keshav


-----Original Message-----
From: Baweja, Keshav 
Sent: Monday, October 20, 2014 12:17 PM
To: us...@ca...; jsc...@li...
Subject: Jsch issue with compression algorithm

Hello All, 

I have been able to narrow down this issue to below - 

1) I enabled client to server compression configuration on Jsch  by setting compression=2 as an option on camel route.
2) With this, Jsch sets client to server compression configuration as -  JSCH -> kex: client: zl...@op..., zlib, none
3) When server is configured as below the sftp connection is successful
  JSCH -> kex: server: none,zl...@op...
4) However, if the server is configured as any of the below the sftp connection is not successful  JSCH -> kex: server: none,zlib  JSCH -> kex: server: zlib

So if zl...@op... is not configured on server, Jsch fails with the exception below

Caused by: com.jcraft.jsch.JSchException: Algorithm negotiation fail
        at com.jcraft.jsch.Session.receive_kexinit(Session.java:583) ~[ftu-server-3.0.3.jar:na]
        at com.jcraft.jsch.Session.connect(Session.java:320) ~[ftu-server-3.0.3.jar:na]
        at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:115) ~[ftu-server-3.0.3.jar:na]

Has someone encountered this? Any ideas to resolve this. Thanks in advance.

Regards
Keshav

-----Original Message-----
From: Baweja, Keshav [mailto:kes...@jp...]
Sent: Friday, October 10, 2014 2:56 PM
To: us...@ca...; jsc...@li...
Subject: RE: JSch connection issue with Maverick SSHD server


Hello 

I am using Camel routing library to set up sftp routes to a remote sftp server. Camel user Jsch library (version 0.1.50) for all sftp operations and jsch-zlib (version 1.1.3) for the compression. However I encounter the exception below with this set up. Could someone advise/point to a resolution? Many thanks in advance.

[2014-10-07 10:37:11.937] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using private keyfile: /home/localuser/.ssh/id_rsa
[2014-10-07 10:37:11.937] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using knownhosts file: /home/localuser/.ssh/known_hosts
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using StrickHostKeyChecking: no
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using compression: 2
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Connecting to host port port
[2014-10-07 10:37:12.150] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Connection established
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Remote version string: SSH-2.0-Maverick_SSHD
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Local version string: SSH-2.0-JSCH-0.1.50
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes256-ctr is not available.
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes192-ctr is not available.
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes256-cbc is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes192-cbc is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> arcfour256 is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> CheckKexes: diffie-hellman-group14-sha1
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> SSH_MSG_KEXINIT sent
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> SSH_MSG_KEXINIT received
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: ssh-rsa
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,blowfish-cbc,cast128-cbc
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,blowfish-cbc,cast128-cbc
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: hmac-sha1,hmac-sha1-96
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: hmac-sha1,hmac-sha1-96
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: zlib
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: zlib
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server:
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server:
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: ssh-rsa,ssh-dss
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: zl...@op..., zlib, none
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: zl...@op..., zlib, none
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client:
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client:
[2014-10-07 10:37:12.311] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Disconnecting from host port port
[2014-10-07 10:37:12.316] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpConsumer - Could not connect to:Endpoint[sftp://user@host:port/data?compression=2&delay=70000&disconnect=false&include=filename_2014-10-06.xml&knownHostsFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fknown_hosts&localWorkDirectory=%2Fexport%2Fhome%2Flocaluser%2FFTU%2Fserver%2Fwork%2F26&noop=true&pollStrategy=%23POLL_STRATEGY_ENDPOINT_16&privateKeyFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fid_rsa&readLock=changed&readLockCheckInterval=5000&readLockTimeout=20000&reconnectDelay=60000&throwExceptionOnConnectFailed=true]. Will try to recover.
org.apache.camel.component.file.GenericFileOperationFailedException: Cannot connect to sftp://user@host:port
        at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:143) ~[ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.connectIfNecessary(RemoteFileConsumer.java:154) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.recoverableConnectIfNecessary(RemoteFileConsumer.java:133) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.prePollCheck(RemoteFileConsumer.java:55) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:106) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:187) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:114) [ftu-server-3.0.2.jar:na]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_05]
        at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [na:1.7.0_05]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [na:1.7.0_05]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_05]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.7.0_05]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [na:1.7.0_05]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [na:1.7.0_05]
        at java.lang.Thread.run(Thread.java:722) [na:1.7.0_05] Caused by: com.jcraft.jsch.JSchException: Algorithm negotiation fail
        at com.jcraft.jsch.Session.receive_kexinit(Session.java:582) ~[ftu-server-3.0.2.jar:na]
        at com.jcraft.jsch.Session.connect(Session.java:320) ~[ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:115) ~[ftu-server-3.0.2.jar:na]
        ... 14 common frames omitted
[2014-10-07 10:37:12.316] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpConsumer - Trying to recover connection to: Endpoint[sftp://user@host:port/data?compression=2&delay=70000&disconnect=false&include=filename_2014-10-06.xml&knownHostsFile=%2Fexport%2Fhome%2Flocaluser%2
F.ssh%2Fknown_hosts&localWorkDirectory=%2Fexport%2Fhome%2Flocaluser%2FFTU%2Fserver%2Fwork%2F26&noop=true&pollStrategy=%23POLL_STRATEGY_ENDPOINT_16&privateKeyFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fid_rsa&readLock=changed&readLockCheckInterval=5000&readLockTimeout=20000&reconnectDelay=60000&throwExceptionOnConnectFailed=true] with a fresh client.


Also debug output from unix sftp command (which connects successfully) is below –

Connecting to host...
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to host [host] port port.
debug1: Connection established.
debug1: identity file /export/home/localuser/.ssh/id_rsa type 1
debug1: identity file /export/home/localuser/.ssh/id_dsa type 2
debug1: Logging to host: host
debug1: Local user: localuser Remote user: user
debug1: Remote protocol version 2.0, remote software version Maverick_SSHD
debug1: no match: Maverick_SSHD
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.6
debug1: use_engine is 'yes'
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-sha1 zlib
debug1: kex: client->server aes128-cbc hmac-sha1 zlib
debug1: Peer sent proposed langtags, ctos:
debug1: Peer sent proposed langtags, stoc:
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 157/320
debug1: bits set: 523/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'host' is known and matches the RSA host key.
debug1: Found key in /export/home/localuser/.ssh/known_hosts:19
debug1: bits set: 528/1024
debug1: ssh_rsa_verify: signature correct
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for 'out' mode
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for 'in' mode
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT

Regards
Keshav

-----Original Message-----
From: Baweja, Keshav
Sent: Tuesday, September 16, 2014 7:07 PM
To: us...@ca...
Subject: RE: JSch connection issue with Maverick SSHD server

Hello 

JSch has configuration parameters to set compression algorithm for client to server and server to client transport. 

compression.c2s
    Compression algorithms for client-to-server transport. The default is "none", but this library also supports "zlib" and "zl...@op...". (Other compression algorithms can't be put in, it seems.)

compression.s2c
    Compression algorithms for server-to-client transport. The default is "none", but this library also supports "zlib" and "zl...@op...". (Other compression algorithms can't be put in, it seems.)

Is it possible to set this configuration parameter in Options part of Camel URI? 

The only Option I could see on Camel's FTP2 page is below - compression | Default Value = 0 | SFTP Only: Camel 2.8.3/2.9: To use compression. Specify a level from 1 to 10. Important: You must manually add the needed JSCH zlib JAR to the classpath for compression support.


Does setting this Camel option (with JSch zlib on classpath) automatically sets both these configuration parameters.



Regards
Keshav


-----Original Message-----
From: Baweja, Keshav [mailto:kes...@jp...]
Sent: Monday, September 15, 2014 2:30 PM
To: us...@ca...
Subject: RE: JSch connection issue with Maverick SSHD server

Thanks for your reply Nodet, 

The sftp server is hosted externally and is outside our infrastructure. I can't make any changes to the server, and need to make client work with the server configuration.  Would you know how I can do it, found the below on Camel's ftp2 page and guess need to look at this - 

compression | Default Value = 0 | SFTP Only: Camel 2.8.3/2.9: To use compression. Specify a level from 1 to 10. Important: You must manually add the needed JSCH zlib JAR to the classpath for compression support.

Regards
Keshav


-----Original Message-----
From: Guillaume Nodet [mailto:gn...@ap...]
Sent: Monday, September 15, 2014 2:15 PM
To: us...@ca...
Subject: Re: JSch connection issue with Maverick SSHD server

Your server is configured with "zlib" compression only, while the client only supports compression "none", so there's a mismatch and both can't talk to each other.  You need to configure the server with both "zlib" *and* "none" compression factories.

2014-09-15 7:39 GMT+02:00 Baweja, Keshav <kes...@jp...
>:

> Hello
>
> I am using Camel 2.13.2 in my application to build up routes to 
> download files from sftp server locations. The codebase has been 
> tested ok against 5 different sftp servers. However against one 
> particular sftp server, JSch the sftp implementation used  by Camel 
> seems to disconnect immediately after connecting. Could you please 
> advise what could be the issue here. The log from application is as 
> below -
>
> [2014-09-15 05:52:32.236] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using private
> keyfile: /home/.ssh/id_rsa
> [2014-09-15 05:52:32.238] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using 
> knownhosts file: /home/.ssh/known_hosts
> [2014-09-15 05:52:32.329] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using
> StrickHostKeyChecking: no
> [2014-09-15 05:52:32.329] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Connecting to hostname port port
> [2014-09-15 05:52:32.462] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Connection established
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> Remote 
> version string: SSH-2.0-Maverick_SSHD
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> Local 
> version string: SSH-2.0-JSCH-0.1.50
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH ->
> CheckCiphers:
> aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des
> -ctr,arcfour,arcfour128,arcfour256
> [2014-09-15 05:52:32.598] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH ->
> CheckKexes: diffie-hellman-group14-sha1
> [2014-09-15 05:52:32.621] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> SSH_MSG_KEXINIT sent
> [2014-09-15 05:52:32.621] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> SSH_MSG_KEXINIT received
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: ssh-rsa
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cb
> c,twofish128-cbc,blowfish-cbc,cast128-cbc
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cb
> c,twofish128-cbc,blowfish-cbc,cast128-cbc
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: hmac-sha1,hmac-sha1-96
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: hmac-sha1,hmac-sha1-96
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: zlib
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: zlib
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-
> group-exchange-sha1
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: ssh-rsa,ssh-dss
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256
> -cbc
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256
> -cbc
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: none
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: none
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Disconnecting from hostname port port
>
> Regards
> Keshav
>
>
>
> Regards
> Keshav
>
>
>
> This email is confidential and subject to important disclaimers and 
> conditions including on offers for the purchase or sale of securities, 
> accuracy and completeness of information, viruses, confidentiality, 
> legal privilege, and legal entity disclaimers, available at 
> http://www.jpmorgan.com/pages/disclosures/email.
>

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

[JSch-users] Jsch issue with compression algorithm

From: Baweja, K. <kes...@jp...> - 2014-10-20 04:17:39

Hello All, 

I have been able to narrow down this issue to below - 

1) I enabled client to server compression configuration on Jsch  by setting compression=2 as an option on camel route.
2) With this, Jsch sets client to server compression configuration as -  JSCH -> kex: client: zl...@op..., zlib, none
3) When server is configured as below the sftp connection is successful
  JSCH -> kex: server: none,zl...@op...
4) However, if the server is configured as any of the below the sftp connection is not successful
 JSCH -> kex: server: none,zlib
 JSCH -> kex: server: zlib

So if zl...@op... is not configured on server, Jsch fails with the exception below

Caused by: com.jcraft.jsch.JSchException: Algorithm negotiation fail
        at com.jcraft.jsch.Session.receive_kexinit(Session.java:583) ~[ftu-server-3.0.3.jar:na]
        at com.jcraft.jsch.Session.connect(Session.java:320) ~[ftu-server-3.0.3.jar:na]
        at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:115) ~[ftu-server-3.0.3.jar:na]

Has someone encountered this? Any ideas to resolve this. Thanks in advance.

Regards
Keshav

-----Original Message-----
From: Baweja, Keshav [mailto:kes...@jp...] 
Sent: Friday, October 10, 2014 2:56 PM
To: us...@ca...; jsc...@li...
Subject: RE: JSch connection issue with Maverick SSHD server


Hello 

I am using Camel routing library to set up sftp routes to a remote sftp server. Camel user Jsch library (version 0.1.50) for all sftp operations and jsch-zlib (version 1.1.3) for the compression. However I encounter the exception below with this set up. Could someone advise/point to a resolution? Many thanks in advance.

[2014-10-07 10:37:11.937] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using private keyfile: /home/localuser/.ssh/id_rsa
[2014-10-07 10:37:11.937] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using knownhosts file: /home/localuser/.ssh/known_hosts
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using StrickHostKeyChecking: no
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using compression: 2
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Connecting to host port port
[2014-10-07 10:37:12.150] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Connection established
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Remote version string: SSH-2.0-Maverick_SSHD
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Local version string: SSH-2.0-JSCH-0.1.50
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes256-ctr is not available.
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes192-ctr is not available.
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes256-cbc is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes192-cbc is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> arcfour256 is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> CheckKexes: diffie-hellman-group14-sha1
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> SSH_MSG_KEXINIT sent
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> SSH_MSG_KEXINIT received
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: ssh-rsa
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,blowfish-cbc,cast128-cbc
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,blowfish-cbc,cast128-cbc
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: hmac-sha1,hmac-sha1-96
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: hmac-sha1,hmac-sha1-96
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: zlib
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: zlib
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server:
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server:
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: ssh-rsa,ssh-dss
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: zl...@op..., zlib, none
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: zl...@op..., zlib, none
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client:
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client:
[2014-10-07 10:37:12.311] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Disconnecting from host port port
[2014-10-07 10:37:12.316] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpConsumer - Could not connect to:Endpoint[sftp://user@host:port/data?compression=2&delay=70000&disconnect=false&include=filename_2014-10-06.xml&knownHostsFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fknown_hosts&localWorkDirectory=%2Fexport%2Fhome%2Flocaluser%2FFTU%2Fserver%2Fwork%2F26&noop=true&pollStrategy=%23POLL_STRATEGY_ENDPOINT_16&privateKeyFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fid_rsa&readLock=changed&readLockCheckInterval=5000&readLockTimeout=20000&reconnectDelay=60000&throwExceptionOnConnectFailed=true]. Will try to recover.
org.apache.camel.component.file.GenericFileOperationFailedException: Cannot connect to sftp://user@host:port
        at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:143) ~[ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.connectIfNecessary(RemoteFileConsumer.java:154) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.recoverableConnectIfNecessary(RemoteFileConsumer.java:133) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.prePollCheck(RemoteFileConsumer.java:55) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:106) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:187) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:114) [ftu-server-3.0.2.jar:na]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_05]
        at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [na:1.7.0_05]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [na:1.7.0_05]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_05]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.7.0_05]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [na:1.7.0_05]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [na:1.7.0_05]
        at java.lang.Thread.run(Thread.java:722) [na:1.7.0_05] Caused by: com.jcraft.jsch.JSchException: Algorithm negotiation fail
        at com.jcraft.jsch.Session.receive_kexinit(Session.java:582) ~[ftu-server-3.0.2.jar:na]
        at com.jcraft.jsch.Session.connect(Session.java:320) ~[ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:115) ~[ftu-server-3.0.2.jar:na]
        ... 14 common frames omitted
[2014-10-07 10:37:12.316] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpConsumer - Trying to recover connection to: Endpoint[sftp://user@host:port/data?compression=2&delay=70000&disconnect=false&include=filename_2014-10-06.xml&knownHostsFile=%2Fexport%2Fhome%2Flocaluser%2
F.ssh%2Fknown_hosts&localWorkDirectory=%2Fexport%2Fhome%2Flocaluser%2FFTU%2Fserver%2Fwork%2F26&noop=true&pollStrategy=%23POLL_STRATEGY_ENDPOINT_16&privateKeyFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fid_rsa&readLock=changed&readLockCheckInterval=5000&readLockTimeout=20000&reconnectDelay=60000&throwExceptionOnConnectFailed=true] with a fresh client.


Also debug output from unix sftp command (which connects successfully) is below –

Connecting to host...
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to host [host] port port.
debug1: Connection established.
debug1: identity file /export/home/localuser/.ssh/id_rsa type 1
debug1: identity file /export/home/localuser/.ssh/id_dsa type 2
debug1: Logging to host: host
debug1: Local user: localuser Remote user: user
debug1: Remote protocol version 2.0, remote software version Maverick_SSHD
debug1: no match: Maverick_SSHD
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.6
debug1: use_engine is 'yes'
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-sha1 zlib
debug1: kex: client->server aes128-cbc hmac-sha1 zlib
debug1: Peer sent proposed langtags, ctos:
debug1: Peer sent proposed langtags, stoc:
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 157/320
debug1: bits set: 523/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'host' is known and matches the RSA host key.
debug1: Found key in /export/home/localuser/.ssh/known_hosts:19
debug1: bits set: 528/1024
debug1: ssh_rsa_verify: signature correct
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for 'out' mode
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for 'in' mode
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT

Regards
Keshav

-----Original Message-----
From: Baweja, Keshav
Sent: Tuesday, September 16, 2014 7:07 PM
To: us...@ca...
Subject: RE: JSch connection issue with Maverick SSHD server

Hello 

JSch has configuration parameters to set compression algorithm for client to server and server to client transport. 

compression.c2s
    Compression algorithms for client-to-server transport. The default is "none", but this library also supports "zlib" and "zl...@op...". (Other compression algorithms can't be put in, it seems.)

compression.s2c
    Compression algorithms for server-to-client transport. The default is "none", but this library also supports "zlib" and "zl...@op...". (Other compression algorithms can't be put in, it seems.)

Is it possible to set this configuration parameter in Options part of Camel URI? 

The only Option I could see on Camel's FTP2 page is below - compression | Default Value = 0 | SFTP Only: Camel 2.8.3/2.9: To use compression. Specify a level from 1 to 10. Important: You must manually add the needed JSCH zlib JAR to the classpath for compression support.


Does setting this Camel option (with JSch zlib on classpath) automatically sets both these configuration parameters.



Regards
Keshav


-----Original Message-----
From: Baweja, Keshav [mailto:kes...@jp...]
Sent: Monday, September 15, 2014 2:30 PM
To: us...@ca...
Subject: RE: JSch connection issue with Maverick SSHD server

Thanks for your reply Nodet, 

The sftp server is hosted externally and is outside our infrastructure. I can't make any changes to the server, and need to make client work with the server configuration.  Would you know how I can do it, found the below on Camel's ftp2 page and guess need to look at this - 

compression | Default Value = 0 | SFTP Only: Camel 2.8.3/2.9: To use compression. Specify a level from 1 to 10. Important: You must manually add the needed JSCH zlib JAR to the classpath for compression support.

Regards
Keshav


-----Original Message-----
From: Guillaume Nodet [mailto:gn...@ap...]
Sent: Monday, September 15, 2014 2:15 PM
To: us...@ca...
Subject: Re: JSch connection issue with Maverick SSHD server

Your server is configured with "zlib" compression only, while the client only supports compression "none", so there's a mismatch and both can't talk to each other.  You need to configure the server with both "zlib" *and* "none" compression factories.

2014-09-15 7:39 GMT+02:00 Baweja, Keshav <kes...@jp...
>:

> Hello
>
> I am using Camel 2.13.2 in my application to build up routes to 
> download files from sftp server locations. The codebase has been 
> tested ok against 5 different sftp servers. However against one 
> particular sftp server, JSch the sftp implementation used  by Camel 
> seems to disconnect immediately after connecting. Could you please 
> advise what could be the issue here. The log from application is as 
> below -
>
> [2014-09-15 05:52:32.236] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using private
> keyfile: /home/.ssh/id_rsa
> [2014-09-15 05:52:32.238] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using 
> knownhosts file: /home/.ssh/known_hosts
> [2014-09-15 05:52:32.329] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using
> StrickHostKeyChecking: no
> [2014-09-15 05:52:32.329] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Connecting to hostname port port
> [2014-09-15 05:52:32.462] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Connection established
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> Remote 
> version string: SSH-2.0-Maverick_SSHD
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> Local 
> version string: SSH-2.0-JSCH-0.1.50
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH ->
> CheckCiphers:
> aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des
> -ctr,arcfour,arcfour128,arcfour256
> [2014-09-15 05:52:32.598] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH ->
> CheckKexes: diffie-hellman-group14-sha1
> [2014-09-15 05:52:32.621] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> SSH_MSG_KEXINIT sent
> [2014-09-15 05:52:32.621] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> SSH_MSG_KEXINIT received
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: ssh-rsa
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cb
> c,twofish128-cbc,blowfish-cbc,cast128-cbc
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cb
> c,twofish128-cbc,blowfish-cbc,cast128-cbc
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: hmac-sha1,hmac-sha1-96
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: hmac-sha1,hmac-sha1-96
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: zlib
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: zlib
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-
> group-exchange-sha1
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: ssh-rsa,ssh-dss
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256
> -cbc
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256
> -cbc
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: none
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: none
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Disconnecting from hostname port port
>
> Regards
> Keshav
>
>
>
> Regards
> Keshav
>
>
>
> This email is confidential and subject to important disclaimers and 
> conditions including on offers for the purchase or sale of securities, 
> accuracy and completeness of information, viruses, confidentiality, 
> legal privilege, and legal entity disclaimers, available at 
> http://www.jpmorgan.com/pages/disclosures/email.
>

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

Re: [JSch-users] JSch connection issue with Maverick SSHD server

From: Baweja, K. <kes...@jp...> - 2014-10-10 06:57:28

Hello 

I am using Camel routing library to set up sftp routes to a remote sftp server. Camel user Jsch library (version 0.1.50) for all sftp operations and jsch-zlib (version 1.1.3) for the compression. However I encounter the exception below with this set up. Could someone advise/point to a resolution? Many thanks in advance.

[2014-10-07 10:37:11.937] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using private keyfile: /home/localuser/.ssh/id_rsa
[2014-10-07 10:37:11.937] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using knownhosts file: /home/localuser/.ssh/known_hosts
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using StrickHostKeyChecking: no
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using compression: 2
[2014-10-07 10:37:12.018] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Connecting to host port port
[2014-10-07 10:37:12.150] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Connection established
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Remote version string: SSH-2.0-Maverick_SSHD
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Local version string: SSH-2.0-JSCH-0.1.50
[2014-10-07 10:37:12.279] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes256-ctr is not available.
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes192-ctr is not available.
[2014-10-07 10:37:12.284] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes256-cbc is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> aes192-cbc is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> arcfour256 is not available.
[2014-10-07 10:37:12.285] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> CheckKexes: diffie-hellman-group14-sha1
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> SSH_MSG_KEXINIT sent
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> SSH_MSG_KEXINIT received
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: ssh-rsa
[2014-10-07 10:37:12.308] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,blowfish-cbc,cast128-cbc
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,blowfish-cbc,cast128-cbc
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: hmac-sha1,hmac-sha1-96
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: hmac-sha1,hmac-sha1-96
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: zlib
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server: zlib
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server:
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: server:
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: ssh-rsa,ssh-dss
[2014-10-07 10:37:12.309] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: zl...@op..., zlib, none
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: zl...@op..., zlib, none
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client:
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client:
[2014-10-07 10:37:12.311] [Camel (camel-1) thread #0 - sftp://user@host:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> Disconnecting from host port port
[2014-10-07 10:37:12.316] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpConsumer - Could not connect to:Endpoint[sftp://user@host:port/data?compression=2&delay=70000&disconnect=false&include=filename_2014-10-06.xml&knownHostsFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fknown_hosts&localWorkDirectory=%2Fexport%2Fhome%2Flocaluser%2FFTU%2Fserver%2Fwork%2F26&noop=true&pollStrategy=%23POLL_STRATEGY_ENDPOINT_16&privateKeyFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fid_rsa&readLock=changed&readLockCheckInterval=5000&readLockTimeout=20000&reconnectDelay=60000&throwExceptionOnConnectFailed=true]. Will try to recover.
org.apache.camel.component.file.GenericFileOperationFailedException: Cannot connect to sftp://user@host:port
        at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:143) ~[ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.connectIfNecessary(RemoteFileConsumer.java:154) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.recoverableConnectIfNecessary(RemoteFileConsumer.java:133) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.RemoteFileConsumer.prePollCheck(RemoteFileConsumer.java:55) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:106) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:187) [ftu-server-3.0.2.jar:na]
        at org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:114) [ftu-server-3.0.2.jar:na]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_05]
        at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [na:1.7.0_05]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [na:1.7.0_05]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_05]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.7.0_05]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [na:1.7.0_05]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [na:1.7.0_05]
        at java.lang.Thread.run(Thread.java:722) [na:1.7.0_05]
Caused by: com.jcraft.jsch.JSchException: Algorithm negotiation fail
        at com.jcraft.jsch.Session.receive_kexinit(Session.java:582) ~[ftu-server-3.0.2.jar:na]
        at com.jcraft.jsch.Session.connect(Session.java:320) ~[ftu-server-3.0.2.jar:na]
        at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:115) ~[ftu-server-3.0.2.jar:na]
        ... 14 common frames omitted
[2014-10-07 10:37:12.316] [Camel (camel-1) thread #0 - sftp://user@host:port/data] DEBUG org.apache.camel.component.file.remote.SftpConsumer - Trying to recover connection to: Endpoint[sftp://user@host:port/data?compression=2&delay=70000&disconnect=false&include=filename_2014-10-06.xml&knownHostsFile=%2Fexport%2Fhome%2Flocaluser%2
F.ssh%2Fknown_hosts&localWorkDirectory=%2Fexport%2Fhome%2Flocaluser%2FFTU%2Fserver%2Fwork%2F26&noop=true&pollStrategy=%23POLL_STRATEGY_ENDPOINT_16&privateKeyFile=%2Fexport%2Fhome%2Flocaluser%2F.ssh%2Fid_rsa&readLock=changed&readLockCheckInterval=5000&readLockTimeout=20000&reconnectDelay=60000&throwExceptionOnConnectFailed=true] with a fresh client.


Also debug output from unix sftp command (which connects successfully) is below –

Connecting to host...
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to host [host] port port.
debug1: Connection established.
debug1: identity file /export/home/localuser/.ssh/id_rsa type 1
debug1: identity file /export/home/localuser/.ssh/id_dsa type 2
debug1: Logging to host: host
debug1: Local user: localuser Remote user: user
debug1: Remote protocol version 2.0, remote software version Maverick_SSHD
debug1: no match: Maverick_SSHD
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.6
debug1: use_engine is 'yes'
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-sha1 zlib
debug1: kex: client->server aes128-cbc hmac-sha1 zlib
debug1: Peer sent proposed langtags, ctos:
debug1: Peer sent proposed langtags, stoc:
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 157/320
debug1: bits set: 523/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'host' is known and matches the RSA host key.
debug1: Found key in /export/home/localuser/.ssh/known_hosts:19
debug1: bits set: 528/1024
debug1: ssh_rsa_verify: signature correct
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for 'out' mode
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for 'in' mode
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT

Regards
Keshav

-----Original Message-----
From: Baweja, Keshav 
Sent: Tuesday, September 16, 2014 7:07 PM
To: us...@ca...
Subject: RE: JSch connection issue with Maverick SSHD server

Hello 

JSch has configuration parameters to set compression algorithm for client to server and server to client transport. 

compression.c2s
    Compression algorithms for client-to-server transport. The default is "none", but this library also supports "zlib" and "zl...@op...". (Other compression algorithms can't be put in, it seems.)

compression.s2c
    Compression algorithms for server-to-client transport. The default is "none", but this library also supports "zlib" and "zl...@op...". (Other compression algorithms can't be put in, it seems.)

Is it possible to set this configuration parameter in Options part of Camel URI? 

The only Option I could see on Camel's FTP2 page is below - compression | Default Value = 0 | SFTP Only: Camel 2.8.3/2.9: To use compression. Specify a level from 1 to 10. Important: You must manually add the needed JSCH zlib JAR to the classpath for compression support.


Does setting this Camel option (with JSch zlib on classpath) automatically sets both these configuration parameters.



Regards
Keshav


-----Original Message-----
From: Baweja, Keshav [mailto:kes...@jp...] 
Sent: Monday, September 15, 2014 2:30 PM
To: us...@ca...
Subject: RE: JSch connection issue with Maverick SSHD server

Thanks for your reply Nodet, 

The sftp server is hosted externally and is outside our infrastructure. I can't make any changes to the server, and need to make client work with the server configuration.  Would you know how I can do it, found the below on Camel's ftp2 page and guess need to look at this - 

compression | Default Value = 0 | SFTP Only: Camel 2.8.3/2.9: To use compression. Specify a level from 1 to 10. Important: You must manually add the needed JSCH zlib JAR to the classpath for compression support.

Regards
Keshav


-----Original Message-----
From: Guillaume Nodet [mailto:gn...@ap...]
Sent: Monday, September 15, 2014 2:15 PM
To: us...@ca...
Subject: Re: JSch connection issue with Maverick SSHD server

Your server is configured with "zlib" compression only, while the client only supports compression "none", so there's a mismatch and both can't talk to each other.  You need to configure the server with both "zlib" *and* "none" compression factories.

2014-09-15 7:39 GMT+02:00 Baweja, Keshav <kes...@jp...
>:

> Hello
>
> I am using Camel 2.13.2 in my application to build up routes to 
> download files from sftp server locations. The codebase has been 
> tested ok against 5 different sftp servers. However against one 
> particular sftp server, JSch the sftp implementation used  by Camel 
> seems to disconnect immediately after connecting. Could you please 
> advise what could be the issue here. The log from application is as 
> below -
>
> [2014-09-15 05:52:32.236] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using private
> keyfile: /home/.ssh/id_rsa
> [2014-09-15 05:52:32.238] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using 
> knownhosts file: /home/.ssh/known_hosts
> [2014-09-15 05:52:32.329] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] DEBUG 
> org.apache.camel.component.file.remote.SftpOperations - Using
> StrickHostKeyChecking: no
> [2014-09-15 05:52:32.329] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Connecting to hostname port port
> [2014-09-15 05:52:32.462] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Connection established
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> Remote 
> version string: SSH-2.0-Maverick_SSHD
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> Local 
> version string: SSH-2.0-JSCH-0.1.50
> [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH ->
> CheckCiphers:
> aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des
> -ctr,arcfour,arcfour128,arcfour256
> [2014-09-15 05:52:32.598] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH ->
> CheckKexes: diffie-hellman-group14-sha1
> [2014-09-15 05:52:32.621] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> SSH_MSG_KEXINIT sent
> [2014-09-15 05:52:32.621] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> SSH_MSG_KEXINIT received
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: ssh-rsa
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cb
> c,twofish128-cbc,blowfish-cbc,cast128-cbc
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cb
> c,twofish128-cbc,blowfish-cbc,cast128-cbc
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: hmac-sha1,hmac-sha1-96
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: hmac-sha1,hmac-sha1-96
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: zlib
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server: zlib
> [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> server:
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-
> group-exchange-sha1
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: ssh-rsa,ssh-dss
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256
> -cbc
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes256
> -cbc
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: none
> [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client: none
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO  org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex:
> client:
> [2014-09-15 05:52:32.624] [Camel (camel-1) thread #0 - 
> sftp://user@hostname:port/data] INFO 
> org.apache.camel.component.file.remote.SftpOperations - JSCH -> 
> Disconnecting from hostname port port
>
> Regards
> Keshav
>
>
>
> Regards
> Keshav
>
>
>
> This email is confidential and subject to important disclaimers and 
> conditions including on offers for the purchase or sale of securities, 
> accuracy and completeness of information, viruses, confidentiality, 
> legal privilege, and legal entity disclaimers, available at 
> http://www.jpmorgan.com/pages/disclosures/email.
>

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

Re: [JSch-users] Concurrency with JSch

From: Lahiru G. <gl...@gm...> - 2014-10-07 18:35:01

Hi Users,

And when I remove the threadpool an still submit a very large load I can
see I am getting the following error intermittently,

com.jcraft.jsch.JSchException: Packet corrupt


        at com.jcraft.jsch.Session.start_discard(Session.java:1049)

        at com.jcraft.jsch.Session.read(Session.java:956)

        at com.jcraft.jsch.UserAuthNone.start(UserAuthNone.java:56)

        at com.jcraft.jsch.Session.connect(Session.java:389)

        at com.jcraft.jsch.Session.connect(Session.java:183)


Regards

Lahiru

On Tue, Oct 7, 2014 at 2:18 PM, Lahiru Gunathilake <gl...@gm...>
wrote:

> Hi All,
>
> I have extended the JCraft library to authenticate my servers with a token
> and everything works fine when I use in the serial mode. But when I moved
> to a thread pool and try to share the JCraftSession and try to create
> multiple channels in large number of threads (I have already increased my
> maxSessionCount in sshd_config) I get the following error and I am not sure
> what is really going on.
>
> Every 20-30 request I get the below error.
>
>
>  "com.jcraft.jsch.JSchException: channel is not opened."
>
>
> Anybody using the sessions and creating channels concurrently ? I am not
> synchronizing the session in each thread ? Should I synchronize the session
> object if I am using in multi-threaded mode ?
>
> Regards
> Lahiru
>
> --
> Research Assistant
> Science Gateways Group
> Indiana University
>



-- 
Research Assistant
Science Gateways Group
Indiana University

[JSch-users] Concurrency with JSch

From: Lahiru G. <gl...@gm...> - 2014-10-07 18:18:31

Hi All,

I have extended the JCraft library to authenticate my servers with a token
and everything works fine when I use in the serial mode. But when I moved
to a thread pool and try to share the JCraftSession and try to create
multiple channels in large number of threads (I have already increased my
maxSessionCount in sshd_config) I get the following error and I am not sure
what is really going on.

Every 20-30 request I get the below error.


 "com.jcraft.jsch.JSchException: channel is not opened."


Anybody using the sessions and creating channels concurrently ? I am not
synchronizing the session in each thread ? Should I synchronize the session
object if I am using in multi-threaded mode ?

Regards
Lahiru

-- 
Research Assistant
Science Gateways Group
Indiana University

[JSch-users] FIPS Validation

From: Gerry R. <gr...@ve...> - 2014-10-06 22:04:41

I have some applications where I am utilizing JSch library.

I have been asked about whether the crypto library we are using (JSch) is FIPS Validated.


Does JSch produce a FIPS Validated version of the JSch crypto library?  Similar to the

FIPS version of the openssl library?  If not, I think this is something that JSch should offer.


FIPS Validation is necessary for nearly all government agencies in the U.S. and Canada

The current standard is FIPS 140-2:  http://csrc.nist.gov/groups/STM/cmvp/standards.html#02

Re: [JSch-users] Ant won't work.

From: Antoine L. L. <an...@gm...> - 2014-10-03 02:15:34

You said that you are runnning Ant via the Eclipse IDE integration.
I think you need to tell Eclipse about the extra jsch.jar, maybe by creating a “custom Ant” setup.

I am not using Eclipse Ant IDE integration myself but I remember having created “custom Ant” setups, which mention each jar one wants on the class path.

Hope this helps,

Antoine

On Oct 2, 2014, at 7:12 PM, Donald Paul Winston <sat...@ya...> wrote:

> Eclipse Java EE IDE for Web Developers.
> 
> Version: Luna Release (4.4.0)
> Build id: 20140612-0600
> 
> 
> 
> BUILD FAILED
> /Users/satchwinston/Documents/workspace-jee/TIP/build.xml:11: Problem: failed to create task or type scp
> Cause: Could not load a dependent class com/jcraft/jsch/Logger
>        It is not enough to have Ant's optional JARs
>        you need the JAR files that the optional tasks depend upon.
>        Ant's optional task dependencies are listed in the manual.
> Action: Determine what extra JAR files are needed, and place them in one of:
>         -/Users/satchwinston/Desktop/eclipse jee/plugins/org.apache.ant_1.9.2.v201404171502/lib
> 
> Iput the jsch.jar in -/Users/satchwinston/Desktop/eclipse jee/plugins/org.apache.ant_1.9.2.v201404171502/lib
> 
> What do I do? 
> Donald Paul Winston
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users

[JSch-users] Ant won't work.

From: Donald P. W. <sat...@ya...> - 2014-10-02 23:13:02

Eclipse Java EE IDE for Web Developers.

Version: Luna Release (4.4.0)
Build id: 20140612-0600



BUILD FAILED
/Users/satchwinston/Documents/workspace-jee/TIP/build.xml:11: Problem: failed to create task or type scp
Cause: Could not load a dependent class com/jcraft/jsch/Logger
       It is not enough to have Ant's optional JARs
       you need the JAR files that the optional tasks depend upon.
       Ant's optional task dependencies are listed in the manual.
Action: Determine what extra JAR files are needed, and place them in one of:
        -/Users/satchwinston/Desktop/eclipse jee/plugins/org.apache.ant_1.9.2.v201404171502/lib

Iput the jsch.jar in -/Users/satchwinston/Desktop/eclipse jee/plugins/org.apache.ant_1.9.2.v201404171502/lib

What do I do? 
Donald Paul Winston

[JSch-users] (no subject)

From: Rayane C. <cha...@ya...> - 2014-09-23 23:28:10

Hi,
I noticed that when you call this method in JSch class:
  publicvoidaddIdentity(String name, byte[]prvkey, byte[]pubkey, byte[] passphrase) throwsJSchException
The method returns with the parameter prvkeyno longer to it's orignal value. Which makes it difficult to call this method many times (in case the credentials do not change and you wish to redo a connection) with the same prvKey since it is modified after the first call.

 
But if inside IdentityFileclass, in (privateIdentityFile(String name, byte[] prvkey, byte[] pubkey, JSch jsch) throwsJSchException), instead of doing :
byte[] buf=prvkey; (this does not prevent from modifying inside the method, the original passed parameter)
you do a :
byte[] buf = new byte[prvkey.length];
System.arraycopy(prvkey, 0, buf, 0, prvkey.length);You’ll operate on a copy, and the original remains intact at the end of the method.

What I do now is calling the addIdentity by giving it a copy of my private key prvkey ( a copy by System.arraycopy, before calling the method).
Hoping I've been clear.
Regards,

Re: [JSch-users] Jsch stopped working with Java8

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/

Re: [JSch-users] Jsch stopped working with Java8

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/

Re: [JSch-users] Jsch stopped working with Java8

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/
>

85 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 .. 6 7 8 9 10 .. 154 > >> (Page 8 of 154)