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

[JSch-users] Authentication with password & key

[Răzvan R. <raz...@gm...>]

Hi Jsch community,

I am looking to use both password and key authentication in a single
connect call, so that
the password authentication is used as backup in case the key
authentication fails.

Adding the key with Jsch.addIdentity and password with Session.setUserInfo
does not yield this behaviour. Of course I could call Session.connect
twice, but I am wondering whether Jsch supports this.

Many thanks,
Razvan

Re: [JSch-users] SFTP of large file hangs

[Vikas V. <vvi...@ho...>]

I have also verified that changing  SFTPRekey parameter to "none" on the ProFTPD server configuration fixes the issue. So the issue definitely is that JSCH is unable to handle Rekeying from the SFTP server. Any idea how I can fix this?

Help truly appreciated.


Thanks,

Vikas.

________________________________
From: Vikas Verma <vvi...@ho...>
Sent: Monday, October 10, 2016 12:38:28 PM
To: Alan Ezust
Cc: jsc...@li...
Subject: Re: [JSch-users] SFTP of large file hangs


I just tried java -Xmx4096m -classpath "*" Sftp and it still fails. Looking at the change logs I see that there was a Rekeying issue with ProFTPD server but supposedly it was fixed in version 53. I have already tested with both 53 and 54 but no luck.


Thanks,

Vikas.




________________________________
From: Alan Ezust <ala...@gm...>
Sent: Monday, October 10, 2016 12:09 PM
To: Vikas Verma
Cc: jsc...@li...
Subject: Re: [JSch-users] SFTP of large file hangs


Another guess: investigate what the startup command line options are for java on the system in question.
Is the max heap size limited with an -Xmx option? Or is there a -d32 being passed in?



On Mon, Oct 10, 2016 at 8:26 AM, Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>> wrote:

I was able to reproduce this in our local environment. We were able to setup ProFTPD SFTP server with default settings. After transferring about 2GB of data (using jsch) the transfer stops. I am attaching the ProFTPD logs for reference. Please help.


Thanks,

Vikas.

________________________________
From: Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>>
Sent: Wednesday, October 5, 2016 11:40:47 AM
To: Alan Ezust

Cc: jsc...@li...<mailto:jsc...@li...>
Subject: Re: [JSch-users] SFTP of large file hangs


@Alan --> Yes its running 64 bit.

@Lothar --> The problem is just between Proftpd and JSCH. I am able to transfer huge files (> 4gb) to other SFTP servers from JSCH. And Proftpd works fine with other ssh clients (like the one that comes with linux). I am not sure sure about their (Partner that hosts sftp server) logging. I can reach out and ask. But their support isnt that great.


Thanks,

Vikas.

________________________________
From: Alan Ezust <ala...@gm...<mailto:ala...@gm...>>
Sent: Wednesday, October 5, 2016 11:00:44 AM
To: Vikas Verma
Cc: jsc...@li...<mailto:jsc...@li...>
Subject: Re: [JSch-users] SFTP of large file hangs

Just wondering, is the client running jsch also running a 64 bit version of Java?


On Mon, Oct 3, 2016 at 12:19 PM, Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>> wrote:

Can anyone please help? The SFTP server is proftpd. This looks like an old Rekeying problem between Proftpd and Jsch. I have tried JSCH version 50/51 and 54 with no luck.


Thanks,

Vikas.

________________________________
From: Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>>
Sent: Wednesday, September 14, 2016 11:43:16 AM
To: jsc...@li...<mailto:jsc...@li...>
Subject: SFTP of large file hangs


We are having a strange issue with one of our clients (Client hosts the SFTP server. We are the client using JSCH). When we SFTP a large file to their SFTP server the file stops getting uploaded after exactly 2143990632<tel:2143990632> bytes. The JSCH connection just starts over at that point. I am including the logs. Has anyone seen this behavior before? I can use any other SFTP client with that server and they work.

In the logs you will see that after my custom log prints (3 and 4) it starts putting the file. After sending 2143990632<tel:2143990632> bytes it kind of starts over and the highlighted log shows up. The file at that point does not "grow" in size on the server side.

Help truly appreciated !!

Thanks,
Vikas.


INFO: Connecting to xxx.xxx.xxx.xx port 22
INFO: Connection established
INFO: Remote version string: SSH-2.0-mod_sftp/0.9.7
INFO: Local version string: SSH-2.0-JSCH-0.1.53
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: SSH_MSG_KEXINIT received
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true
WARN: Permanently added 'xxx.xxx.xxx.xx' (RSA) to the list of known hosts.
INFO: SSH_MSG_NEWKEYS sent
INFO: SSH_MSG_NEWKEYS received
INFO: SSH_MSG_SERVICE_REQUEST sent
INFO: SSH_MSG_SERVICE_ACCEPT received
INFO: Authentications that can continue: publickey,keyboard-interactive,password
INFO: Next authentication method: publickey
INFO: Authentications that can continue: password
INFO: Next authentication method: password
INFO: Authentication succeeded (password).
-----------------------------------3
-----------------------------------4
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
JSch-users mailing list
JSc...@li...<mailto:JSc...@li...>
https://lists.sourceforge.net/lists/listinfo/jsch-users

Re: [JSch-users] SFTP of large file hangs

[Vikas V. <vvi...@ho...>]

I just tried java -Xmx4096m -classpath "*" Sftp and it still fails. Looking at the change logs I see that there was a Rekeying issue with ProFTPD server but supposedly it was fixed in version 53. I have already tested with both 53 and 54 but no luck.


Thanks,

Vikas.




________________________________
From: Alan Ezust <ala...@gm...>
Sent: Monday, October 10, 2016 12:09 PM
To: Vikas Verma
Cc: jsc...@li...
Subject: Re: [JSch-users] SFTP of large file hangs


Another guess: investigate what the startup command line options are for java on the system in question.
Is the max heap size limited with an -Xmx option? Or is there a -d32 being passed in?



On Mon, Oct 10, 2016 at 8:26 AM, Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>> wrote:

I was able to reproduce this in our local environment. We were able to setup ProFTPD SFTP server with default settings. After transferring about 2GB of data (using jsch) the transfer stops. I am attaching the ProFTPD logs for reference. Please help.


Thanks,

Vikas.

