jsch-users Mailing List for JSch (Page 2)
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: Lothar K. <jo...@ki...> - 2017-11-13 08:31:56
|
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: CJ B. <CJ....@he...> - 2017-11-01 23:24:30
|
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 |
From: Fabian G. <fab...@mu...> - 2017-09-14 15:31:12
|
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 |
From: Jurrie O. <jsc...@ju...> - 2017-09-06 08:15:42
|
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 |
From: Jurrie O. <jsc...@ju...> - 2017-09-03 18:40:27
|
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 |
From: Anoopps K. <ano...@gm...> - 2017-07-12 15:57:26
|
From: Edward L. <edw...@mo...> - 2017-06-12 21:20:55
|
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! |
From: Christian S. <Chr...@so...> - 2017-05-05 06:11:55
|
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. |
From: <to...@qu...> - 2017-05-02 10:47:30
|
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. |
From: Lothar K. <jo...@ki...> - 2017-03-16 11:06:48
|
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 |
From: PIYUSH V. <vya...@gm...> - 2017-03-16 09:18:53
|
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 |
From: rahul k. <kat...@gm...> - 2016-12-02 05:56:03
|
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 |
From: Tim B. <tb...@al...> - 2016-11-09 02:56:17
|
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 > |
From: Erik W. <eri...@na...> - 2016-11-08 20:21:41
|
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 |
From: Tim B. <tb...@al...> - 2016-11-08 05:39:48
|
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 > |
From: Erik W. <eri...@na...> - 2016-11-07 22:31:07
|
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 |
From: Lothar K. <jo...@ki...> - 2016-11-07 09:43:46
|
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 |
From: Erik W. <eri...@na...> - 2016-11-04 21:20:14
|
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 |
From: Peter H. <pet...@gm...> - 2016-10-25 23:04:23
|
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 |
From: Preetham K. <ka...@gm...> - 2016-10-25 17:46:43
|
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 |
From: Stephan C. <ste...@ca...> - 2016-10-15 01:44:40
|
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 |
From: Vikas V. <vvi...@ho...> - 2016-10-14 17:28:53
|
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 ... |
From: Alan E. <ala...@gm...> - 2016-10-14 16:56:20
|
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 |
From: Vikas V. <vvi...@ho...> - 2016-10-14 16:39:41
|
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 |
From: Vikas V. <vvi...@ho...> - 2016-10-14 16:38:51
|
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 |