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

[JSch-users] Is JSch still alive

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

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] Exception Question

[CJ B. <CJ....@he...>]

Good Day,
We are using version 0.1.53 version of JSCH and running into an intermittent issue when connecting to an SSH server on a Solaris system.  Would like to get any insight as to what could be the cause.  Thank You!

Exception:
Caused by: com.jcraft.jsch.JSchException: verify: false
        at com.jcraft.jsch.Session.connect(Unknown Source)
        at com.jcraft.jsch.Session.connect(Unknown Source)

Solaris log entries when error encountered:
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: kex: server->client aes256-cbc hmac-sha1 none
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: Peer sent proposed langtags, ctos:
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: Peer sent proposed langtags, stoc:
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: We proposed langtags, ctos: de-LU,en-GB,en-IE,en-US,fr,fr-BE,fr-FR,fr-LU,nl-BE,en-CA,nl,nl-NL,i-d
efault
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: We proposed langtags, stoc: de-LU,en-GB,en-IE,en-US,fr,fr-BE,fr-FR,fr-LU,nl-BE,en-CA,nl,nl-NL,i-d
efault
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: dh_gen_key: priv key bits set: 240/512
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: bits set: 1000/2048
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEXDH_INIT
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: bits set: 1032/2048
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug2: kex_derive_keys
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: newkeys: mode 1
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: set_newkeys: setting new keys for 'out' mode
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS
Oct 11 08:25:15 ldnsbygu51 sshd[15563]: [ID 800047 auth.info] Received disconnect from 10.213.53.228: 3: com.jcraft.jsch.JSchException: verify: false


Solaris log entries when all works as expected:
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: kex: server->client aes256-cbc hmac-sha1 none
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: Peer sent proposed langtags, ctos:
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: Peer sent proposed langtags, stoc:
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: We proposed langtags, ctos: de-LU,en-GB,en-IE,en-US,fr,fr-BE,fr-FR,fr-LU,nl-BE,en-CA,nl,nl-NL,i-d
efault
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: We proposed langtags, stoc: de-LU,en-GB,en-IE,en-US,fr,fr-BE,fr-FR,fr-LU,nl-BE,en-CA,nl,nl-NL,i-d
efault
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: dh_gen_key: priv key bits set: 252/512
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: bits set: 1043/2048
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEXDH_INIT
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: bits set: 1003/2048
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug2: kex_derive_keys
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: newkeys: mode 1
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: set_newkeys: setting new keys for 'out' mode
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: newkeys: mode 0
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: set_newkeys: setting new keys for 'in' mode
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: KEX done
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: userauth-request for user sbyn service ssh-connection method none
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: attempt 0 initial attempt 0 failures 0 initial failures 0
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug3: Trying to reverse map address 10.213.53.228.
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug2: parse_server_config: config reprocess config len 937
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug2: input_userauth_request: setting up authctxt for sbyn
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug2: input_userauth_request: try method none
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: userauth_banner: sent
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.info] Failed none for sbyn from 10.213.53.228 port 62239 ssh2
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: userauth-request for user sbyn service ssh-connection method publickey
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug1: attempt 1 initial attempt 0 failures 0 initial failures 0
Oct 11 08:25:00 ldnsbygu51 sshd[15477]: [ID 800047 auth.debug] debug2: input_userauth_request: try method publickey
.... Continues to successful outcome

[JSch-users] SignatureDSA fix considered

[Fabian G. <fab...@mu...>]

Hello,

I would like to know if https://github.com/Jurrie/jsch-111-bugfix is being
considered to be added in the next release and in that case when it is
planned to be.

Thanks,

Fabian

Re: [JSch-users] SignatureDSA: incorrect conversion from mpint to ASN.1

[Jurrie O. <jsc...@ju...>]