________________________________
From: Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>>
Sent: Wednesday, October 5, 2016 11:40:47 AM
To: Alan Ezust

Cc: jsc...@li...<mailto:jsc...@li...>
Subject: Re: [JSch-users] SFTP of large file hangs


@Alan --> Yes its running 64 bit.

@Lothar --> The problem is just between Proftpd and JSCH. I am able to transfer huge files (> 4gb) to other SFTP servers from JSCH. And Proftpd works fine with other ssh clients (like the one that comes with linux). I am not sure sure about their (Partner that hosts sftp server) logging. I can reach out and ask. But their support isnt that great.


Thanks,

Vikas.

________________________________
From: Alan Ezust <ala...@gm...<mailto:ala...@gm...>>
Sent: Wednesday, October 5, 2016 11:00:44 AM
To: Vikas Verma
Cc: jsc...@li...<mailto:jsc...@li...>
Subject: Re: [JSch-users] SFTP of large file hangs

Just wondering, is the client running jsch also running a 64 bit version of Java?


On Mon, Oct 3, 2016 at 12:19 PM, Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>> wrote:

Can anyone please help? The SFTP server is proftpd. This looks like an old Rekeying problem between Proftpd and Jsch. I have tried JSCH version 50/51 and 54 with no luck.


Thanks,

Vikas.

________________________________
From: Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>>
Sent: Wednesday, September 14, 2016 11:43:16 AM
To: jsc...@li...<mailto:jsc...@li...>
Subject: SFTP of large file hangs


We are having a strange issue with one of our clients (Client hosts the SFTP server. We are the client using JSCH). When we SFTP a large file to their SFTP server the file stops getting uploaded after exactly 2143990632<tel:2143990632> bytes. The JSCH connection just starts over at that point. I am including the logs. Has anyone seen this behavior before? I can use any other SFTP client with that server and they work.

In the logs you will see that after my custom log prints (3 and 4) it starts putting the file. After sending 2143990632<tel:2143990632> bytes it kind of starts over and the highlighted log shows up. The file at that point does not "grow" in size on the server side.

Help truly appreciated !!

Thanks,
Vikas.


INFO: Connecting to xxx.xxx.xxx.xx port 22
INFO: Connection established
INFO: Remote version string: SSH-2.0-mod_sftp/0.9.7
INFO: Local version string: SSH-2.0-JSCH-0.1.53
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: SSH_MSG_KEXINIT received
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true
WARN: Permanently added 'xxx.xxx.xxx.xx' (RSA) to the list of known hosts.
INFO: SSH_MSG_NEWKEYS sent
INFO: SSH_MSG_NEWKEYS received
INFO: SSH_MSG_SERVICE_REQUEST sent
INFO: SSH_MSG_SERVICE_ACCEPT received
INFO: Authentications that can continue: publickey,keyboard-interactive,password
INFO: Next authentication method: publickey
INFO: Authentications that can continue: password
INFO: Next authentication method: password
INFO: Authentication succeeded (password).
-----------------------------------3
-----------------------------------4
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
JSch-users mailing list
JSc...@li...<mailto:JSc...@li...>
https://lists.sourceforge.net/lists/listinfo/jsch-users

Re: [JSch-users] SFTP of large file hangs

[Alan E. <ala...@gm...>]

Another guess: investigate what the startup command line options are for
java on the system in question.
Is the max heap size limited with an -Xmx option? Or is there a -d32 being
passed in?



On Mon, Oct 10, 2016 at 8:26 AM, Vikas Verma <vvi...@ho...> wrote:

