Karbas, Reinhard | 7 Jan 18:03 2015

Jsch key exchange protocols

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:

* curve25519-sha256@...
* 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

------------------------------------------------------------------------------
(Continue reading)

sodiska saw | 18 Dec 12:33 2014
Picon

PassPhrase for privateKey fail

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
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users
Flavio Orfano | 12 Dec 01:49 2014
Picon

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


------------------------------------------------------------------------------
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
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users
Paul Jorstad | 6 Nov 15:54 2014
Picon

Re: End of IO Stream Read, no response after SSH_MSG_SERVICE_REQUEST sent

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
------------------------------------------------------------------------------
_______________________________________________
JSch-users mailing list
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users
Ville Suoranta | 27 Oct 16:42 2014
Picon

Using diffie-hellman-group-exchange-sha256

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 mailing list
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users
Baweja, Keshav | 20 Oct 06:16 2014
Picon

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:
zlib <at> openssh.com, zlib, none
3) When server is configured as below the sftp connection is successful
  JSCH -> kex: server: none,zlib <at> openssh.com
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 zlib <at> openssh.com 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:keshav.baweja <at> jpmorgan.com.INVALID] 
Sent: Friday, October 10, 2014 2:56 PM
To: users <at> camel.apache.org; jsch-users <at> lists.sourceforge.net
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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> host:port/data] INFO 
org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: zlib <at> openssh.com,
zlib, none
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user <at> host:port/data] INFO 
org.apache.camel.component.file.remote.SftpOperations - JSCH -> kex: client: zlib <at> openssh.com,
zlib, none
[2014-10-07 10:37:12.310] [Camel (camel-1) thread #0 - sftp://user <at> 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 <at> 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 <at> 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 <at> host:port/data] DEBUG
org.apache.camel.component.file.remote.SftpConsumer - Could not connect
to:Endpoint[sftp://user <at> 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 <at> 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 <at> host:port/data] DEBUG
org.apache.camel.component.file.remote.SftpConsumer - Trying to recover connection to:
Endpoint[sftp://user <at> 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: users <at> camel.apache.org
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 "zlib <at> openssh.com". (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 "zlib <at> openssh.com". (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:keshav.baweja <at> jpmorgan.com.INVALID]
Sent: Monday, September 15, 2014 2:30 PM
To: users <at> camel.apache.org
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:gnodet <at> apache.org]
Sent: Monday, September 15, 2014 2:15 PM
To: users <at> camel.apache.org
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 <keshav.baweja <at> jpmorgan.com.invalid
>:

> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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 <at> 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.  
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
JSch-users mailing list
JSch-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jsch-users
Donald Paul Winston | 3 Oct 01:12 2014
Picon

Ant won't work.

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
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users
Rayane Chandar | 24 Sep 01:28 2014
Picon

(no subject)

Hi,
I noticed that when you call this method in JSch class:
  public void addIdentity(String name, byte[]prvkey, byte[]pubkey, byte[] passphrase) throws JSchException
The method returns with the parameter prvkey no 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 IdentityFile class, in (private IdentityFile(String name, byte[] prvkey, byte[] pubkey, JSch jsch) throws JSchException), 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,
------------------------------------------------------------------------------
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
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users
Nick | 11 Sep 13:04 2014
Picon

Jsch stopped working with Java8

Hello,

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?

Also the following test passes fine without any exception:
> Try the following program
>
> import javax.crypto.Cipher;
> import javax.crypto.spec.IvParameterSpec;
> import javax.crypto.spec.SecretKeySpec;
>
> public class CheckCrypto {
>      public static void main(String[] args){
>          String cryptoAlg = "AES";
>          try{
>              SecretKeySpec keyspec = new SecretKeySpec(new byte[32], cryptoAlg);
>              Cipher c = Cipher.getInstance(cryptoAlg + "/CBC/NoPadding");
>              c.init(Cipher.ENCRYPT_MODE, keyspec, new IvParameterSpec(new byte[16]));
>          }
>          catch(Exception e){
>              System.err.println("************ The Java Virtual Machine can't handle strong
cryptography.\n************ This will lead to problems with some services and subsystems!");
>          }
>
>      }
> }
>
> If you get the exception-message, you still need to install the
> unlimimted strength cryptography policy files.
>
>
> Cheers, Lothar

-----
Sincerely,
Nick
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
aes256-cbc is not available.
aes192-cbc is not available.
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-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
kex: client: ssh-rsa,ssh-dss
kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-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:
kex: server->client aes128-cbc hmac-md5 none
kex: client->server aes128-cbc hmac-md5 none
SSH_MSG_KEXDH_INIT sent
expecting SSH_MSG_KEXDH_REPLY
Caused by: com.jcraft.jsch.JSchException: Session.connect: java.security.InvalidKeyException:
Key is too long for this algorithm
        at com.jcraft.jsch.Session.connect(Session.java:558)
        at com.jcraft.jsch.Session.connect(Session.java:183)
Connecting to *.*.*.* port 22
Connection established
Remote version string: SSH-2.0-OpenSSH_5.8
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
aes256-cbc is not available.
aes192-cbc is not available.
CheckKexes: diffie-hellman-group14-sha1
SSH_MSG_KEXINIT sent
SSH_MSG_KEXINIT received
kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
kex: server: ssh-rsa,ssh-dss
kex: server: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc <at> lysator.liu.se
kex: server: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc <at> lysator.liu.se
kex: server: hmac-md5,hmac-sha1,umac-64 <at> openssh.com,hmac-ripemd160,hmac-ripemd160 <at> openssh.com,hmac-sha1-96,hmac-md5-96
kex: server: hmac-md5,hmac-sha1,umac-64 <at> openssh.com,hmac-ripemd160,hmac-ripemd160 <at> openssh.com,hmac-sha1-96,hmac-md5-96
kex: server: none,zlib <at> openssh.com
kex: server: none,zlib <at> openssh.com
kex: server:
kex: server:
kex: client: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
kex: client: ssh-rsa,ssh-dss
kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-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:
kex: server->client aes128-ctr hmac-md5 none
kex: client->server aes128-ctr hmac-md5 none
SSH_MSG_KEXDH_INIT sent
expecting SSH_MSG_KEXDH_REPLY
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
JSch-users mailing list
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users
Chathuri Wimalasena | 2 Sep 19:50 2014
Picon

JSch with rssh

Hi Devs, 

Is there a way we can create a session using jsch with a user who has only rssh (http://www.pizzashack.org/rssh/index.shtml) access. (That means, particular user does not have login access to shell. He has restricted access to that host). 

Appreciate your help on this.

Thanks..
Chathuri


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
JSch-users mailing list
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users
Mick Dreeling | 26 Aug 05:29 2014
Picon

SSH Data Transfer Speed

Hi Guys,

I am  aware that the best way to transfer files  is via SCP, but i wanted to know what the limitations of standard SSH transfer are.

When i use JSch to remotely "tail -f" a log file on disk, i get maximum 700 kb/s on a 100 Mb/s connection.

Is the bottleneck with JSch?

Can anyone suggest how i could "tail download" basically at a higher transfer rate?

I realize its a non-standard question, but i am interested from a research point of view.

Thanks

- Mick


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
JSch-users mailing list
JSch-users@...
https://lists.sourceforge.net/lists/listinfo/jsch-users

Gmane