Hi All,

we did further analysis and the findings are given below.

The issue is narrowed down to a read function in ChannelSession.java file.
public void run(){
        Buffer buf=new Buffer((rmpsize));
while(isConnected() &&
         thread!=null &&
            io!=null &&

The third parameter to the read() gives the maximum number of bytes that should be read. This varies based on the ssh servers we use For OpenSSH server and libSSH server the values were 32670 and 34902 respectively. The session hung for both these servers. Hard coding this third parameter to 26608 led to successful sessions with OpenSsh and LibSsh.  Values beyond 26608 when used for the 3rd parameter led to session hang. This seems to be the problem with java’s read API for Buffer class.

The third parameter for the read() is derived from the “rmpsize” which is Remote max packet size which is received from the SSH server.

SSH RFC 4253 section 6.1 states that
 “6.1.  Maximum Packet Length

   All implementations MUST be able to process packets with an
   uncompressed payload length of 32768 bytes or less and a total packet
   size of 35000 bytes or less (including 'packet_length',
   'padding_length', 'payload', 'random padding', and 'mac').  The
   maximum of 35000 bytes is an arbitrarily chosen value that is larger
   than the uncompressed length noted above.”

So the values  32768 and 35000 for max packet size is valid as per the RFC. But JSch is not compliant with this.
The RFC 4254  states that
Section 5.1:
  “The 'maximum packet size' specifies the
   maximum size of an individual data packet that can be sent to the
   sender.  For example, one might want to use smaller packets for
   interactive connections to get better interactive response on slow
Hence inorder to achieve this we have done the following change in code.
and this works fine.
-->diff ChannelSession.java_bkup ChannelSession.java
<     Buffer buf=new Buffer(rmpsize);
>     Buffer buf=new Buffer(1000);
Kindly let us know if there are any comments on this.


On Thu, Apr 10, 2014 at 6:58 PM, aarthit 2014 <aarthit2014@gmail.com> wrote:

Hi All,


We are using Jsch-0.1.51 for establishing SSH sessions with our product. We face the following issue:


The shell hangs and we are not able to enter any commands or text in the screen.


We tested the following scenarios and these are our observations:




SSH version

SSH server stack



Scientific Linux release 6.0


Openssh 5.3

SSH session establishment fails with the message “Invalid server’s version string”


Scientific Linux release 6.4


OpenSSH 5.3

SSH session establishment fails with the message “Invalid server’s version string”


Linux-CentOS release 5.5


OpenSSH 4.3

Authentication succeeds and  session gets established. The SSH shell prompt is also received.

The session freezes there and doesn’t work.


Scientific Linux 6.0


Libssh 0.6.1

Authentication succeeds and the session is established the shell prompt is also received but the session freezes.


For the above 1st 3 cases The establishment of the SSH session is not consistent ,out of 10 trials we could see only twice the session is getting established all the other attempts resulted in a failure.


The 4th case did not give us a successful session In any of the instances.

In the 1st two cases we changed the version to 2 and checked and in that we see the result that session gets established but freezes.


This problem of session hang is consistent when the client is run from a windows XP machine  running with java version like

java version "1.6.0_20" . java version "1.6.0_01" .


When run from a windows 7 PC with java version "1.6.0_22" we see out of 10 times we see 2 times the session gets established and other times it is not getting established.



Kindly let us know , why do we see the discrepancy in establishing the sessions. And most of the times we are not seeing a successful shell. Do we have to change any settings in the jsch config file. Or any other modifications has to be done. Kindly let us know if any solution is available for this and the reason for the above behavior