> I was able to reproduce this in our local environment. We were able to
> setup ProFTPD SFTP server with default settings. After transferring about
> 2GB of data (using jsch) the transfer stops. I am attaching the ProFTPD
> logs for reference. Please help.
>
>
> Thanks,
>
> Vikas.
> ------------------------------
> *From:* Vikas Verma <vvi...@ho...>
> *Sent:* Wednesday, October 5, 2016 11:40:47 AM
> *To:* Alan Ezust
>
> *Cc:* jsc...@li...
> *Subject:* Re: [JSch-users] SFTP of large file hangs
>
>
> @Alan --> Yes its running 64 bit.
>
> @Lothar --> The problem is just between Proftpd and JSCH. I am able to
> transfer huge files (> 4gb) to other SFTP servers from JSCH. And Proftpd
> works fine with other ssh clients (like the one that comes with linux). I
> am not sure sure about their (Partner that hosts sftp server) logging. I
> can reach out and ask. But their support isnt that great.
>
>
> Thanks,
>
> Vikas.
> ------------------------------
> *From:* Alan Ezust <ala...@gm...>
> *Sent:* Wednesday, October 5, 2016 11:00:44 AM
> *To:* Vikas Verma
> *Cc:* jsc...@li...
> *Subject:* Re: [JSch-users] SFTP of large file hangs
>
> Just wondering, is the client running jsch also running a 64 bit version
> of Java?
>
>
> On Mon, Oct 3, 2016 at 12:19 PM, Vikas Verma <vvi...@ho...> wrote:
>
>> Can anyone please help? The SFTP server is proftpd. This looks like an
>> old Rekeying problem between Proftpd and Jsch. I have tried JSCH version
>> 50/51 and 54 with no luck.
>>
>>
>> Thanks,
>>
>> Vikas.
>> ------------------------------
>> *From:* Vikas Verma <vvi...@ho...>
>> *Sent:* Wednesday, September 14, 2016 11:43:16 AM
>> *To:* jsc...@li...
>> *Subject:* SFTP of large file hangs
>>
>>
>> We are having a strange issue with one of our clients (Client hosts the
>> SFTP server. We are the client using JSCH). When we SFTP a large file to
>> their SFTP server the file stops getting uploaded after exactly
>> 2143990632 bytes. The JSCH connection just starts over at that point. I
>> am including the logs. Has anyone seen this behavior before? I can use any
>> other SFTP client with that server and they work.
>>
>> In the logs you will see that after my custom log prints (3 and 4) it
>> starts putting the file. After sending 2143990632 bytes it kind of
>> starts over and the highlighted log shows up. The file at that point does
>> not "grow" in size on the server side.
>>
>> Help truly appreciated !!
>>
>> Thanks,
>> Vikas.
>>
>>
>> INFO: Connecting to xxx.xxx.xxx.xx port 22
>> INFO: Connection established
>> INFO: Remote version string: SSH-2.0-mod_sftp/0.9.7
>> INFO: Local version string: SSH-2.0-JSCH-0.1.53
>> INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-c
>> tr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour
>> 128,arcfour256
>> INFO: aes256-ctr is not available.
>> INFO: aes192-ctr is not available.
>> INFO: aes256-cbc is not available.
>> INFO: aes192-cbc is not available.
>> INFO: CheckKexes: diffie-hellman-group14-sha1,ec
>> dh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
>> INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2
>> -nistp384,ecdsa-sha2-nistp521
>> INFO: SSH_MSG_KEXINIT sent
>> INFO: SSH_MSG_KEXINIT received
>> INFO: kex: server: diffie-hellman-group-exchange-
>> sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-gro
>> up14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
>> INFO: kex: server: ssh-rsa,ssh-dss
>> INFO: kex: server: aes256-ctr,aes192-ctr,aes128-c
>> tr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour2
>> 56,arcfour128,3des-ctr,3des-cbc
>> INFO: kex: server: aes256-ctr,aes192-ctr,aes128-c
>> tr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour2
>> 56,arcfour128,3des-ctr,3des-cbc
>> INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md
>> 5,hmac-md5-96,hmac-ripemd160
>> INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md
>> 5,hmac-md5-96,hmac-ripemd160
>> INFO: kex: server: zl...@op...,zlib,none
>> INFO: kex: server: zl...@op...,zlib,none
>> INFO: kex: server:
>> INFO: kex: server:
>> INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-n
>> istp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffi
>> e-hellman-group-exchange-sha256,diffie-hellman-group-exchang
>> e-sha1,diffie-hellman-group1-sha1
>> INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nis
>> tp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
>> INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
>> INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
>> INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-2
>> 56,hmac-sha1-96,hmac-md5-96
>> INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-2
>> 56,hmac-sha1-96,hmac-md5-96
>> INFO: kex: client: none
>> INFO: kex: client: none
>> INFO: kex: client:
>> INFO: kex: client:
>> INFO: kex: server->client aes128-ctr hmac-md5 none
>> INFO: kex: client->server aes128-ctr hmac-md5 none
>> INFO: SSH_MSG_KEXDH_INIT sent
>> INFO: expecting SSH_MSG_KEXDH_REPLY
>> INFO: ssh_rsa_verify: signature true
>> WARN: Permanently added 'xxx.xxx.xxx.xx' (RSA) to the list of known hosts.
>> INFO: SSH_MSG_NEWKEYS sent
>> INFO: SSH_MSG_NEWKEYS received
>> INFO: SSH_MSG_SERVICE_REQUEST sent
>> INFO: SSH_MSG_SERVICE_ACCEPT received
>> INFO: Authentications that can continue: publickey,keyboard-interactive
>> ,password
>> INFO: Next authentication method: publickey
>> INFO: Authentications that can continue: password
>> INFO: Next authentication method: password
>> INFO: Authentication succeeded (password).
>> -----------------------------------3
>> -----------------------------------4
>> INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-c
>> tr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour
>> 128,arcfour256
>> INFO: aes256-ctr is not available.
>> INFO: aes192-ctr is not available.
>> INFO: aes256-cbc is not available.
>> INFO: aes192-cbc is not available.
>> INFO: CheckKexes: diffie-hellman-group14-sha1,ec
>> dh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
>> INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2
>> -nistp384,ecdsa-sha2-nistp521
>> INFO: SSH_MSG_KEXINIT sent
>> INFO: kex: server: diffie-hellman-group-exchange-
>> sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-gro
>> up14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
>> INFO: kex: server: ssh-rsa,ssh-dss
>> INFO: kex: server: aes256-ctr,aes192-ctr,aes128-c
>> tr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour2
>> 56,arcfour128,3des-ctr,3des-cbc
>> INFO: kex: server: aes256-ctr,aes192-ctr,aes128-c
>> tr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour2
>> 56,arcfour128,3des-ctr,3des-cbc
>> INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md
>> 5,hmac-md5-96,hmac-ripemd160
>> INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md
>> 5,hmac-md5-96,hmac-ripemd160
>> INFO: kex: server: zl...@op...,zlib,none
>> INFO: kex: server: zl...@op...,zlib,none
>> INFO: kex: server:
>> INFO: kex: server:
>> INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-n
>> istp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffi
>> e-hellman-group-exchange-sha256,diffie-hellman-group-exchang
>> e-sha1,diffie-hellman-group1-sha1
>> INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nis
>> tp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
>> INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
>> INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
>> INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-2
>> 56,hmac-sha1-96,hmac-md5-96
>> INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-2
>> 56,hmac-sha1-96,hmac-md5-96
>> INFO: kex: client: none
>> INFO: kex: client: none
>> INFO: kex: client:
>> INFO: kex: client:
>> INFO: kex: server->client aes128-ctr hmac-md5 none
>> INFO: kex: client->server aes128-ctr hmac-md5 none
>> INFO: SSH_MSG_KEXDH_INIT sent
>> INFO: expecting SSH_MSG_KEXDH_REPLY
>> INFO: ssh_rsa_verify: signature true
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> JSch-users mailing list
>> JSc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsch-users
>>
>>
>

Re: [JSch-users] SFTP of large file hangs

[Vikas V. <vvi...@ho...>]

@Alan --> Yes its running 64 bit.

@Lothar --> The problem is just between Proftpd and JSCH. I am able to transfer huge files (> 4gb) to other SFTP servers from JSCH. And Proftpd works fine with other ssh clients (like the one that comes with linux). I am not sure sure about their (Partner that hosts sftp server) logging. I can reach out and ask. But their support isnt that great.


Thanks,

Vikas.

________________________________
From: Alan Ezust <ala...@gm...>
Sent: Wednesday, October 5, 2016 11:00:44 AM
To: Vikas Verma
Cc: jsc...@li...
Subject: Re: [JSch-users] SFTP of large file hangs

Just wondering, is the client running jsch also running a 64 bit version of Java?


On Mon, Oct 3, 2016 at 12:19 PM, Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>> wrote:

Can anyone please help? The SFTP server is proftpd. This looks like an old Rekeying problem between Proftpd and Jsch. I have tried JSCH version 50/51 and 54 with no luck.


Thanks,

Vikas.

________________________________
From: Vikas Verma <vvi...@ho...<mailto:vvi...@ho...>>
Sent: Wednesday, September 14, 2016 11:43:16 AM
To: jsc...@li...<mailto:jsc...@li...>
Subject: SFTP of large file hangs


We are having a strange issue with one of our clients (Client hosts the SFTP server. We are the client using JSCH). When we SFTP a large file to their SFTP server the file stops getting uploaded after exactly 2143990632<tel:2143990632> bytes. The JSCH connection just starts over at that point. I am including the logs. Has anyone seen this behavior before? I can use any other SFTP client with that server and they work.

In the logs you will see that after my custom log prints (3 and 4) it starts putting the file. After sending 2143990632<tel:2143990632> bytes it kind of starts over and the highlighted log shows up. The file at that point does not "grow" in size on the server side.

Help truly appreciated !!

Thanks,
Vikas.


INFO: Connecting to xxx.xxx.xxx.xx port 22
INFO: Connection established
INFO: Remote version string: SSH-2.0-mod_sftp/0.9.7
INFO: Local version string: SSH-2.0-JSCH-0.1.53
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: SSH_MSG_KEXINIT received
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true
WARN: Permanently added 'xxx.xxx.xxx.xx' (RSA) to the list of known hosts.
INFO: SSH_MSG_NEWKEYS sent
INFO: SSH_MSG_NEWKEYS received
INFO: SSH_MSG_SERVICE_REQUEST sent
INFO: SSH_MSG_SERVICE_ACCEPT received
INFO: Authentications that can continue: publickey,keyboard-interactive,password
INFO: Next authentication method: publickey
INFO: Authentications that can continue: password
INFO: Next authentication method: password
INFO: Authentication succeeded (password).
-----------------------------------3
-----------------------------------4
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server: zl...@op...<mailto:zl...@op...>,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
JSch-users mailing list
JSc...@li...<mailto:JSc...@li...>
https://lists.sourceforge.net/lists/listinfo/jsch-users

Re: [JSch-users] SFTP of large file hangs

[Alan E. <ala...@gm...>]

Just wondering, is the client running jsch also running a 64 bit version of
Java?


On Mon, Oct 3, 2016 at 12:19 PM, Vikas Verma <vvi...@ho...> wrote:

> Can anyone please help? The SFTP server is proftpd. This looks like an
> old Rekeying problem between Proftpd and Jsch. I have tried JSCH version
> 50/51 and 54 with no luck.
>
>
> Thanks,
>
> Vikas.
> ------------------------------
> *From:* Vikas Verma <vvi...@ho...>
> *Sent:* Wednesday, September 14, 2016 11:43:16 AM
> *To:* jsc...@li...
> *Subject:* SFTP of large file hangs
>
>
> We are having a strange issue with one of our clients (Client hosts the
> SFTP server. We are the client using JSCH). When we SFTP a large file to
> their SFTP server the file stops getting uploaded after exactly 2143990632
> bytes. The JSCH connection just starts over at that point. I am including
> the logs. Has anyone seen this behavior before? I can use any other SFTP
> client with that server and they work.
>
> In the logs you will see that after my custom log prints (3 and 4) it
> starts putting the file. After sending 2143990632 bytes it kind of starts
> over and the highlighted log shows up. The file at that point does not
> "grow" in size on the server side.
>
> Help truly appreciated !!
>
> Thanks,
> Vikas.
>
>
> INFO: Connecting to xxx.xxx.xxx.xx port 22
> INFO: Connection established
> INFO: Remote version string: SSH-2.0-mod_sftp/0.9.7
> INFO: Local version string: SSH-2.0-JSCH-0.1.53
> INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-
> ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,
> arcfour128,arcfour256
> INFO: aes256-ctr is not available.
> INFO: aes192-ctr is not available.
> INFO: aes256-cbc is not available.
> INFO: aes192-cbc is not available.
> INFO: CheckKexes: diffie-hellman-group14-sha1,
> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
> INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-
> nistp521
> INFO: SSH_MSG_KEXINIT sent
> INFO: SSH_MSG_KEXINIT received
> INFO: kex: server: diffie-hellman-group-exchange-
> sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-
> group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
> INFO: kex: server: ssh-rsa,ssh-dss
> INFO: kex: server: aes256-ctr,aes192-ctr,aes128-
> ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,
> arcfour256,arcfour128,3des-ctr,3des-cbc
> INFO: kex: server: aes256-ctr,aes192-ctr,aes128-
> ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,
> arcfour256,arcfour128,3des-ctr,3des-cbc
> INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-
> md5,hmac-md5-96,hmac-ripemd160
> INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-
> md5,hmac-md5-96,hmac-ripemd160
> INFO: kex: server: zl...@op...,zlib,none
> INFO: kex: server: zl...@op...,zlib,none
> INFO: kex: server:
> INFO: kex: server:
> INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-
> nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,
> diffie-hellman-group-exchange-sha256,diffie-hellman-group-
> exchange-sha1,diffie-hellman-group1-sha1
> INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-
> nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
> INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
> INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
> INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-
> 256,hmac-sha1-96,hmac-md5-96
> INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-
> 256,hmac-sha1-96,hmac-md5-96
> INFO: kex: client: none
> INFO: kex: client: none
> INFO: kex: client:
> INFO: kex: client:
> INFO: kex: server->client aes128-ctr hmac-md5 none
> INFO: kex: client->server aes128-ctr hmac-md5 none
> INFO: SSH_MSG_KEXDH_INIT sent
> INFO: expecting SSH_MSG_KEXDH_REPLY
> INFO: ssh_rsa_verify: signature true
> WARN: Permanently added 'xxx.xxx.xxx.xx' (RSA) to the list of known hosts.
> INFO: SSH_MSG_NEWKEYS sent
> INFO: SSH_MSG_NEWKEYS received
> INFO: SSH_MSG_SERVICE_REQUEST sent
> INFO: SSH_MSG_SERVICE_ACCEPT received
> INFO: Authentications that can continue: publickey,keyboard-
> interactive,password
> INFO: Next authentication method: publickey
> INFO: Authentications that can continue: password
> INFO: Next authentication method: password
> INFO: Authentication succeeded (password).
> -----------------------------------3
> -----------------------------------4
> INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-
> ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,
> arcfour128,arcfour256
> INFO: aes256-ctr is not available.
> INFO: aes192-ctr is not available.
> INFO: aes256-cbc is not available.
> INFO: aes192-cbc is not available.
> INFO: CheckKexes: diffie-hellman-group14-sha1,
> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
> INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-
> nistp521
> INFO: SSH_MSG_KEXINIT sent
> INFO: kex: server: diffie-hellman-group-exchange-
> sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-
> group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
> INFO: kex: server: ssh-rsa,ssh-dss
> INFO: kex: server: aes256-ctr,aes192-ctr,aes128-
> ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,
> arcfour256,arcfour128,3des-ctr,3des-cbc
> INFO: kex: server: aes256-ctr,aes192-ctr,aes128-
> ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,
> arcfour256,arcfour128,3des-ctr,3des-cbc
> INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-
> md5,hmac-md5-96,hmac-ripemd160
> INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-
> md5,hmac-md5-96,hmac-ripemd160
> INFO: kex: server: zl...@op...,zlib,none
> INFO: kex: server: zl...@op...,zlib,none
> INFO: kex: server:
> INFO: kex: server:
> INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-
> nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,
> diffie-hellman-group-exchange-sha256,diffie-hellman-group-
> exchange-sha1,diffie-hellman-group1-sha1
> INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-
> nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
> INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
> INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
> INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-
> 256,hmac-sha1-96,hmac-md5-96
> INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-
> 256,hmac-sha1-96,hmac-md5-96
> INFO: kex: client: none
> INFO: kex: client: none
> INFO: kex: client:
> INFO: kex: client:
> INFO: kex: server->client aes128-ctr hmac-md5 none
> INFO: kex: client->server aes128-ctr hmac-md5 none
> INFO: SSH_MSG_KEXDH_INIT sent
> INFO: expecting SSH_MSG_KEXDH_REPLY
> INFO: ssh_rsa_verify: signature true
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users
>
>