On 03-09-17 20:20, Jurrie Overgoor wrote:
> We are using Apache VFS, which in turn uses JSCH to connect to SFTP. 
> Recently, my team and I stumbled upon a bug in JSCH which presents 
> itself when using Java 8 and SHA1withDSA. We are using JSCH 0.1.53, 
> but I tried 0.1.54 and the bug is still present. Other users appear to 
> be hitting this bug as well: https://sourceforge.net/p/jsch/bugs/111/
>
> I traced the problem down to SignatureDSA.java, which does conversion 
> from ASN.1 to mpint and from mpint to ASN.1. When verifying a hash, a 
> conversion from mpint to ASN.1 is done, just before the hash is passed 
> on to Java to actually do the verification. In the conversion from 
> mpint to ASN.1 I believe things are not done correctly. Leading 0x00 
> bytes are not stripped from the ASN.1 INTEGER as they should be. 
> Please note that Java 6 allows leading 0s, but Java 7 and 8 do not. 
> So, an IOException is thrown with message "Invalid encoding: redundant 
> leading 0s".
>
> So, when either r or s are integers that can be represented in less 
> than 20 bytes, we see redundant leading 0s. Sadly, r and s are 
> dependent on a random value k. So I whipped up a quick test that does 
> signatureDSA.sign() and signatureDSA.verify() over and over again. I 
> can reproduce the problem this way. I can not seem to trigger an error 
> when using SignatureRSA (representing SHA1withRSA) or SignatureECDSA 
> (representing SHA256withECDSA).
>
> Now, as I'm by no means an expert on this matter, I'd like to ask this 
> list if my observations are correct :)
>
> I made changes to SignatureDSA and am currently testing. Things seem 
> to work fine now. I can try to create a patch if it would be handy?

Hello everyone,

My alternative implementation of SignatureDSA.java is available as a 
Maven artifact. It's available at https://github.com/Jurrie/jsch-111-bugfix
Please let me know if it helped you, or if something is wrong.

With kind regards,

Jurrie

[JSch-users] SignatureDSA: incorrect conversion from mpint to ASN.1

[Jurrie O. <jsc...@ju...>]

Hello everyone,

We are using Apache VFS, which in turn uses JSCH to connect to SFTP. 
Recently, my team and I stumbled upon a bug in JSCH which presents 
itself when using Java 8 and SHA1withDSA. We are using JSCH 0.1.53, but 
I tried 0.1.54 and the bug is still present. Other users appear to be 
hitting this bug as well: https://sourceforge.net/p/jsch/bugs/111/

I traced the problem down to SignatureDSA.java, which does conversion 
from ASN.1 to mpint and from mpint to ASN.1. When verifying a hash, a 
conversion from mpint to ASN.1 is done, just before the hash is passed 
on to Java to actually do the verification. In the conversion from mpint 
to ASN.1 I believe things are not done correctly. Leading 0x00 bytes are 
not stripped from the ASN.1 INTEGER as they should be. Please note that 
Java 6 allows leading 0s, but Java 7 and 8 do not. So, an IOException is 
thrown with message "Invalid encoding: redundant leading 0s".

So, when either r or s are integers that can be represented in less than 
20 bytes, we see redundant leading 0s. Sadly, r and s are dependent on a 
random value k. So I whipped up a quick test that does 
signatureDSA.sign() and signatureDSA.verify() over and over again. I can 
reproduce the problem this way. I can not seem to trigger an error when 
using SignatureRSA (representing SHA1withRSA) or SignatureECDSA 
(representing SHA256withECDSA).

Now, as I'm by no means an expert on this matter, I'd like to ask this 
list if my observations are correct :)

I made changes to SignatureDSA and am currently testing. Things seem to 
work fine now. I can try to create a patch if it would be handy?

With kind regards,

Jurrie

[JSch-users] (no subject)

[Anoopps K. <ano...@gm...>]

[JSch-users] Multi-Factor Authentication

[Edward L. <edw...@mo...>]

Hi,

