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

Re: [JSch-users] End of IO Stream Read Exception

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

Am 21.10.2015 um 23:31 schrieb Randy Grasmick:
> Hello! I have been working on an SFTP suite for an Oracle database
> for quite some time now and have reached to end of my rope with
> this error: “com.jcraft.jsch.JSchException: Session.connect:
> java.io.IOException: End of IO Stream Read.” I can’t seem to pin
> down what element is causing this error. I realize that it occurs
> when the session attempts to connect, session.connect(int timeout),
> but I have no idea where to look for trouble.

can you enable debug logging? Maybe that helps to see where
the problem occurs.


Cheers, Lothar

Re: [JSch-users] Illegal data get mixed into a sent file

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

Hi,

Am 21.10.2015 um 10:22 schrieb Kagoshima Data Application Co., Ltd.  T.Oohara:

> We are using JSch library version 0.1.49 and we have a problem that
> the illegal data will get mixed into a file we sent.
[...]
> We found the same problem would occur with JSch-0.1.53, do you think
> this problem occurs due to a defect specific to JSch? And in that
> case, can you fix the defect with JSch version 0.1.49?

can you provide a test class reduced to the code that helps
reproducing the effect?


Cheers, Lothar

Re: [JSch-users] com.jcraft.jsch.JSchException: verify: false

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

Am 23.10.2015 um 04:19 schrieb Fate Testarossa:

> when i use jsch frequently connect  and disconnect session,it shows :
> 
> com.jcraft.jsch.JSchException: verify: false
> at com.jcraft.jsch.Session.connect(Session.java:295)

[...]

> And when i also connect and disconnect channelsftp frequently ,
> the message shows that "

> com.jcraft.jsch.JSchException: verify: false
> at com.jcraft.jsch.Session.connect(Session.java:295)

This is the same error. You don't reach the line where
you open sftp.

> Then how to do it if i want to connect and disconnect session
> and channelsftp frequently ? Thanks.

Looks like there is a firewall on the server-side (or a
feature in the SSH-server) regarding your client's
behavior as DoS-attack and denies further access.


Cheers, Lothar

Re: [JSch-users] Packet Fragmentation

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

Am 21.10.2015 um 12:53 schrieb Flavio Orfano:

> I am trying to confirm if JSCH client allow packet fragmentation by
> default. Would this be something configurable at this level or
> would this be responsibility of lower level like IP?

Packet fragmentation happens on the network interface level and
can't be controlled on application level.


Cheers, Lothar

[JSch-users] com.jcraft.jsch.JSchException: verify: false

[Fate T. <asd...@si...>]