Re: [JSch-users] SFTP of large file hangs

[Lothar K. <jo...@ki...>]

Hi,

Am 03.10.2016 um 21:19 schrieb Vikas Verma:
> Can anyone please help? The SFTP server is proftpd. This looks like an old
>  Rekeying problem between Proftpd and Jsch. I have tried JSCH version 50/51
>  and 54 with no luck.

if time permits (it currently isn't) I can try to reproduce it here, but
this isn't a general problem since I know of one user here who is transfering
DVD-images via JSCH from one server to the other, so if there were a problem
that is always ocurring I'd know of it already.

Is proftpd on the other side able to log more than nothing? Maybe you
can see something popping up that might help.


Cheers, Lothar

Re: [JSch-users] SFTP of large file hangs

[Vikas V. <vvi...@ho...>]

Can anyone please help? The SFTP server is proftpd. This looks like an old Rekeying problem between Proftpd and Jsch. I have tried JSCH version 50/51 and 54 with no luck.


Thanks,

Vikas.

________________________________
From: Vikas Verma <vvi...@ho...>
Sent: Wednesday, September 14, 2016 11:43:16 AM
To: jsc...@li...
Subject: SFTP of large file hangs


We are having a strange issue with one of our clients (Client hosts the SFTP server. We are the client using JSCH). When we SFTP a large file to their SFTP server the file stops getting uploaded after exactly 2143990632 bytes. The JSCH connection just starts over at that point. I am including the logs. Has anyone seen this behavior before? I can use any other SFTP client with that server and they work.

In the logs you will see that after my custom log prints (3 and 4) it starts putting the file. After sending 2143990632 bytes it kind of starts over and the highlighted log shows up. The file at that point does not "grow" in size on the server side.

Help truly appreciated !!

Thanks,
Vikas.


INFO: Connecting to xxx.xxx.xxx.xx port 22
INFO: Connection established
INFO: Remote version string: SSH-2.0-mod_sftp/0.9.7
INFO: Local version string: SSH-2.0-JSCH-0.1.53
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: SSH_MSG_KEXINIT received
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...,zlib,none
INFO: kex: server: zl...@op...,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true
WARN: Permanently added 'xxx.xxx.xxx.xx' (RSA) to the list of known hosts.
INFO: SSH_MSG_NEWKEYS sent
INFO: SSH_MSG_NEWKEYS received
INFO: SSH_MSG_SERVICE_REQUEST sent
INFO: SSH_MSG_SERVICE_ACCEPT received
INFO: Authentications that can continue: publickey,keyboard-interactive,password
INFO: Next authentication method: publickey
INFO: Authentications that can continue: password
INFO: Next authentication method: password
INFO: Authentication succeeded (password).
-----------------------------------3
-----------------------------------4
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...,zlib,none
INFO: kex: server: zl...@op...,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true

Re: [JSch-users] stdout and stderr question

[Offer B. <off...@gm...>]

Hi...

Thanks for the reply...
Yes. I am sure the command is writing to stderr... running the same command
with runtime.exec produces each output in a different stream...
I have read the examples and can't figure out anything i am doing wrong...

I will share the relevant parts of the code when i am near a computer
again...

Thanks on advance,
Offer Baruch

On Sep 28, 2016 15:42, "Keith Alan Richardson" <kei...@gm...> wrote:

> Hi
>
> Is the command you run remotely via jsch writing to stderr?  You can check
> that by running it manually and redirecting stdout to /dev/null
>
> I recall the JSCH website has example code which reads the two streams out
> separately. Try looking at that for a reference
>
> If all else fails you'll need to share your code
>
> -Keith Richardson
>
> On Wednesday, September 28, 2016, Offer Baruch <off...@gm...>
> wrote:
>
>> Really? no one? is this the right place to ask this?
>>
>> On Tue, Sep 6, 2016 at 12:47 PM, Offer Baruch <off...@gm...>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> We have been using JSCH for a long time now...
>>> We are using an ChannelExec to run our commands.
>>> Up until now we always read both the input and err streams and combined
>>> their output into one string.
>>>
>>> We now want to split those streams into different strings and to allow
>>> the calling program to decide what to do with each stream...
>>> When i tried to debug this, i have found that reading from the input
>>> stream returns back both stdout and stderr... in fact the err stream is
>>> empty...
>>> is this a known feature/bug?
>>>
>>> is there a proper way to do this?
>>>
>>> thanks in advance!
>>> Offer Baruch
>>>
>>
>>

Re: [JSch-users] stdout and stderr question

[Keith A. R. <kei...@gm...>]

Hi

Is the command you run remotely via jsch writing to stderr?  You can check
that by running it manually and redirecting stdout to /dev/null

I recall the JSCH website has example code which reads the two streams out
separately. Try looking at that for a reference

If all else fails you'll need to share your code

-Keith Richardson

On Wednesday, September 28, 2016, Offer Baruch <off...@gm...>
wrote:

> Really? no one? is this the right place to ask this?
>
> On Tue, Sep 6, 2016 at 12:47 PM, Offer Baruch <off...@gm...
> <javascript:_e(%7B%7D,'cvml','off...@gm...');>> wrote:
>
>> Hi everyone,
>>
>> We have been using JSCH for a long time now...
>> We are using an ChannelExec to run our commands.
>> Up until now we always read both the input and err streams and combined
>> their output into one string.
>>
>> We now want to split those streams into different strings and to allow
>> the calling program to decide what to do with each stream...
>> When i tried to debug this, i have found that reading from the input
>> stream returns back both stdout and stderr... in fact the err stream is
>> empty...
>> is this a known feature/bug?
>>
>> is there a proper way to do this?
>>
>> thanks in advance!
>> Offer Baruch
>>
>
>

Re: [JSch-users] stdout and stderr question

[Offer B. <off...@gm...>]

Really? no one? is this the right place to ask this?

On Tue, Sep 6, 2016 at 12:47 PM, Offer Baruch <off...@gm...> wrote:

> Hi everyone,
>
> We have been using JSCH for a long time now...
> We are using an ChannelExec to run our commands.
> Up until now we always read both the input and err streams and combined
> their output into one string.
>
> We now want to split those streams into different strings and to allow the
> calling program to decide what to do with each stream...
> When i tried to debug this, i have found that reading from the input
> stream returns back both stdout and stderr... in fact the err stream is
> empty...
> is this a known feature/bug?
>
> is there a proper way to do this?
>
> thanks in advance!
> Offer Baruch
>

[JSch-users] SFTP of large file hangs

[Vikas V. <vvi...@ho...>]

We are having a strange issue with one of our clients (Client hosts the SFTP server. We are the client using JSCH). When we SFTP a large file to their SFTP server the file stops getting uploaded after exactly 2143990632 bytes. The JSCH connection just starts over at that point. I am including the logs. Has anyone seen this behavior before? I can use any other SFTP client with that server and they work.

In the logs you will see that after my custom log prints (3 and 4) it starts putting the file. After sending 2143990632 bytes it kind of starts over and the highlighted log shows up. The file at that point does not "grow" in size on the server side.

Help truly appreciated !!

Thanks,
Vikas.


INFO: Connecting to xxx.xxx.xxx.xx port 22
INFO: Connection established
INFO: Remote version string: SSH-2.0-mod_sftp/0.9.7
INFO: Local version string: SSH-2.0-JSCH-0.1.53
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: SSH_MSG_KEXINIT received
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...,zlib,none
INFO: kex: server: zl...@op...,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true
WARN: Permanently added 'xxx.xxx.xxx.xx' (RSA) to the list of known hosts.
INFO: SSH_MSG_NEWKEYS sent
INFO: SSH_MSG_NEWKEYS received
INFO: SSH_MSG_SERVICE_REQUEST sent
INFO: SSH_MSG_SERVICE_ACCEPT received
INFO: Authentications that can continue: publickey,keyboard-interactive,password
INFO: Next authentication method: publickey
INFO: Authentications that can continue: password
INFO: Next authentication method: password
INFO: Authentication succeeded (password).
-----------------------------------3
-----------------------------------4
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: SSH_MSG_KEXINIT sent
INFO: kex: server: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa1024-sha1
INFO: kex: server: ssh-rsa,ssh-dss
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,cast128-cbc,arcfour256,arcfour128,3des-ctr,3des-cbc
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160
INFO: kex: server: zl...@op...,zlib,none
INFO: kex: server: zl...@op...,zlib,none
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: kex: server->client aes128-ctr hmac-md5 none
INFO: kex: client->server aes128-ctr hmac-md5 none
INFO: SSH_MSG_KEXDH_INIT sent
INFO: expecting SSH_MSG_KEXDH_REPLY
INFO: ssh_rsa_verify: signature true

[JSch-users] stdout and stderr question

[Offer B. <off...@gm...>]

Hi everyone,

We have been using JSCH for a long time now...
We are using an ChannelExec to run our commands.
Up until now we always read both the input and err streams and combined
their output into one string.

We now want to split those streams into different strings and to allow the
calling program to decide what to do with each stream...
When i tried to debug this, i have found that reading from the input stream
returns back both stdout and stderr... in fact the err stream is empty...
is this a known feature/bug?

is there a proper way to do this?

thanks in advance!
Offer Baruch

[JSch-users] ANNOUNCE: JSch 0.1.54

[<ym...@jc...>]

Hi there,

JSch 0.1.54 has been released.
It is available at
  http://sourceforge.net/projects/jsch/files/jsch/0.1.54/jsch-0.1.54.zip/download
and its md5sum is 0b9312909fe542f6e662d40ec676f6b5 .
And you can get its byte code in jar file format at
  http://sourceforge.net/projects/jsch/files/jsch.jar/0.1.54/jsch-0.1.54.jar/download
and its md5sum is ee35c74673b4113f92f8bbafe2c5eeaa .


Changes since version 0.1.53:
- bugfix: fixed CVS-2016-5725
          Refer to following links,
            http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2016-5725
            https://github.com/tintinweb/pub/tree/master/pocs/cve-2016-5725
          Thanks a lot for tintinweb's contributions.
- bugfix: sftp-put may send the garbage data in some rare case.
- bugfix: fixed a deadlock bug in KnownHosts#getHostKey().
- bugfix: SftpProgressMonitor#init() was not invoked in sftp-put
          by using the output-stream.
- change: KnownHosts#setKnownHosts() should accept the non-existing file.
- change: excluding the user interaction time from the timeout value.
- change: addressing SFTP slow file transfer speed with Titan FTP.
- change: updating copyright messages; 2015 -> 2016

[JSch-users] Enormous traffic when uploading file to non-empty folder

[Milano N. <dra...@gm...>]

OK, now I feel embarassed and stupid for not noticing earlier that in my
code there is hidden the *ChannelSftp.ls* call. No idea why. It's been
there since beginning of the app. It is called once when new file
abstraction is requested and once for any other operation (e.g. requesting
an OutputStream from the abstraction).

*Let's do the math now:*
If you have about 6400 files in the upload directory, it means about 1,5 MB
of data to download if you want to list it. And it can take up to two
minutes (120 seconds) to download such data depending on your connection.

So if you want to *upload* one *4KB* file to the SFTP using streams, you
are going to *download 3MB* of useless data first, *wait* up to about *four
minutes* and then your file is downloaded. I'm not even speaking about the
fact the operation is going to fail if your connection is slow since you're
not going to simply download so much data on a bad connection.
Thanks to Lothar for pointing me to the right direction!

Re: [JSch-users] Enormous traffic when uploading file to non-empty folder

[Lothar K. <jo...@ki...>]

Am 24.08.2016 um 11:57 schrieb Milano Nicolum:
> Another symptom of the issue is that listing the directory content via sftp.ls
>  sftp.ls(sftpAbsolutePath) call takes approx. 100 seconds, tcpdump says it
>  transfers about 1555 KB server -> client and 58KB client -> server.
>
> If I connect to the server via SSH (using putty), run the ll command in console
>  and redirect the command output to a textfile, the resulting file has 768 KB
>  instantly.

SFTP is a different thing than SSH-shell, so it's not easy to compare these.
what was the exact command for listing the files in the shell?
Since you ran tcpdump, where exactly were the 100 seconds happening? While
waiting for data from the server or is it a slower transfer of bytes?

> I understand that there is allways difference in the computing time, part of
>  it depends on the fact computing is done on server/client side. (Even though
>  the difference is huge). But where is the additional data traffic coming from?

A reason might be that you compare apples to pears. In case you entered
ls subdir
in the shell and you are listing the directory with
/home/user/subdir
in SFTP, the SFTP server will most likely return the filenames including
their paths while the shell only returns the names. This would easily
explain the increased amount of data. Also there is additional data per
file containing the attributes (see next paragraph). With short filenames
this easily becomes the majority of tranfered data.

In case the time got lost while waiting for the server the reason might
be that the file-listing in SFTP provides more information than the
resulting file listing in a shell. For every file the FileAttributes are
retrieved from the file system containing things like last access time,
"extended attributes", etc. Some of them are part of the directory-entry
itself that can be accessed quickly. Others are not that easy to retrieve
(or at least need an extra file-system-access per file) and might be the
reason why your listing takes exponentially longer for longer files.

This is not a SFTP-specific problem, you can run into the same problem
when using the file-command with search-criterias for last access time, etc.


Cheers, Lothar

[JSch-users] Enormous traffic when uploading file to non-empty folder

[Milano N. <dra...@gm...>]

Another symptom of the issue is that listing the directory content via
sftp.ls(sftpAbsolutePath) call takes approx. 100 seconds, tcpdump says it
transfers about 1555 KB server -> client and 58KB client -> server.

If I connect to the server via SSH (using putty), run the ll command in
console and redirect the command output to a textfile, the resulting file
has 768 KB instantly. I understand that there is allways difference in the
computing time, part of it depends on the fact computing is done on
server/client side. (Even though the difference is huge). But where is the
additional data traffic coming from? Approximately twice as much data is
transfered. Any ideas?

P.S. I wouldn't expect any issues with encoding as both machines run some
unix derivate system. But who knows. Is there a possibility of such problem?

[JSch-users] Enormous traffic when uploading file to non-empty folder

[Milano N. <dra...@gm...>]

After further investigation I tested two scenarios of uploading a file to
the SFTP server. In scenario one I only had a handful of files in the
upload directory, in the second scenario there were 6400 tiny files more.

*Scenario 1:* lstat takes about 1 sec to execute. Tcpdump shows 907020
bytes traffic for a 800 KB file...
2016-08-23 13:19:28,655 [TRACE] SFTP Operation - Get file attributes
(lstat): /home/milano/upload_test/Clean_code.pptx
2016-08-23 13:19:30,844 [TRACE] SFTP Operation - Getting file attributes
finished.
2016-08-23 13:19:30,877 [TRACE] SFTP Operation - Get file attributes
(lstat): /home/milano/upload_test/Clean_code.pptx
2016-08-23 13:19:32,044 [TRACE] SFTP Operation - Getting file attributes
finished.

*Scenario 2:* lstat takes about 110 sec to execute. Tcpdump shows 4130593
bytes traffic for a 800 KB file...
2016-08-23 14:05:10,222 [TRACE] SFTP Operation - Get file attributes
(lstat): /home/milano/upload_test/Clean_code.pptx
2016-08-23 14:06:58,868 [TRACE] SFTP Operation - Getting file attributes
finished.
2016-08-23 14:06:59,336 [TRACE] SFTP Operation - Get file attributes
(lstat): /home/milano/upload_test/Clean_code.pptx
2016-08-23 14:08:45,189 [TRACE] SFTP Operation - Getting file attributes
finished.

So the upload took about the same time in the end, but it was the lstat
command using a lot of data. Now I have to find out how to avoid such
behaviour...

[JSch-users] Enormous traffic when uploading file to non-empty folder

[Milano N. <dra...@gm...>]

Hi, I'm currently experiencing an issue with my company's file transfering
osgi bundle using the jsch library. Normally it should only upload some log
files archive files once per few minutes. But once there were more files
present in the target folder, the data consumption on my device also grew
proportionally.

E.g. if there are only 40 files in the upload folder, everything seems to
be OK. So nobody noticed any problem. But once there are 7000 files or so,
the *incomming *data consumption gets really high. The log files can have
20-35 MB per day, but my download takes even about 2,5 GB data per day.
With no other networking application active.

Of course there may be an error in my code (which I'm trying to discover
right now), but I wonder if anyone experienced similar problem.

Thanks for any tips.

[JSch-users] Provide More Information in Exception

[温. <we...@fo...>]

Hi,

I am reading code of below method and found there is one exception thrown with little information which is not helpful for end users.
com.jcraft.jsch.Session.connect(int)

        while (true) {
            buf = read(buf);
            if (kex.getState() == buf.getCommand()) {
                kex_start_time = System.currentTimeMillis();
                boolean result = kex.next(buf);
                if (!result) {
                    //System.err.println("verify: "+result);
                    in_kex = false;
                    throw new JSchException("verify: " + result);
                }
            } else {
                in_kex = false;
                throw new JSchException("invalid protocol(kex): " + buf.getCommand());
            }
            if (kex.getState() == KeyExchange.STATE_END) {
                break;
            }
        }

The JSchException("verify:"+result) will result in below stack trace when it is thrown:

    Caused by: com.jcraft.jsch.JSchException: verify: false     	at com.jcraft.jsch.Session.connect(Session.java:305)     	at com.jcraft.jsch.Session.connect(Session.java:158)     	at com.ericsson.commonlibrary.nealservices.fault.NodeSftp.connect(NodeSftp.java:44)     	... 37 more
This kind of exception message is almost useless for end users, especially for those newbies. So, could you please refine this and make it more readable and understandable? Thanks!

[JSch-users] Support for //?

[Keith B. <kb...@bo...>]

Hiyas,

We use JSch to provide SFTP services in our application and users have
reported an inability to use the '//' sequence to specify an upload to the
root directory.  One user has debugged the software and found that the
string seems to be getting changed to a single '/' sequence before the
upload actually occurs leading the server to err on the request.

They feel is should work since this is valid in a command line SFTP
client.  For example:

sftp> put ./BFEP.ILBZZ.K0696376 //BFEP.ILBZZ.K0696376
Uploading ./BFEP.ILBZZ.K0696376 to //BFEP.ILBZZ.K0696376
./BFEP.ILBZZ.K0696376 100% 492 0.5KB/s 00:00

Is this a known defect or just unsupported functionality?

Thanks.

Keith

-- 
Keith Barlow

*Software Engineer*
*Dell Boomi*

[JSch-users] com.jcraft.jsch.JSchException: session is down

[Manan B. <man...@gm...>]

Hi all,
This is my first mail in mailer list so pardon me for bad formatting.

I am facing session is down exception while transferring file to remote vm
which runs on ubuntu.
In a high level debug issue comes when I called openChannel("sftp")
The implementation of openChanel(String type) looks like,

if(!isConnected){                            //isConnected is true
  throw new JSchException("session is down");
}
try{
  Channel channel=Channel.getChannel(type);    //After this
isConnected is coming false
  addChannel(channel);
  channel.init();
  return channel;
}
catch(Exception e){
  //e.printStackTrace();
}
return null;

So I tried to debug if more than one thread is trying to access isConnected
variable but it is not the case. Also getChannel has nothing to do with
isConnected.
Is any one of you have face this issue? Your help will be really
appreciated.



-- 
Regards,
Manan Bhatt

Re: [JSch-users] Transfering large number of small files

[Leonardo K. S. <sh...@gm...>]

you can't compare sftp with rsync

rsync calculates the incremental changes it must send over the wire, sftp
will always send the whole file, no matter it's overwriting the same file
on the other side

you can compare jsch with native sftp, but I believe sftp will still be
faster for obvious reasons

[]

Leo

On Wed, Jul 13, 2016 at 6:59 PM, Luís Lobo <lf...@gm...> wrote:

> Hi all.
>
> I'm trying to transfer a large number of small files to a remote server
> (with reasonable latency) using JSch.
>
> The code I'm using creates a Session and a ChannelSftp and then iterates
> over the local files (some times thousands) to transfer them to the server,
> with something like (I omitted exception handling for simplicity):
>
> Session session=...;
> ChannelSftp sftp=(ChannelSftp)session.openChannel("sftp");
> for(Path path:...){
>     sftp.put(path.toString(), String.format("/destination/%s",path.getFileName().toString()));
> }
> sftp.disconnect();
> session.disconnect();
>
>
> The problem is this is very slow (sometimes *it takes hours*) compared
> with the something like:
>
> rsync -avu /local/<some glob> server:/destination/ # takes seconds
>
> Is there any faster way to transfer large number of small files with JSch?
>
> Regards,
> LL
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users
>
>

[JSch-users] Transferring large number of small files

[Luís L. <lf...@gm...>]

(now with correct encoding... sorry)
Hi all.

I'm trying to transfer a large number of small files to a remote server (with reasonable latency) using JSch.

The code I'm using creates a Session and a ChannelSftp and then iterates over the local files (some times thousands) to transfer them to the server, with something like (I omitted exception handling for simplicity):

	Session session = ...;
	ChannelSftp sftp = (ChannelSftp) session.openChannel("sftp");
	for(Path path : ...){
	    sftp.put(path.toString(), String.format("/destination/%s",path.getFileName().toString()));
	}
	sftp.disconnect();
	session.disconnect();

The problem is this is very slow (sometimes it takes hours) compared with the something like:

	rsync -av /local/<some glob> server:/destination/ # takes seconds

Is there any faster way to transfer large number of small files with JSch?

Regards,
LL

[JSch-users] Transfering large number of small files

[Luís L. <lf...@gm...>]

Hi all.

I'm trying to transfer a large number of small files to a remote server (with reasonable latency) using JSch.

The code I'm using creates a Session and a ChannelSftp and then iterates over the local files (some times thousands) to transfer them to the server, with something like (I omitted exception handling for simplicity):

Session session=...;
ChannelSftp sftp=(ChannelSftp)session.openChannel("sftp");
for(Path path:...){
    sftp.put(path.toString(), String.format("/destination/%s",path.getFileName().toString()));
}
sftp.disconnect();
session.disconnect();

The problem is this is very slow (sometimes it takes hours) compared with the something like:

rsync -avu /local/<some glob> server:/destination/ # takes seconds

Is there any faster way to transfer large number of small files with JSch?

Regards,
LL