jsch-users Mailing List for JSch (Page 3)
Status: Alpha
Brought to you by:
ymnk
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
(3) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(34) |
Feb
(70) |
Mar
(18) |
Apr
(17) |
May
(21) |
Jun
(20) |
Jul
(27) |
Aug
(12) |
Sep
(10) |
Oct
(7) |
Nov
(21) |
Dec
(5) |
2004 |
Jan
(18) |
Feb
(13) |
Mar
(35) |
Apr
(8) |
May
(26) |
Jun
(32) |
Jul
(19) |
Aug
(37) |
Sep
(14) |
Oct
(20) |
Nov
(41) |
Dec
(48) |
2005 |
Jan
(44) |
Feb
(60) |
Mar
(62) |
Apr
(42) |
May
(26) |
Jun
(55) |
Jul
(29) |
Aug
(21) |
Sep
(56) |
Oct
(20) |
Nov
(17) |
Dec
(9) |
2006 |
Jan
(33) |
Feb
(49) |
Mar
(27) |
Apr
(27) |
May
(67) |
Jun
(28) |
Jul
(64) |
Aug
(45) |
Sep
(39) |
Oct
(52) |
Nov
(36) |
Dec
(45) |
2007 |
Jan
(60) |
Feb
(44) |
Mar
(57) |
Apr
(18) |
May
(15) |
Jun
(37) |
Jul
(27) |
Aug
(32) |
Sep
(48) |
Oct
(52) |
Nov
(48) |
Dec
(17) |
2008 |
Jan
(28) |
Feb
(6) |
Mar
(29) |
Apr
(27) |
May
(10) |
Jun
(33) |
Jul
(27) |
Aug
(15) |
Sep
(46) |
Oct
(18) |
Nov
(10) |
Dec
(8) |
2009 |
Jan
(22) |
Feb
(17) |
Mar
(10) |
Apr
(14) |
May
(20) |
Jun
(28) |
Jul
(9) |
Aug
(8) |
Sep
(12) |
Oct
(22) |
Nov
(23) |
Dec
(18) |
2010 |
Jan
(32) |
Feb
(18) |
Mar
(30) |
Apr
(54) |
May
(25) |
Jun
(22) |
Jul
(26) |
Aug
(54) |
Sep
(15) |
Oct
(24) |
Nov
(53) |
Dec
(11) |
2011 |
Jan
(45) |
Feb
(40) |
Mar
(47) |
Apr
(28) |
May
(30) |
Jun
(58) |
Jul
(13) |
Aug
(27) |
Sep
(41) |
Oct
(7) |
Nov
(18) |
Dec
(22) |
2012 |
Jan
(36) |
Feb
(71) |
Mar
(30) |
Apr
(25) |
May
(32) |
Jun
(15) |
Jul
(12) |
Aug
(8) |
Sep
(16) |
Oct
(21) |
Nov
(4) |
Dec
|
2013 |
Jan
(9) |
Feb
(6) |
Mar
(27) |
Apr
(16) |
May
(16) |
Jun
(10) |
Jul
(5) |
Aug
(1) |
Sep
(7) |
Oct
(12) |
Nov
(25) |
Dec
(10) |
2014 |
Jan
(4) |
Feb
(24) |
Mar
(7) |
Apr
(12) |
May
(14) |
Jun
(7) |
Jul
(13) |
Aug
(3) |
Sep
(21) |
Oct
(10) |
Nov
(4) |
Dec
(6) |
2015 |
Jan
(8) |
Feb
(8) |
Mar
(6) |
Apr
(5) |
May
(2) |
Jun
(4) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
(16) |
Nov
(6) |
Dec
(9) |
2016 |
Jan
(7) |
Feb
(7) |
Mar
(3) |
Apr
(1) |
May
(12) |
Jun
(7) |
Jul
(7) |
Aug
(6) |
Sep
(5) |
Oct
(15) |
Nov
(6) |
Dec
(1) |
2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
(3) |
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Răzvan R. <raz...@gm...> - 2016-10-14 15:50:33
|
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 |
From: Vikas V. <vvi...@ho...> - 2016-10-10 21:17:51
|
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 |
From: Vikas V. <vvi...@ho...> - 2016-10-10 16:38:41
|
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 |
From: Alan E. <ala...@gm...> - 2016-10-10 16:10:12
|
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 >> >> > |
From: Vikas V. <vvi...@ho...> - 2016-10-05 15:41:00
|
@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 |
From: Alan E. <ala...@gm...> - 2016-10-05 15:01:33
|
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 > > |
From: Lothar K. <jo...@ki...> - 2016-10-05 11:47:49
|
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 |
From: Vikas V. <vvi...@ho...> - 2016-10-03 19:19:50
|
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 |
From: Offer B. <off...@gm...> - 2016-09-28 17:26:14
|
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 >>> >> >> |
From: Keith A. R. <kei...@gm...> - 2016-09-28 12:42:19
|
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 >> > > |
From: Offer B. <off...@gm...> - 2016-09-28 10:35:35
|
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 > |
From: Vikas V. <vvi...@ho...> - 2016-09-14 15:43:28
|
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 |
From: Offer B. <off...@gm...> - 2016-09-06 09:47:17
|
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 |
From: <ym...@jc...> - 2016-08-30 18:28:46
|
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 |
From: Milano N. <dra...@gm...> - 2016-08-25 05:53:00
|
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! |
From: Lothar K. <jo...@ki...> - 2016-08-24 10:33:23
|
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 |
From: Milano N. <dra...@gm...> - 2016-08-24 09:57:12
|
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? |
From: Milano N. <dra...@gm...> - 2016-08-24 07:34:41
|
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... |
From: Milano N. <dra...@gm...> - 2016-08-23 10:24:57
|
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. |
From: 温. <we...@fo...> - 2016-07-22 09:35:11
|
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! |
From: Keith B. <kb...@bo...> - 2016-07-21 18:35:08
|
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* |
From: Manan B. <man...@gm...> - 2016-07-15 07:30:18
|
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 |
From: Leonardo K. S. <sh...@gm...> - 2016-07-14 02:07:57
|
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 > > |
From: Luís L. <lf...@gm...> - 2016-07-13 22:09:31
|
(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 |
From: Luís L. <lf...@gm...> - 2016-07-13 21:59:34
|
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 |