jsch-users Mailing List for JSch
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: Jurrie O. <jsc...@ju...> - 2023-02-22 18:23:38
|
On 22-02-2023 07:16, Abhishek Kant Rattan via JSch-users wrote: > JSCH 3pp is currently supporting the following weak mac algorithms only. > > *MAC: hmac-md5, hmac-sha1, hmac-md5-96, hmac-sha1-96* > > Is there any planning to support strong mac algorithms in JSCH?. > Hi Abhishek, JSch seems to be in a state of low-maintenance. The author is not responsive (even on bug reports and proposed fixes), this mailing list sees minor traffic and the latest JSch release was released 26-11-2018 (https://search.maven.org/artifact/com.jcraft/jsch). I would advise you to migrate to a fork that's better maintained, such as that of Matthias (https://sourceforge.net/p/jsch/mailman/message/37044268/). See https://github.com/mwiede/jsch and https://search.maven.org/artifact/com.github.mwiede/jsch. With kind regards, Jurrie |
From: Abhishek K. R. <abh...@er...> - 2023-02-22 06:49:51
|
Hi Team, JSCH 3pp is currently supporting the following weak mac algorithms only. MAC: hmac-md5, hmac-sha1, hmac-md5-96, hmac-sha1-96 Is there any planning to support strong mac algorithms in JSCH?. Thanks & Regards, [http://mediabank.ericsson.net/internet-media/Email_logo_Ericsson.png]<http://www.ericsson.com/> Abhishek Kant Rattan |
From: <mw...@gm...> - 2020-06-23 09:41:09
|
hi all, as it is unclear about the maintenance of jsch, I write a blog post about the connection to the openssh changes in the future http://www.matez.de/index.php/2020/06/22/the-future-of-jsch-without-ssh-rsa/ As long as I hear nothing back, I am releasing the jsch fork on https://github.com/mwiede/jsch Kind regards Matthias On Tue, Jun 2, 2020 at 5:43 PM Jerry Nicholson <je...@ml...> wrote: > We certainly hope Jsch has a long and healthy lifespan. We are using it in > a production > environment where it fills a very import role. > > -- > Jerry Nicholson > Mlink.com LLC > 603.523.8398 > > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users > |
From: Jerry N. <je...@ml...> - 2020-06-02 15:43:04
|
We certainly hope Jsch has a long and healthy lifespan. We are using it in a production environment where it fills a very import role. -- Jerry Nicholson Mlink.com LLC 603.523.8398 |
From: Bram V. D. <bra...@in...> - 2020-06-02 10:35:50
|
Hey folks, I'm wondering: is JSCH still being maintained? The latest release was back in 2018. There are already couple of forks out there which implement new features (such as support for rsa-sha2-512). Thanks, - Bram |
From: James L. <jam...@de...> - 2019-12-06 05:01:28
|
Dear Dr. Yamanaka, Thank you for JSch! While using JSch via the Apache Commons VFS API, I encountered VFS-627 <https://issues.apache.org/jira/browse/VFS-627>. I root caused the issue and found a deadlock in JSch. A patch against JSch 0.1.55 that fixes the issue is below. I also posted a detailed investigation of the problem and a simple test program to reproduce the issue at: https://github.com/jlentini/SftpCopyDeadlock I hope this fix can be included in a future version of JSch. If you would like more information or the patch in a different format, please let me know. Regards, -james James Lentini --- Prevent read/write deadlock by allocating sufficient receive buffer space diff --git a/src/main/java/com/jcraft/jsch/ChannelSftp.java b/src/main/java/com/jcraft/jsch/ChannelSftp.java index f76d1d5..3ac036f 100644 --- a/src/main/java/com/jcraft/jsch/ChannelSftp.java +++ b/src/main/java/com/jcraft/jsch/ChannelSftp.java @@ -224,7 +224,7 @@ public class ChannelSftp extends ChannelSession{ PipedOutputStream pos=new PipedOutputStream(); io.setOutputStream(pos); - PipedInputStream pis=new MyPipedInputStream(pos, rmpsize); + PipedInputStream pis=new MyPipedInputStream(pos, rq.size()*rmpsize); io.setInputStream(pis); io_in=io.in; |
From: Mohamed F. N <md...@gm...> - 2019-11-12 19:49:44
|
Hi Team, We are from HCL-Cisco team. Recently we got a request to support the HMAC-SHA2-256 and HMAC-SHA2-512 stronger algorithms. At present, we are using the “jcraft.jar” of version:0.1.53 and downloaded the latest “0.1.55” also. In that jar, particularly – com.jcraft.jsch.JSch.java found the below lines are commented out, // The "hmac-sha2-512" will require the key-length 2048 for DH, // but Sun's JCE has not allowed to use such a long key. //config.put("hmac-sha2-512", "com.jcraft.jsch.jce.HMACSHA512"); Why this algorithm is not yet supported? But still I am able to see the file named com.jcraft.jsch.jce.HMACSHA512. Is this algorithm not fully implemented/handled with Parent Class“HMAC.java”? Suggest if any alternate way to support SHA2-512 algorithm ? And also I would like to know the list of all types of MAC algorithms support in Java till date. Thanks in Advance ! Regards, Mohamed Faleh N |
From: Abhimanu H. <abh...@gm...> - 2019-11-11 08:39:13
|
Hi Lothar, Thanks for the reply. Can you suggest me a solution , so that program can get out of loop as soon as command is executed. Regards, Abhimanu Handoo On Mon, Oct 28, 2019 at 6:04 PM Lothar Kimmeringer <jo...@ki...> wrote: > > > Am 28.10.2019 um 05:35 schrieb Abhimanu Handoo: > > while(in.available()>0){ > > available() returns the number of bytes that can be read without blocking. > I assume that this returns 0 all the time and because you don't do any > attempt to actually read from the stream (leading to blocking) you never > end the loop. > > BTW: > > if(i<0)break; > > -1 is only returned if the end of stream is reached. Having this > inside a block that is only entered after you know that there is > data to be read (i.e. the end is not reached) makes no real sense. > > > Cheers, Lothar > > > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users > -- *Thanks and Regards,Abhimanu Handoo+91-7838562222* |
From: Lothar K. <jo...@ki...> - 2019-10-28 12:34:07
|
Am 28.10.2019 um 05:35 schrieb Abhimanu Handoo: > while(in.available()>0){ available() returns the number of bytes that can be read without blocking. I assume that this returns 0 all the time and because you don't do any attempt to actually read from the stream (leading to blocking) you never end the loop. BTW: > if(i<0)break; -1 is only returned if the end of stream is reached. Having this inside a block that is only entered after you know that there is data to be read (i.e. the end is not reached) makes no real sense. Cheers, Lothar |
From: Abhimanu H. <abh...@gm...> - 2019-10-28 04:36:00
|
Hi, I am having issue while trying to execute certain commands.Below is the code I am creating session in object and pass it along with the command -------------------------------------------------------------------------------------- private void executeCommand(Session session, String CMD) { logInfo("Inside executeCommand method. CMD is :\n" +CMD); try { Channel channel=session.openChannel("exec"); ((ChannelExec)channel).setCommand(CMD); channel.setInputStream(null); ((ChannelExec)channel).setErrStream(System.err); InputStream in=channel.getInputStream(); channel.connect(); byte[] tmp=new byte[1024]; while(true){ while(in.available()>0){ int i=in.read(tmp, 0, 1024); logInfo("Inside in.avilable()>0 while loop..."); System.out.println("Inside in.avilable()>0 while loop..."); if(i<0)break; logInfo(new String(tmp, 0, i)); } if(channel.isClosed() || in.available() < 0){ logInfo("exit-status: "+channel.getExitStatus()); break; } try{ Thread.sleep(1000); }catch(Exception e){ LOGGER.log(Level.SEVERE, e.getLocalizedMessage(), e); System.exit(INIT_ERROR); } System.out.println("Inside while true loop..."); } channel.disconnect(); } catch (Exception e) { LOGGER.log(Level.SEVERE, e.getLocalizedMessage(), e); System.exit(INIT_ERROR); } } ------------------------------------------------------------------------- Please help !! -- *Thanks and Regards,Abhimanu Handoo* |
From: Fernando R. <rod...@or...> - 2019-05-31 11:33:52
|
El 30/5/19 a las 20:52, cha...@gm... escribió: > Hi > > When I am connecting with jsch session getting the java.io.IOException:end of io stream error.using the IntelliJ ide.pls help me what wrong I am doing > > Thanks > Rao > > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users hi, you get a session? what type of server you try to connect, ssh version? -- A/P Fernando Rodriguez Analista Técnico Administración de Servidores Departamento de Servicios Informáticos Universidad ORT Uruguay +59829021505 int. 1401 |
From: <cha...@gm...> - 2019-05-30 23:53:00
|
Hi When I am connecting with jsch session getting the java.io.IOException:end of io stream error.using the IntelliJ ide.pls help me what wrong I am doing Thanks Rao |
From: Sensen, A. <a.s...@th...> - 2019-04-12 17:50:59
|
Dear Lothar and Volker, thanks for your quick reply. I indeed misunderstood how the InputStream should be handled. I implemented a wrapper that counts the transferred bytes and returns -1 when the file has been transferred completely, just as Lothar suggested. Thank you very much for your help! Andreas ________________________________ Von: Jung, Volker [vol...@so...] Gesendet: Freitag, 12. April 2019 13:58 An: 'jsc...@li...' Betreff: Re: [JSch-users] SCP to SFTP file streaming Hi Andreas, as far as I understand, you are trying to stream data received by the SCP ‘protocol’ directly to a target host via SFTP. The streams of the EXEC-channel are open as long as the EXEC channel is not closed. However, your implementation seems to assume that the InputStream is closed as soon as the data of the file is fully received via SCP. This is not the case and looks to me like a misunderstanding on your side. I think you have to implement the SCP specific details yourself, meaning that you have to provide a new InputStream for SFTP-upload which is closed upon receiving the end-transmission-token via SCP. Sincerely yours Volker Von: Sensen, Andreas <a.s...@th...> Gesendet: Freitag, 12. April 2019 08:42 An: 'jsc...@li...' <jsc...@li...> Betreff: [JSch-users] SCP to SFTP file streaming Hi all, first i’d like to thank JCraft for the JSch library. It has been really helpful so far! But during my development i ran into a problem: trying to copy a file with SCP to an SFTP-Server using the Streams provided by JSch. The error is easily reproducable in Version 0.1.55 by doing the following steps: * Retrieve an InputStream (MyPipedInputStream) from a Channel * Try to upload this file with an ChannelSftp: -------- JSch jsch = new JSch(); Session session = jsch.getSession(username, host, port); ChannelExec channel = (ChannelExec) session.openChannel("exec"); … InputStream sshInputStream = channel.getInputStream(); JSch jsch = new JSch(); Session session = jsch.getSession(username, host, port); ChannelSftp channel = (ChannelSftp) session.openChannel("sftp"); channel.put(sshInputStream , file); -------- The problem lies in ChannelSftp's _put method (lines 635 to 643): -------- do{ nread=src.read(data, s, datalen); if(nread>0){ s+=nread; datalen-=nread; count+=nread; } } while(datalen>0 && nread>0); -------- As far as i understand it, the while-loop tries to read as many bytes as possible into the data array. But since a (My)PipedInputStream doesn't return -1 if it's empty, but rather waits for more data to come, this ends in an endlessly blocking read() at the end of the file transfer. The only way i could solve this is by removing the do-while-loop around the code and adding an SftpProgressMonitor implementation, that returns false on count(long byte) if the whole file has been transferred. But that involves manipulating JSch source code, which i'd prefer not to do... Is there any better solution to this particular problem? Any help would be greatly appreciated! Thanks Andreas |
From: Jung, V. <vol...@so...> - 2019-04-12 12:21:18
|
Hi Andreas, as far as I understand, you are trying to stream data received by the SCP 'protocol' directly to a target host via SFTP. The streams of the EXEC-channel are open as long as the EXEC channel is not closed. However, your implementation seems to assume that the InputStream is closed as soon as the data of the file is fully received via SCP. This is not the case and looks to me like a misunderstanding on your side. I think you have to implement the SCP specific details yourself, meaning that you have to provide a new InputStream for SFTP-upload which is closed upon receiving the end-transmission-token via SCP. Sincerely yours Volker Von: Sensen, Andreas <a.s...@th...> Gesendet: Freitag, 12. April 2019 08:42 An: 'jsc...@li...' <jsc...@li...> Betreff: [JSch-users] SCP to SFTP file streaming Hi all, first i'd like to thank JCraft for the JSch library. It has been really helpful so far! But during my development i ran into a problem: trying to copy a file with SCP to an SFTP-Server using the Streams provided by JSch. The error is easily reproducable in Version 0.1.55 by doing the following steps: * Retrieve an InputStream (MyPipedInputStream) from a Channel * Try to upload this file with an ChannelSftp: -------- JSch jsch = new JSch(); Session session = jsch.getSession(username, host, port); ChannelExec channel = (ChannelExec) session.openChannel("exec"); ... InputStream sshInputStream = channel.getInputStream(); JSch jsch = new JSch(); Session session = jsch.getSession(username, host, port); ChannelSftp channel = (ChannelSftp) session.openChannel("sftp"); channel.put(sshInputStream , file); -------- The problem lies in ChannelSftp's _put method (lines 635 to 643): -------- do{ nread=src.read(data, s, datalen); if(nread>0){ s+=nread; datalen-=nread; count+=nread; } } while(datalen>0 && nread>0); -------- As far as i understand it, the while-loop tries to read as many bytes as possible into the data array. But since a (My)PipedInputStream doesn't return -1 if it's empty, but rather waits for more data to come, this ends in an endlessly blocking read() at the end of the file transfer. The only way i could solve this is by removing the do-while-loop around the code and adding an SftpProgressMonitor implementation, that returns false on count(long byte) if the whole file has been transferred. But that involves manipulating JSch source code, which i'd prefer not to do... Is there any better solution to this particular problem? Any help would be greatly appreciated! Thanks Andreas |
From: Lothar K. <jo...@ki...> - 2019-04-12 10:30:35
|
Am 12.04.2019 um 08:42 schrieb Sensen, Andreas: > ChannelExec channel = (ChannelExec) session.openChannel("exec"); > > … that part would be interesting as well in order to give an answer. > InputStream sshInputStream = channel.getInputStream(); Aftersending a "scp -f filename" the scp-command starts with an information about the lenght of the file to be transfered. You should read that and keep that information for the next step. Here you should wrap the returned inputstream into an own InputStream that uses the above size-information to return -1 as soon as the announced number of bytes has been reached. Cheers, Lothar |
From: Sensen, A. <a.s...@th...> - 2019-04-12 06:59:49
|
Hi all, first i'd like to thank JCraft for the JSch library. It has been really helpful so far! But during my development i ran into a problem: trying to copy a file with SCP to an SFTP-Server using the Streams provided by JSch. The error is easily reproducable in Version 0.1.55 by doing the following steps: * Retrieve an InputStream (MyPipedInputStream) from a Channel * Try to upload this file with an ChannelSftp: -------- JSch jsch = new JSch(); Session session = jsch.getSession(username, host, port); ChannelExec channel = (ChannelExec) session.openChannel("exec"); ... InputStream sshInputStream = channel.getInputStream(); JSch jsch = new JSch(); Session session = jsch.getSession(username, host, port); ChannelSftp channel = (ChannelSftp) session.openChannel("sftp"); channel.put(sshInputStream , file); -------- The problem lies in ChannelSftp's _put method (lines 635 to 643): -------- do{ nread=src.read(data, s, datalen); if(nread>0){ s+=nread; datalen-=nread; count+=nread; } } while(datalen>0 && nread>0); -------- As far as i understand it, the while-loop tries to read as many bytes as possible into the data array. But since a (My)PipedInputStream doesn't return -1 if it's empty, but rather waits for more data to come, this ends in an endlessly blocking read() at the end of the file transfer. The only way i could solve this is by removing the do-while-loop around the code and adding an SftpProgressMonitor implementation, that returns false on count(long byte) if the whole file has been transferred. But that involves manipulating JSch source code, which i'd prefer not to do... Is there any better solution to this particular problem? Any help would be greatly appreciated! Thanks Andreas |
From: jai.bhima.naga.patavali <jai...@pr...> - 2019-03-24 22:17:58
|
Hi JSch Experts Quoting http://www.jcraft.com/jsch/ : ---------------------------------------------- Features The current JSch has the following features. Cipher: blowfish-cbc,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,3des-ctr,arcfour,arcfour128,arcfour256 ---------------------------------------------- I am using JSch 0.1.54 library version. The above states that aes256-cbc is supported by JSch library. Indeed I see there is implementation for AES256CBC.java in the package com.jcraft.jsch.jce in the source code for JSch available from Maven repository http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.jcraft%22%20AND%20a%3A%22jsch%22 I see that the JSch implementation relies on the JRE's cipher implementation. SecretKeySpec keyspec=new SecretKeySpec(key, "AES"); cipher=javax.crypto.Cipher.getInstance("AES/CBC/"+pad); I am using JRE 1.6 with Unlimited Strength Jurisdiction Policy (refer https://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html) and JCE is already pre-packaged within JRE 1.6. However apparently aes256-cbc is not supported with JRE 1.6 since I cannot use that cipher with JSch when connecting to my SSH Server. Can you please confirm aes256-cbc is not supported in JRE 1.6 ? Is it possible for me to enhance JRE 1.6 with support for the aes256-cbc cipher implementation ? Unfortunately upgrading to higher JRE version (1.7 or 1.8) is not feasible since it involves massive logistical challenges currently. Any help is really appreciated. I am totally blocked and need some ideas. Thanks, Suchet Sent with [ProtonMail](https://protonmail.com) Secure Email. |
From: <307...@qq...> - 2019-03-14 09:36:12
|
Look at lines 633-665, and in particular lines 638-644. It looks like keys in formats DSA, RSA, ECDSA, and SSH are supported, but there's no indication that OPENSSH keys are supported.https://www.openssh.com/txt/release-7.8 ssh-keygen(1): write OpenSSH format private keys by default instead of using OpenSSL's PEM format.OpenSSH format -----BEGIN OPENSSH PRIVATE KEY----- ... -----BEGIN OPENSSH PRIVATE KEY----- OpenSSL's PEM format -----BEGIN RSA PRIVATE KEY----- ... -----BEGIN RSA PRIVATE KEY-----Which version do you plan to fix this issue? Thanks for the help. |
From: Borislav S. <jsc...@me...> - 2019-01-06 22:46:12
|
Hello, Support is (should be) in place. You need to pass parameters and optionally/preferably set the preferred authentication method to 'gssapi-with-mic'. This is a link to a previous discussion that should be helpful: https://jsch-users.narkive.com/GwhLVhEH/kerberos-jsch-help#post4 Borislav On Fri, Jan 4, 2019 at 4:55 AM Hrushikesh Agrawal via JSch-users < jsc...@li...> wrote: > Hi All, > Can you please help me on below questions - > > - Does below jars supports the Kerberos authentication while performing > the SFTP operations through jsch library? > jsch-0.1.51.jar > jsch-0.1.49.jar > > - is Kerberos authentication by default supported by library or do we > need to take care for this. > > Thanks, > Hrushi > > > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users > |
From: Jurrie O. <jsc...@ju...> - 2019-01-04 11:27:56
|
Hi Lothar, Happy new year to you too! On 26-11-2018 there was a new release, version 0.1.55. So I don't think the project's dead... but not quite alive as well :) With kind regards, Jurrie On 04-01-19 11:46, Lothar Kimmeringer wrote: > Hi, > > so I assume Jsch is dead, then? > > > Thanks, cheers and a happy new ywar. > > Am 12.01.2018 um 10:11 schrieb Lothar Kimmeringer: >> Hi, >> >> just to make sure that my mail of two months ago hasn't been lost >> by the Elders of Jsch, I ask again. >> >> >> Thanks and cheers, Lothar >> >> Am 13.11.2017 um 09:07 schrieb Lothar Kimmeringer: >>> Hi, >>> >>> I'm wondering if JSch is still alive. The last update was more than a >>> year ago and the last mail coming from the "official side" (i.e. >>> Atsuhiko Yamanaka) in this list was the announcement of this update. >>> Since then no more mails are answered. Because there is no public >>> source repository (the only one I found is a mirror with the last >>> commit >>> that took place 2011) I'm not able to see if any activity is actually >>> taking place so I'm hoping to at least get some life sign to this mail. >>> >>> >>> Thanks and best regards, >>> >>> Lothar Kimmeringer > > > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users |
From: Lothar K. <jo...@ki...> - 2019-01-04 11:00:15
|
Hi, so I assume Jsch is dead, then? Thanks, cheers and a happy new ywar. Am 12.01.2018 um 10:11 schrieb Lothar Kimmeringer: > Hi, > > just to make sure that my mail of two months ago hasn't been lost > by the Elders of Jsch, I ask again. > > > Thanks and cheers, Lothar > > Am 13.11.2017 um 09:07 schrieb Lothar Kimmeringer: >> Hi, >> >> I'm wondering if JSch is still alive. The last update was more than a >> year ago and the last mail coming from the "official side" (i.e. >> Atsuhiko Yamanaka) in this list was the announcement of this update. >> Since then no more mails are answered. Because there is no public >> source repository (the only one I found is a mirror with the last commit >> that took place 2011) I'm not able to see if any activity is actually >> taking place so I'm hoping to at least get some life sign to this mail. >> >> >> Thanks and best regards, >> >> Lothar Kimmeringer |
From: Hrushikesh A. <hag...@ti...> - 2019-01-04 09:54:56
|
Hi All, Can you please help me on below questions - - Does below jars supports the Kerberos authentication while performing the SFTP operations through jsch library? jsch-0.1.51.jar jsch-0.1.49.jar - is Kerberos authentication by default supported by library or do we need to take care for this. Thanks, Hrushi |
From: Hrushikesh A. <hag...@ti...> - 2018-07-12 15:26:58
|
Hi, We are using jsch library to get connected to sftp server and its works fine. We are getting issue when IPA is enabled on RHEL machine. We can't connect to the same host on port 22 through jsch lib. So question is - Does Jsch supports the IPA authentication? if yes, can you please share the steps for that? Thanks, Hrushi |
From: Lothar K. <jo...@ki...> - 2018-01-12 09:24:27
|
Hi, just to make sure that my mail of two months ago hasn't been lost by the Elders of Jsch, I ask again. Thanks and cheers, Lothar Am 13.11.2017 um 09:07 schrieb Lothar Kimmeringer: > Hi, > > I'm wondering if JSch is still alive. The last update was more than a > year ago and the last mail coming from the "official side" (i.e. > Atsuhiko Yamanaka) in this list was the announcement of this update. > Since then no more mails are answered. Because there is no public > source repository (the only one I found is a mirror with the last commit > that took place 2011) I'm not able to see if any activity is actually > taking place so I'm hoping to at least get some life sign to this mail. > > > Thanks and best regards, > > Lothar Kimmeringer |
From: Marco M. <ma...@ma...> - 2017-11-29 10:00:39
|
Hi, I would suggest you to implement a listener to catch if ssh is disconnected suddenly. Now I'm implementing Logger interface and, if message contains "Caught an exception, leaving main loop due to Connection reset", I retry the ssh connection. Many thanks! |