I am using Jsch in my development, and I see that 2FA is possible.  But, I
wanted to know if Jsch can support MFA at all.  I have been trying to see
if MFA is supported, but there isn't any examples or documentation on the
Jsch about MFA.

Thanks!

[JSch-users] Filename Encoding

[Christian S. <Chr...@so...>]

Hi all,
I try to access files on an SFTP server (using Jsch) which use for their names an encoding different from UTF-8 (in my case, ISO-8859-1). I have found an old discussion about that topic (https://sourceforge.net/p/jsch/mailman/message/26647296/) and a corresponding entry in the changelog for version 0.1.45 ("bugfix: sftp protocol version 3, 4 and 5 should allow only UTF-8 encoding"). However, I think that their might be some misunderstanding about the SFTP version numbers which leads to a still incorrect behavior of Jsch.
Looking at the specs (e.g. https://tools.ietf.org/html/draft-ietf-secsh-filexfer-00), I see that there are 14 versions of the specs. However, these do *not* correspond to the SFTP protocol version in a one-to-one manner. The SFTP protocol version for each of the spec versions is given in the section "Protocol Initialization". Looking at this section, we find that spec versions 0 to 2 describe protocol version 3, spec versions 3 and 4 describe protocol version 4, spec version 5 describe protocol version 5 and spec versions 6 to 13 describe protocol version 6. (This information can also be found at https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol#History_and_development.)
In the original protocol version 3, the filename encoding is undefined. In protocol versions 4 and 5, the filename encoding must be UTF-8, and in protocol version 6, the filename encoding can be negotiated. This has also been discussed in the old mailing list thread, but the versions mentioned in that thread were the spec versions, and not the protocol versions. So the current implementation ...

    if(3 <= sversion && sversion <= 5 &&
       !encoding.equals(UTF8)){
      throw new SftpException(SSH_FX_FAILURE,
                              "The encoding can not be changed for this sftp server.");
    }

... is not correct in my opinion and should be changed to ...

    if(4 <= sversion && sversion <= 5 &&
       !encoding.equals(UTF8)){
      throw new SftpException(SSH_FX_FAILURE,
                              "The encoding can not be changed for this sftp server.");
    }

... because only protocol versions 4 and 5 hardcoded the encoding to be UTF-8.

Regards,
Christian

PS: This mail doesn't seem to have come through the first time, so I resend it. Please excuse if it actually is a duplicate now.

[JSch-users] JSCH produces invalid identification string?

[<to...@qu...>]

The JSCH client produces an identification string of:
SSH-2.0-JSCH-<version>

According to the SSH transport layer protocol spec (RFC 4253):

"This identification string MUST be

      SSH-protoversion-softwareversion SP comments CR LF
...
Both the 'protoversion' and 'softwareversion' strings MUST consist of
   printable US-ASCII characters, with the exception of whitespace
   characters and the minus sign (-).
"

So according the strict interpretation of RFC 4253, "JSCH-<version>" isn't a valid software_version string, and it should be "JSCH_<version>" (underscore instead of dash).

Clearly ssh daemons aren't in the habit of checking this!

This is probably already known, and it's a minor issue. It's also unclear how easy it would be to change (potentially causing incompatibilities).

Anyway, just thought I'd comment in case this is considered a bigger issue?

Thanks.

Re: [JSch-users] special character set reading through JSCH

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

Hi,

Am 16.03.2017 um 10:18 schrieb PIYUSH VYAS:

> I am facing issue while downloading the file from one of my SFTP server.
> This file contains some nordic characters, which I am not able to see in
>  the downloaded file through channelSftp.get api.

Have you set the filename encoding?


Cheers, Lothar

[JSch-users] special character set reading through JSCH

[PIYUSH V. <vya...@gm...>]

Hello,

I am facing issue while downloading the file from one of my SFTP server.
This file contains some nordic characters, which I am not able to see in
the downloaded file through channelSftp.get api.

does anyone has any idea how can it be resolved?


Regards,
Piyush Vyas

[JSch-users] Not able to use JSCH jar our application.

[rahul k. <kat...@gm...>]

Hi,

I have a linux machine which I need to connect and send list of commands
using jsch java jar.

Following are the operations need to perform in linux server:
1. Connect linux server using ssh.
2. Execute login command and provide user name and password in linux shell
3. Show details of user.

Below are the commands which I need to automate using SSH connection.

[local_hots] mysh>login useradmin
Please enter user name: User1
Enter pin :
> ********                           ("123456" hint)

Authentication successful.

useradmin login successful.

Command Result : 0 (Success)
[local_host] mysh:> show user

I have connected linux server and send login command successfully through
java code but not able to enter user name and password.

Below is code which I am using

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.PrintStream;
import java.util.Properties;

import com.jcraft.jsch.Channel;
import com.jcraft.jsch.ChannelExec;
import com.jcraft.jsch.ChannelShell;
import com.jcraft.jsch.JSch;
import com.jcraft.jsch.JSchException;
import com.jcraft.jsch.Session;



public class JSchExampleSSHConnection {

    /**
     * JSch Example Tutorial
     * Java SSH Connection Program
     * @return
     */
    public static void main(String[] args) throws JSchException {
        String host="192.168.1.10";
        String user="admin";
        String password="linuxserver@123";



         JSch shell = new JSch();
        // get a new session

        Session session = null;

        String privateKey = "C:\\Users\\rahul\\.ssh\\id_rsa";

        try {
            shell.addIdentity(privateKey);
        } catch (JSchException e1) {
            // TODO Auto-generated catch block
            e1.printStackTrace();
        }

        try {
            session = shell.getSession(user, host, 22);

            System.out.println(session);
        //Session session = shell.getSession(userName, hostName, port);
        session.setPassword(password);
        Properties config = new Properties();
          config.put("StrictHostKeyChecking", ""
                  + "");
//          java.util.Properties config=new java.util.Properties();

          session.setConfig(config);

            session.connect();

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

              OutputStream ops = channel.getOutputStream();
              PrintStream ps = new PrintStream(ops, true);

              channel.connect();
              //give commands to be executed inside println.and can have
any no of commands sent.



              ps.println("login useradmin"");
              ps.println("User1");
              ps.println("password");


              ps.close();




              InputStream in=channel.getInputStream();



              byte[] bt=new byte[1024];


            while(true)
              {
                   while(in.available()>0)
                   {
                       int i=in.read(bt, 0, 1024);
                       if(i<0)
                           break;
                       strCmdOutput = new String(bt, 0, i);
                       System.out.println(strCmdOutput);

                   }
                   if(channel.isClosed())
                   {
                       break;
                   }

                   Thread.sleep(10000);
                   channel.disconnect();

                   session.disconnect();



        }


        }catch (JSchException | IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

 catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }


    }

}


Thanks & Regards
Rahul Katoch

Re: [JSch-users] [solved] jsch-0.1.54.jar throws com.jcraft.jsch.JSchException: invalid privatekey

[Tim B. <tb...@al...>]

I'm glad to hear you got it working, though I'm surprised the command you
ran, without -t rsa, worked as you described.  No matter, if it solved your
problem then that's what matters.

Tim

On Tue, Nov 8, 2016 at 1:21 PM, Erik Wasser <eri...@na...> wrote:

> On 08.11.2016 06:39, Tim Bain wrote:
>
> > This is the 0.1.53 source:
> > http://grepcode.com/file/repo1.maven.org/maven2/com.
> jcraft/jsch/0.1.53/com/jcraft/jsch/KeyPair.java#KeyPair
> > Presumably the 0.1.54 source isn't much different, since the line
> > numbers match exactly.
> >
> > Look at lines 634-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.  Did you maybe forget the
> > "-t rsa" argument when generating the 4096-bit key?  I'm not sure why
> > the output would include "(RSA)" if that happened, but at the same time
> > the content you showed us doesn't appear to be an RSA key...
>
> Hi. Thanks for the answer. You've pushed me into the right direction.
> I've just recreated a new key with the following command:
>
> > ssh-keygen -b 4096 -f .ssh/foo
>
> And everything is fine and the first line indicates an RSA. And voilà:
> Jsch is working just fine with a 4096 bits/RSA key.
>
> So my key was just bad, like the error messages indicated it. B-)
>
> Thanks for the help.
>
> --
> So long... Erik
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users
>

Re: [JSch-users] [solved] jsch-0.1.54.jar throws com.jcraft.jsch.JSchException: invalid privatekey

[Erik W. <eri...@na...>]

On 08.11.2016 06:39, Tim Bain wrote:

> This is the 0.1.53 source:
> http://grepcode.com/file/repo1.maven.org/maven2/com.jcraft/jsch/0.1.53/com/jcraft/jsch/KeyPair.java#KeyPair 
> Presumably the 0.1.54 source isn't much different, since the line
> numbers match exactly.
> 
> Look at lines 634-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.  Did you maybe forget the
> "-t rsa" argument when generating the 4096-bit key?  I'm not sure why
> the output would include "(RSA)" if that happened, but at the same time
> the content you showed us doesn't appear to be an RSA key...

Hi. Thanks for the answer. You've pushed me into the right direction.
I've just recreated a new key with the following command:

> ssh-keygen -b 4096 -f .ssh/foo

And everything is fine and the first line indicates an RSA. And voilà:
Jsch is working just fine with a 4096 bits/RSA key.

So my key was just bad, like the error messages indicated it. B-)

Thanks for the help.

-- 
So long... Erik

Re: [JSch-users] jsch-0.1.54.jar throws com.jcraft.jsch.JSchException: invalid privatekey

[Tim B. <tb...@al...>]

This is the 0.1.53 source:
http://grepcode.com/file/repo1.maven.org/maven2/com.jcraft/jsch/0.1.53/com/jcraft/jsch/KeyPair.java#KeyPair
Presumably the 0.1.54 source isn't much different, since the line numbers
match exactly.

Look at lines 634-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.  Did you maybe forget the "-t
rsa" argument when generating the 4096-bit key?  I'm not sure why the
output would include "(RSA)" if that happened, but at the same time the
content you showed us doesn't appear to be an RSA key...

Tim

On Mon, Nov 7, 2016 at 3:30 PM, Erik Wasser <eri...@na...> wrote:

> On 07.11.2016 10:38, Lothar Kimmeringer wrote:
>
> > Hi,
> >
> > Am 04.11.2016 um 22:20 schrieb Erik Wasser:
> >
> >> Why is that? Why are 4096 bits RSA keys invalid? How can I fix this
> issue?
> >
> > Maybe a limit of a JVM without Unlimited Strength Cryptography Extension
> > being installed?
>
> Thanks for the feedback.
>
> I've download the file 'jce_policy-8.zip'
> (http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-
> 2133166.html)
> and extracted the files 'US_export_policy.jar' and 'local_policy.jar'
> to the directory '/usr/java/jdk1.8.0_112/jre/lib/security' (overwriting
> the old ones).
>
> Nothing changed (and I've double checked if this is the right java
> version I'm using).
>
> If I switch to 'java-1.8.0-openjdk.x86_64' the error still remains so I
> think it's not a (Oracle-)Java problem.
>
> Here's the stack trace:
>
> com.jcraft.jsch.JSchException: invalid privatekey: [B@282ba1e
>         at com.jcraft.jsch.KeyPair.load(KeyPair.java:664)
>         at com.jcraft.jsch.KeyPair.load(KeyPair.java:561)
>         at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:40)
>         at com.jcraft.jsch.JSch.addIdentity(JSch.java:407)
>         at com.jcraft.jsch.JSch.addIdentity(JSch.java:367)
>         at UserAuthPubKey.main(UserAuthPubKey.java:29)
>
> I've debugged a little bit further and replaced the lines
>
> > -----BEGIN OPENSSH PRIVATE KEY-----
> > ...
> > -----BEGIN OPENSSH PRIVATE KEY-----
>
> with
>
> > -----BEGIN RSA PRIVATE KEY-----
> > ...
> > -----BEGIN RSA PRIVATE KEY-----
>
> And the stack trace changed a little bit:
>
> com.jcraft.jsch.JSchException: invalid privatekey: [B@f5f2bb7
>         at com.jcraft.jsch.KeyPair.load(KeyPair.java:948)
>         at com.jcraft.jsch.KeyPair.load(KeyPair.java:561)
>         at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:40)
>         at com.jcraft.jsch.JSch.addIdentity(JSch.java:407)
>         at com.jcraft.jsch.JSch.addIdentity(JSch.java:367)
>         at UserAuthPubKey.main(UserAuthPubKey.java:29)
>
> Any ideas?
>
> --
> So long... Erik
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users
>

Re: [JSch-users] jsch-0.1.54.jar throws com.jcraft.jsch.JSchException: invalid privatekey

[Erik W. <eri...@na...>]

On 07.11.2016 10:38, Lothar Kimmeringer wrote:

> Hi,
> 
> Am 04.11.2016 um 22:20 schrieb Erik Wasser:
> 
>> Why is that? Why are 4096 bits RSA keys invalid? How can I fix this issue?
> 
> Maybe a limit of a JVM without Unlimited Strength Cryptography Extension
> being installed?

Thanks for the feedback.

I've download the file 'jce_policy-8.zip'
(http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html)
and extracted the files 'US_export_policy.jar' and 'local_policy.jar'
to the directory '/usr/java/jdk1.8.0_112/jre/lib/security' (overwriting
the old ones).

Nothing changed (and I've double checked if this is the right java
version I'm using).

If I switch to 'java-1.8.0-openjdk.x86_64' the error still remains so I
think it's not a (Oracle-)Java problem.

Here's the stack trace:

com.jcraft.jsch.JSchException: invalid privatekey: [B@282ba1e
        at com.jcraft.jsch.KeyPair.load(KeyPair.java:664)
        at com.jcraft.jsch.KeyPair.load(KeyPair.java:561)
        at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:40)
        at com.jcraft.jsch.JSch.addIdentity(JSch.java:407)
        at com.jcraft.jsch.JSch.addIdentity(JSch.java:367)
        at UserAuthPubKey.main(UserAuthPubKey.java:29)

I've debugged a little bit further and replaced the lines

> -----BEGIN OPENSSH PRIVATE KEY-----
> ...
> -----BEGIN OPENSSH PRIVATE KEY-----

with

> -----BEGIN RSA PRIVATE KEY-----
> ...
> -----BEGIN RSA PRIVATE KEY-----

And the stack trace changed a little bit:

com.jcraft.jsch.JSchException: invalid privatekey: [B@f5f2bb7
        at com.jcraft.jsch.KeyPair.load(KeyPair.java:948)
        at com.jcraft.jsch.KeyPair.load(KeyPair.java:561)
        at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:40)
        at com.jcraft.jsch.JSch.addIdentity(JSch.java:407)
        at com.jcraft.jsch.JSch.addIdentity(JSch.java:367)
        at UserAuthPubKey.main(UserAuthPubKey.java:29)

Any ideas?

-- 
So long... Erik

Re: [JSch-users] jsch-0.1.54.jar throws com.jcraft.jsch.JSchException: invalid privatekey

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

Hi,

Am 04.11.2016 um 22:20 schrieb Erik Wasser:

> Why is that? Why are 4096 bits RSA keys invalid? How can I fix this issue?

Maybe a limit of a JVM without Unlimited Strength Cryptography Extension
being installed?


Cheers, Lothar

[JSch-users] jsch-0.1.54.jar throws com.jcraft.jsch.JSchException: invalid privatekey

[Erik W. <eri...@na...>]

Summary: Is there a known problem with SSH and RSA keys with 4096 bits?

Recently I noticed that using the SFTP plugin of my favorite editor
jedit wasn't working anymore. To make a long story short: I've drilled
down the problem to the library JSch (jsch-0.1.54.jar) and compiled one
of your example:

I'm using UserAuthPubKey.java
(http://www.jcraft.com/jsch/examples/UserAuthPubKey.java.html) example
with a 2 different keys:

% ssh-keygen -lf ~/.ssh/id_rsa-2048
2048 SHA256:e8G+h4MsuUMZYUbk2jhk18FGQ88JNB/Lpxzpw/kfAeY
eri...@na... (RSA)

% ssh-keygen -lf ~/.ssh/id_rsa-4096
4096 SHA256:3M4Mx6KUodWqWfdVWOr0cavdapf8y+zIH3bXcl7umbo
eri...@na... (RSA)

The first one is working fine, that last one returns the following message

> com.jcraft.jsch.JSchException: invalid privatekey: [B@f5f2bb7

throwing from the code snippet

> jsch.addIdentity(chooser.getSelectedFile().getAbsolutePath());

If've modified UserAuthPubKey.java a little bit to drill down the
JSchException. Here's the relevant part:

    if(returnVal == JFileChooser.APPROVE_OPTION) {
        System.out.println("You chose "+
            chooser.getSelectedFile().getAbsolutePath()+".");
        System.out.println("before jsch.addIdentity()");
        jsch.addIdentity(chooser.getSelectedFile().getAbsolutePath());
        System.out.println("after jsch.addIdentity()");
    }

Compiling (using the oracle JDK 1.8.0_101):

% javac -classpath jsch.jar UserAuthPubKey.java

Starting and using the 2048 bit key:

% java -classpath jsch.jar:. UserAuthPubKey
You chose /home/brassel/.ssh/id_rsa-2048.
before jsch.addIdentity()
after jsch.addIdentity()
...Program goes on...

Starting and using the 4096 bit key:

% java -classpath jsch.jar:. UserAuthPubKey
You chose /home/brassel/.ssh/id_rsa-4096.
before jsch.addIdentity()
com.jcraft.jsch.JSchException: invalid privatekey: [B@48140564
...Program ends here...

Why is that? Why are 4096 bits RSA keys invalid? How can I fix this issue?

-- 
So long... Erik

[JSch-users] Source code repository

[Peter H. <pet...@gm...>]

Is the source code for JSch available from a VCS ?

I can't seem to find it.

Yes, I know the source is available from the ZIP file, but that doesn't
really allow me to track changes from one release to the next.

Regards

Peter

[JSch-users] End of IO Stream when connecting to few servers

[Preetham K. <ka...@gm...>]

Hi,
 I am trying to connect to a SloarWinds SFTP server using JSCH. It fails
with the below error. I have noticed this happens with a bunch of other
SFTP servers as well, but works fine on an OpenSSH server. I am guessing
this is some kind of config issue and any pointers would help.

Thanks,
 ~preetham

--log ---



KEX=diffie-hellman-group1-sha1
Connecting to 172.16.5.71 port 22
Connection established
Remote version string: SSH-1.99-WeOnlyDo 2.2.9
Local version string: SSH-2.0-JSCH-0.1.53
CheckCiphers:
aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
CheckKexes:
diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
SSH_MSG_KEXINIT sent
SSH_MSG_KEXINIT received
kex: server: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
kex: server: ssh-rsa
kex: server:
aes128-cbc,aes128-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes192-ctr,aes256-cbc,aes256-ctr,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,
rij...@ly...,cast128-cbc
kex: server:
aes128-cbc,aes128-ctr,3des-cbc,blowfish-cbc,aes192-cbc,aes192-ctr,aes256-cbc,aes256-ctr,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,
rij...@ly...,cast128-cbc
kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,none
kex: server: hmac-sha1,hmac-sha1-96,hmac-md5,none
kex: server: zlib,none
kex: server: zlib,none
kex: server:
kex: server:
kex: client: diffie-hellman-group1-sha1
kex: client:
ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
kex: client:
none,blowfish-cbc,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,3des-ctr,arcfour,arcfour128,arcfour256
kex: client:
none,blowfish-cbc,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,3des-ctr,arcfour,arcfour128,arcfour256
kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
kex: client: none
kex: client: none
kex: client:
kex: client:
kex: server->client blowfish-cbc hmac-md5 none
kex: client->server blowfish-cbc hmac-md5 none
SSH_MSG_KEXDH_INIT sent
expecting SSH_MSG_KEXDH_REPLY
ssh_rsa_verify: signature true
Permanently added '172.16.5.71' (RSA) to the list of known hosts.
- Permanently added '172.16.5.71' (RSA) to the list of known hosts.
SSH_MSG_NEWKEYS sent
SSH_MSG_NEWKEYS received
SSH_MSG_SERVICE_REQUEST sent
Disconnecting from 172.16.5.71 port 22

Re: [JSch-users] known hosts bug, sort of

[Stephan C. <ste...@ca...>]

Sorry to pick up this old topic

I ran this week into the same problem except my known_hosts file 
contains ecdsa-sha2-nistp256 keys.
Since OpenSSH also determines the order of the host key algorithms by 
checking the known_hosts file I would like you to reconsider adding such 
an algorithm.

Here an extract of an OpenSSH debug log:

debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.2
debug1: Remote protocol version 2.0, remote software version 
OpenSSH_5.9p1 Debian-5ubuntu1.10
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.10 pat OpenSSH_5* compat 
0x0c000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to xxxx.com:22 as 'git'
debug3: hostkeys_foreach: reading file "/home/yyyy/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file 
/home/yyyy/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from xxxx.com
debug3: order_hostkeyalgs: prefer hostkeyalgs: 
ecd...@op...,ecd...@op...,ecd...@op...,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received


I currently fixed this by setting the the "server_host_key" config. 
Never the less this is sub-optimal as I need to repeat this for every 
new project that uses JSch. It is prone to break if our IT department 
decides to change the host key algorithm.

Thanks

Stephan

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

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

Yeah looks like a similar issue. But I am not familiar with JSCH source code to figure out how to change that to make it work.


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

I had to google to figure out what "rekeying" means and came across this interesting thread
about a similar problem the paramiko client used to have at 1gb.

https://github.com/paramiko/paramiko/issues/49
[https://avatars1.githubusercontent.com/u/1007176?v=3&s=400]<https://github.com/paramiko/paramiko/issues/49>

Transfer fails at 1GB: rekey window too small, hard-coded ...<https://github.com/paramiko/paramiko/issues/49>
github.com
First off, thanks for the great work with paramiko. At 1GB of data transferred over sftp, paramiko initiates a ssh rekey request and then sets a limit on the number ...

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

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

I had to google to figure out what "rekeying" means and came across this
interesting thread
about a similar problem the paramiko client used to have at 1gb.

https://github.com/paramiko/paramiko/issues/49

Re: [JSch-users] Authentication with password & key

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

Have you tried

config.put("PreferredAuthentications", "publickey,keyboard-interactive,password");

________________________________
From: Răzvan Rotaru <raz...@gm...>
Sent: Friday, October 14, 2016 11:49:45 AM
To: jsc...@li...
Subject: [JSch-users] Authentication with password & key

Hi Jsch community,

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

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

Many thanks,
Razvan

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

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

Anyone? We are heavily invested in JSCH to look for another option. Are there any possible workarounds?

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


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