Dear sir,
when i use jsch frequently connect  and disconnect session,it shows :631com.jcraft.jsch.JSchException: verify: false	at com.jcraft.jsch.Session.connect(Session.java:295)	at com.jcraft.jsch.Session.connect(Session.java:150)	at udf.Test1.connect(Test1.java:48)	at udf.Test1.main(Test1.java:18)940com.jcraft.jsch.JSchException: verify: false	at com.jcraft.jsch.Session.connect(Session.java:295)	at com.jcraft.jsch.Session.connect(Session.java:150)	at udf.Test1.connect(Test1.java:48)	at udf.Test1.main(Test1.java:18)
the code is "
import com.jcraft.jsch.ChannelSftp;import com.jcraft.jsch.JSch;import com.jcraft.jsch.JSchException;import com.jcraft.jsch.Session;import com.jcraft.jsch.UserInfo;
public class Test1 {
	public static void main(String[] args) {				Test1 c =new Test1();		int count =0;		while(true){			Session s;			try {				s = c.connect();				ChannelSftp sftp =(ChannelSftp)s.openChannel("sftp");//			    sftp.connect();//			    sftp.disconnect();				c.close(s);				count++;				if(count==1000000000)					System.out.println(count);			} catch (JSchException e) {				// TODO Auto-generated catch block				System.out.println(count);				e.printStackTrace();			} 							}	}	public void close(ChannelSftp channelSftp){				if(channelSftp!=null||!channelSftp.isConnected())			channelSftp.disconnect();	}	public void close(Session session){				if(session!=null||!session.isConnected())			session.disconnect();	}	public Session connect() throws JSchException{				Session session =new JSch().getSession("xx", "xx.xx.xx.xx");		session.setUserInfo(new SimpleUserInfo("xxxx"));		session.connect();		return session;	}}class SimpleUserInfo implements UserInfo {

    private String password;
    public SimpleUserInfo(String password) {        this.password = password;    }
    @Override    public String getPassphrase() {        return null;    }
    @Override    public String getPassword() {        return password;    }
    @Override    public boolean promptPassword(String message) {        return true;    }
    @Override    public boolean promptPassphrase(String message) {        return false;    }
    @Override    public boolean promptYesNo(String message) {        return true;    }
    @Override    public void showMessage(String s) {
    }}

"And when i also connect and disconnect channelsftp frequently ,the message shows that "125com.jcraft.jsch.JSchException: verify: false	at com.jcraft.jsch.Session.connect(Session.java:295)	at com.jcraft.jsch.Session.connect(Session.java:150)	at udf.Test1.connect(Test1.java:49)	at udf.Test1.main(Test1.java:19)
"the code is "
import com.jcraft.jsch.ChannelSftp;import com.jcraft.jsch.JSch;import com.jcraft.jsch.JSchException;import com.jcraft.jsch.Session;import com.jcraft.jsch.UserInfo;
public class Test1 {
	public static void main(String[] args) {				Test1 c =new Test1();		int count =0;		while(true){			Session s;			try {				s = c.connect();				ChannelSftp sftp =(ChannelSftp)s.openChannel("sftp");			    sftp.connect();			    sftp.disconnect();				c.close(s);				count++;				if(count==1000000000)					System.out.println(count);			} catch (JSchException e) {				// TODO Auto-generated catch block				System.out.println(count);				e.printStackTrace();			} 							}	}	public void close(ChannelSftp channelSftp){				if(channelSftp!=null||!channelSftp.isConnected())			channelSftp.disconnect();	}	public void close(Session session){				if(session!=null||!session.isConnected())			session.disconnect();	}	public Session connect() throws JSchException{				Session session =new JSch().getSession("xxx", "xx.xx.xx.xx");		session.setUserInfo(new SimpleUserInfo("xxxxx"));		session.connect();		return session;	}}class SimpleUserInfo implements UserInfo {

    private String password;
    public SimpleUserInfo(String password) {        this.password = password;    }
    @Override    public String getPassphrase() {        return null;    }
    @Override    public String getPassword() {        return password;    }
    @Override    public boolean promptPassword(String message) {        return true;    }
    @Override    public boolean promptPassphrase(String message) {        return false;    }
    @Override    public boolean promptYesNo(String message) {        return true;    }
    @Override    public void showMessage(String s) {
    }}
"
Then how to do it if i want to connect and disconnect session and channelsftp frequently ? Thanks.

[JSch-users] End of IO Stream Read Exception

[Randy G. <ran...@en...>]

Hello! I have been working on an SFTP suite for an Oracle database for quite some time now and have reached to end of my rope with this error: "com.jcraft.jsch.JSchException: Session.connect: java.io.IOException: End of IO Stream Read." I can't seem to pin down what element is causing this error. I realize that it occurs when the session attempts to connect, session.connect(int timeout), but I have no idea where to look for trouble.

Frustatingly enough, I have the same implementation of this suite of code in my TEST database that works like a charm. It was only just recently that trouble started brewing in my PROD instance. Up until recently the error had been something along the lines of "JSchException: Packet Corrupt", but after changing some Java permissions in the database, it has reared its ugly head in the form of an IO Stream error. Anybody have this kind of issue that they kind find a resolution to?

Regards,

Randy Grasmick

[cid:image001.jpg@01CF7661.6AFC2B10]

Randy Grasmick
IT/DBA Intern
eNSYNC Solutions, Inc.
913.647.8689 (office)   913.605.0670 (cell)
www.ensyncsolutions.com<http://www.ensyncsolutions.com/>

[JSch-users] Packet Fragmentation

[Flavio O. <fo...@ho...>]

Hello Team,
I am trying to confirm if JSCH client allow packet fragmentation by default. Would this be something configurable at this level or would this be responsibility of lower level like IP?
TIA,Flavio 		 	   		  

[JSch-users] Illegal data get mixed into a sent file

[Kagoshima D. A. Co., L. T.O. <ooh...@da...>]

Hello.

We are using JSch library version 0.1.49 and we have a problem that the illegal data will get mixed into a file we sent.

If we add the following configuration to Sftp.java, which is one of the examples included with jsch-0.1.49.zip, and send a file to the SFTP Server (Titan FTP server), then the result shows the file size is the same between the sent file and the received one, but we can find the contents of the two files are different if we compare the hash values retrieved from them.
  JSch.setConfig("mac.c2s", "hmac-sha2-256");
  JSch.setConfig("mac.s2c", "hmac-sha2-256");

This problem always happens when we sent a file which size is more than 35840 bytes. And we look into the received file, we found the data such as a header information "SSH_MSG_CHANNEL_DATA" always got mixed in with the file at every position of 35709 bytes (i.e. a size of data which JSch can send to the Titan SFTP Server in one time), we think this will cause the difference of the contents with the two files.

And it seems that the following values have been set to "SSH_MSG_CHANNEL_OPEN_CONFIRMATION" from the SFTP Server:
  initial window size:16384
  maximum packet size:35840


We found the same problem would occur with JSch-0.1.53, do you think this problem occurs due to a defect specific to JSch? And in that case, can you fix the defect with JSch version 0.1.49?

[JSch-users] Bug with Channel.getInputStream()

[Rob V. <rv...@do...>]

Folks

We've discovered an interesting bug in Channel.getInputStream() (and
potentially also in Channel.getOutputStream()) which can lead to receiving
truncated messages depending on how calling code uses JSch

The basic problem is that each call to Channel.getInputStream() creates a
completely new instance of an InputStream with its own private buffering.
Therefore if you call getInputStream() multiple times (because for example
you passed a Channel object between several methods each of which needs to
access the InputStream) there is a chance that the later call will get an
InputStream that misses some/all of the expected data because it was already
received and buffered in the previous InputStream you obtained.

This seems like a rather odd and buggy behaviour, I would suggest that the
code be changed such that once an InputStream has been created for a Channel
the same instance is always returned.  Right now we've had to work around
this by ensuring we only call getInputStream() once and then passing around
the InputStream instance in addition to the Channel instance.

A similar problem seems to apply to Channel.getOutputStream() though this is
less likely to be encountered provided that you remember to always call
flush() on the OutputStream when you've done writing to it.

Thanks,

Rob

Re: [JSch-users] OpenSSL call within jsch

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

Am 14.10.2015 um 08:35 schrieb Pradeep Hallikeri:

>   Can somebody tell me if jsch is making any OpenSSL
> calls. If it does what is the purpose please?

OpenSSL is a C-library for SSL whereas JSCH is a Java-library
for doing SSH-operations. So, the answer is no. Why do you
think, that this is the case?


Cheers, Lothar

[JSch-users] OpenSSL call within jsch

[Pradeep H. <pra...@me...>]

Hi all, 
  Can somebody tell me if jsch is making any OpenSSL calls. If it does what is the purpose please?
   

Sent from my iPhone

[JSch-users] JSch Errors code

[Aviv B. <avi...@gm...>]

Hi,
Can you post a list of all the error codes that JSch is returning?
Thanks,
Aviv

[JSch-users] sftp implementation broken?

[Greg W. <g.w...@co...>]

I’m using 0.1.53 and recently came across the following problem. As a background, the SFTP protocol uses a command-response mechanism for communication between the client and server. It does not put any restrictions on the interleaving of commands, as each command is issued with a request ID number that is meant to be used to match to the corresponding reply. However the JSch implementation does not use the request ID for some commands (such as lstat()) so interleaving commands results in invalid responses.

Here’s an example:

	InputStream in = sftpChannel.get(“/path/to/file");
	byte[] b = new byte[100];
	int n = in.read(b);
	sftpChannel.lstat(“/path/to/another/file”);

At this point, lstat() throws an SftpException with message “End of file”.

The operation of this code is as follows. First, the call to get() results in an SSH_FXP_OPEN being sent to the server, along with the corresponding reply containing the file handle. The in.read(b) then causes JSch to issue an SSH_FXP_READ command, which for small files will read the whole file contents. The in.read(b) will return with the first 100 bytes at this point. Next, because the server is version 3, the only way to determine end of file is to issue another SSH_FXP_READ to see if the end of file has been reached. Since it has (the first READ read the whole file), the server returns a result of SSH_FXP_STATUS with error code SSH_FX_EOF, but this is not read by JSch yet. Now the call to lstat() sends a SSH_FXP_LSTAT command to the server. Because the server previously replied with an SSH_FXP_STATUS, and JSch does not check the request ID, it thinks the SSH_FXP_STATUS reply is the result of the SSH_FXP_LSTAT command. At this point lstat() fails with “End of file”.

To verify this is what is happening, insert “in.close()” between the read() and the lstat(). This flushes the last SSH_FXP_STATUS, so the response to the LSTAT command is correctly interpreted.

The only work around for this problem currently is to close all streams before issuing any other commands, or use a second sftp channel to issue interleaved commands.

Although this would not affect a command-line implementation of an sftp client (since interleaved commands are not possible), it does prevent JSch from fully utilizing the SFTP protocol.

Regards,
Greg

Re: [JSch-users] Session.connect() java.io.IOException: End of IO Stream Read

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

Am 07.10.2015 um 18:16 schrieb WILDCATS:

>   * Only happens using debugger, but happens consistently.

can you provide the output of the debug log?


Best regards, Lothar

[JSch-users] Session.connect() java.io.IOException: End of IO Stream Read

[WILDCATS <wil...@gm...>]

I've seen a couple posts relating to this but no answers.

I'm seeing the same issue with the following conditions:


   - latest jsch library
   - Session.connect fails on line 323, buf=read(buf);  and Exception is
   thrown on line 918, io.getByte(buf.buffer, buf.index, s2ccippher_size);

     KeyExchange kex=receive_kexinit(buf);

     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);
  }
}



   - Using ssh-agent and key authentication
   - IDEA 14.1.5
   - Only happens using debugger, but happens consistently.

[JSch-users] uploading huge data to proftpd hung up

[s. <148...@qq...>]

Hi all,

We are using jsch 0.1.43 along with proftpd, and proftpd has a channelWindowSize 1GB setting. Hung up sometimes happen if we update file larger than 1GB, if we try to upload again normally it works well.
The cause for this issue may root in waiting for the window adjust notification but that notification never received.

I see in the JSCH change log since version 0.1.51 there is abug fix as
- bugfix: hung-up in uploading huge data to ProFTPd without the config

          'SFTPClientMatch "JSCH.*" channelWindowSize 1GB'  FIXED.

Although we in fact have the config setting, will the fix work for us? Or anywhere we can check the fix code change details so we can check whether it may resolve our issue?


Thanks much
Allen

[JSch-users] InputStream.available() always returns 0

[JASON H. <J_H...@ms...>]

Using Windows 7 64 bit and jsch 0.1.53 I can connect fine as root to a local Debian 8 machine. with


Channel channel = session.openChannel("shell");


and I can read the input stream, but the channel.getInputStream().available() always returns 0 so I don't know when the input is complete. The examples included in jsch use the available() method for this purpose. Can I do anything to make available() behave as expected? Is there a workaround?


I am also doing


session.setConfig("StrictHostKeyChecking", "no");


but I assume this has no bearing on the problem...


Thanks for your help.


Jason

[JSch-users] JSchException "timeout in wating for rekeying process." caused by waiting for user answer

[Alexander K. <ale...@je...>]

Hi!

We are using JSch library 0.1.52 and have a difficulty dealing with 
timeout on establishing connection. The problem is that after a user 
answers prompt dialog "The authenticity of host '***' can't be 
established. RSA key fingerprint is ***. Are you sure you want to 
continue connecting?" JSchException with "timeout in wating for rekeying 
process." message is thrown by JSch Session (under some circumstances):
     com.jcraft.jsch.JSchException: timeout in wating for rekeying process.
         at com.jcraft.jsch.Session.write(Session.java:1339)
         at com.jcraft.jsch.Session.send_newkeys(Session.java:695)
         at com.jcraft.jsch.Session.connect(Session.java:348)
         ...

Steps to reproduce:
1. Be sure that the host we are connecting to is not in 
~/.ssh/known_hosts (e.g. empty it)
2. Set com.jcraft.jsch.Session#setUserInfo(UserInfo) with implementation 
that returns result from com.jcraft.jsch.UserInfo#promptYesNo() in 
several seconds
3. Invoke com.jcraft.jsch.Session#connect(int) with timeout value that 
is less than in step 2
4. Get JSchException

It seems that timeout value passed to Session#connect(int) method 
applies both to user answer time from UI and server interaction time. 
Might it be justly if user interaction had been excluded from timeout value?

Kind regards,
Alexander

[JSch-users] Support for poly1305-aes and aes256-gcm

[Shai A. <sh...@gm...>]

Hi,

First, thank you for jsch. I am using it in my android app SSH Persistent
Tunnels.
On behalf of one of my users , may I ask if support for  poly1305-aes and
aes256-gcm is planned?

Shai

Re: [JSch-users] How to deal with “Not on system console” using JSch?

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

please ignore

telnet was being used, not ssh

[]

Leo

On Thu, Jun 11, 2015 at 2:57 PM, Leonardo K. Shikida <sh...@gm...>
wrote:

> While trying to connect to a SunOS box, if I connect from the terminal, it
> works ok, but if I try via JSch, I get the message "Not on system console".
>
> I understand (quite, not much) the causes (see
> http://www.unix.com/unix-for-dummies-questions-and-answers/1496-not-system-console-connection-host-lost.html
> for some discussion) but my code have to use the root user to log in and I
> can't change the target box settings (such as commenting the variable
> CONSOLE for example.)
>
> So my doubt is related to JSch. Is there any setting to make it work in
> this scenario?
> TIA
>
> Leo
>

[JSch-users] How to deal with “Not on system console” using JSch?

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

While trying to connect to a SunOS box, if I connect from the terminal, it
works ok, but if I try via JSch, I get the message "Not on system console".

I understand (quite, not much) the causes (see
http://www.unix.com/unix-for-dummies-questions-and-answers/1496-not-system-console-connection-host-lost.html
for some discussion) but my code have to use the root user to log in and I
can't change the target box settings (such as commenting the variable
CONSOLE for example.)

So my doubt is related to JSch. Is there any setting to make it work in
this scenario?
TIA

Leo

[JSch-users] Encrypted RSA key is recognized as invalid key

[- - <ns...@fl...>]

There is an error when using RSA AES-128 with jsch.addIdentity()
When the key is encrypted (when it has a password), then it is not
recognized a valid key by the file KeyPair.java at the line 697.

This returns error messages as "invalid privatekey: [B@54a8ff21"

The method used to add an identity is:
 addIdentity(String, byte[] privatekey, byte[] publickey, byte[]
passphrase);

Keys without password work fine.

Similar issues:
http://sourceforge.net/p/jsch/mailman/message/31621834/
http://sourceforge.net/p/jsch/mailman/message/31623173/

[JSch-users] ANNOUNCE: JSch 0.1.53

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

Hi there,

JSch 0.1.53 has been released.
It is available at
  http://sourceforge.net/projects/jsch/files/jsch/0.1.53/jsch-0.1.53.zip/download
and its md5sum is 5c37c1fe15ee6690fcc18b305f2d2659
And you can get its byte code in jar file format at
  http://sourceforge.net/projects/jsch/files/jsch.jar/0.1.53/jsch-0.1.53.jar/download
and its md5sum is 14565d82bc94c312dce42a71c3d79034


Changes since version 0.1.52:
- bugfix: the rekey initiated by the remote may crash the session.
- change: Logjam: use ecdh-sha2-nistp* if available,
          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
- change: Logjam: diffie-hellman-group-exchange-sha256 and
          diffie-hellman-group-exchange-sha1 will use 2048-bit key on
          Java8's SunJCE, thanks to JDK-6521495 and JDK-7044060.
- change: key words for OpenSSH's config file should be case-insensitive.
- change: there should be the host name in "WARNING: REMOTE HOST
          IDENTIFICATION HAS CHANGED" message.

Re: [JSch-users] Modernize KexAlgorithms ordering (deprioritize DH group1)

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

Hi,

On Wed, May 27, 2015 at 10:19 PM, Patrick Toomey
<pat...@gi...> wrote:
>                                                                    I'd like to propose that the
> default key exchange algorithms be modernized and reordered as
> follows:
>
> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

Thank you for your suggestion.

We had added the support for ecdh-sha2-* methods to the latest version,
but we had hesitated to raise their priority.  Until now, we have not
heard the problem about them, so there are not problems to accept your
suggestion on the next version.
We have planed to release it by the end of this month.


Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
Skype callto://jcraft/
Twitter: http://twitter.com/ymnk
Facebook: http://facebook.com/aymnk

Re: [JSch-users] Execute ssh cmd on remote host

[Michael H. <che...@gm...>]

> On Thu, Apr 30, 2015 at 6:21 PM, Michael Hekel <che...@gm...> wrote:
>> I'm succesfully connecting with Jsch to our ssh jump server.
>> From there I would like to run a ssh cmd. I'm able to run simple commands
>> like "ls" but get the following errors if I run "ssh hostX ls" (where hostX
>> is a valid ip).
>>
>> System.err﹕ Permission denied, please try again.
>> System.err﹕ Permission denied, please try again.
>> System.err﹕ Permission denied
>> (publickey,gssapi-keyex,gssapi-with-mic,password).
>
> Try "ssh -v -v -v hostX ls"

Thanks. This helped understand the issue. I had to turn on agent forwarding:
((ChannelExec) channel).setAgentForwarding(true);

Regards,
   Michael