Thread: [JSch-users] JSch on Vmware ESX 3.0
Status: Alpha
Brought to you by:
ymnk
From: Palani v. <pal...@ya...> - 2007-07-27 14:32:38
|
=0A=09=09=09Hi all, =0A=0A I tried JSch to scp a file to a VMware E= SX 3.0 host and the session could not be established because of =0A=0A =0A= =0AAlgorithm negotiation fail =0A=0A=09at com.jcraft.jsch.Session.receive_k= exinit(Unknown Source) =0A=0A=09at com.jcraft.jsch.Session.connect(Unknown = Source) =0A=0A=09at com.jcraft.jsch.Session.connect(Unknown Source) =0A=0A = =0A=0AHere is the output of ssh -v <host> =0A=0A =0A=0A =0A=0AOpenSSH_3.5p1= , SSH protocols 1.5/2.0, OpenSSL 0x009060df =0A=0Adebug1: Reading configura= tion data /etc/ssh/ssh_config =0A=0Adebug1: Applying options for * =0A=0Ade= bug1: Rhosts Authentication disabled, originating port will not be trusted.= =0A=0Adebug1: ssh_connect: needpriv 0 =0A=0Adebug1: Connecting to vmmdev1.= ind.hp.com [15.154.69.89] port 22. =0A=0Adebug1: Connection established. = =0A=0Adebug1: identity file /root/.ssh/identity type -1 =0A=0Adebug1: ident= ity file /root/.ssh/id_rsa type -1 =0A=0Adebug1: identity file /root/.ssh/i= d_dsa type -1 =0A=0Adebug1: Remote protocol version 2.0, remote software ve= rsion OpenSSH_3.6.1p2 =0A=0Adebug1: match: OpenSSH_3.6.1p2 pat OpenSSH* =0A= =0Adebug1: Enabling compatibility mode for protocol 2.0 =0A=0Adebug1: Local= version string SSH-2.0-OpenSSH_3.5p1 =0A=0Adebug1: SSH2_MSG_KEXINIT sent = =0A=0Adebug1: SSH2_MSG_KEXINIT received =0A=0Adebug1: kex: server->client a= es128-cbc hmac-md5 none =0A=0Adebug1: kex: client->server aes128-cbc hmac-m= d5 none =0A=0Adebug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent =0A=0Adebug1: expect= ing SSH2_MSG_KEX_DH_GEX_GROUP =0A=0Adebug1: dh_gen_key: priv key bits set: = 132/256 =0A=0Adebug1: bits set: 1632/3191 =0A=0Adebug1: SSH2_MSG_KEX_DH_GEX= _INIT sent =0A=0Adebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY =0A=0Adebug1: = Host 'vmmdev1.ind.hp.com' is known and matches the RSA host key. =0A=0Adebu= g1: Found key in /root/.ssh/known_hosts:4 =0A=0Adebug1: bits set: 1592/3191= =0A=0Adebug1: ssh_rsa_verify: signature correct =0A=0Adebug1: kex_derive_k= eys =0A=0Adebug1: newkeys: mode 1 =0A=0Adebug1: SSH2_MSG_NEWKEYS sent =0A= =0Adebug1: waiting for SSH2_MSG_NEWKEYS =0A=0Adebug1: newkeys: mode 0 =0A= =0Adebug1: SSH2_MSG_NEWKEYS received =0A=0Adebug1: done: ssh_kex2. =0A=0Ade= bug1: send SSH2_MSG_SERVICE_REQUEST =0A=0Adebug1: service_accept: ssh-usera= uth =0A=0Adebug1: got SSH2_MSG_SERVICE_ACCEPT =0A=0Adebug1: authentications= that can continue: publickey,password,keyboard-interacti =0A=0Ave,hostbase= d =0A=0Adebug1: next auth method to try is publickey =0A=0Adebug1: try priv= key: /root/.ssh/identity =0A=0Adebug1: try privkey: /root/.ssh/id_rsa =0A= =0Adebug1: try privkey: /root/.ssh/id_dsa =0A=0Adebug1: next auth method to= try is keyboard-interactive =0A=0Adebug1: authentications that can continu= e: publickey,password,keyboard-interacti =0A=0Ave,hostbased =0A=0Adebug1: n= ext auth method to try is password =0A=0A =0A=0A =0A=0A =0A=0AAlso the sshd= _config file on the ESX 3.0 host is : =0A=0A =0A=0A# $OpenBSD: sshd_c= onfig,v 1.59 2002/09/25 11:17:16 markus Exp $ =0A=0A =0A=0A# This is the ss= hd server system-wide configuration file. See =0A=0A# sshd_config(5) for m= ore information. =0A=0A =0A=0A# This sshd was compiled with PATH=3D/usr/loc= al/bin:/bin:/usr/bin =0A=0A =0A=0A# The strategy used for options in the de= fault sshd_config shipped with =0A=0A# OpenSSH is to specify options with t= heir default value where =0A=0A# possible, but leave them commented. Uncom= mented options change a =0A=0A# default value. =0A=0A =0A=0A#Port 22 =0A=0A= Protocol 2 =0A=0A#ListenAddress 0.0.0.0 =0A=0A#ListenAddress :: =0A=0A =0A= =0A# HostKey for protocol version 1 =0A=0A#HostKey /etc/ssh/ssh_host_key = =0A=0A# HostKeys for protocol version 2 =0A=0A#HostKey /etc/ssh/ssh_host_rs= a_key =0A=0A#HostKey /etc/ssh/ssh_host_dsa_key =0A=0A =0A=0A# Lifetime and = size of ephemeral version 1 server key =0A=0A#KeyRegenerationInterval 3600 = =0A=0A#ServerKeyBits 768 =0A=0A =0A=0A# Logging =0A=0A#obsoletes QuietMode = and FascistLogging =0A=0ASyslogFacility AUTH =0A=0ALogLevel VERBOSE =0A=0A = =0A=0A# Authentication: =0A=0A =0A=0A#LoginGraceTime 120 =0A=0APermitRootLo= gin yes =0A=0A#StrictModes yes =0A=0A =0A=0A#RSAAuthentication yes =0A=0A#P= ubkeyAuthentication yes =0A=0A#AuthorizedKeysFile .ssh/authorized_keys = =0A=0A =0A=0A# possible, but leave them commented. Uncommented options cha= nge a =0A=0A# default value. =0A=0A =0A=0A#Port 22 =0A=0AProtocol 2 =0A=0A#= ListenAddress 0.0.0.0 =0A=0A#ListenAddress :: =0A=0A =0A=0A# HostKey for pr= otocol version 1 =0A=0A#HostKey /etc/ssh/ssh_host_key =0A=0A# HostKeys for = protocol version 2 =0A=0A#HostKey /etc/ssh/ssh_host_rsa_key =0A=0A#HostKey = /etc/ssh/ssh_host_dsa_key =0A=0A =0A=0A# Lifetime and size of ephemeral ver= sion 1 server key =0A=0A#KeyRegenerationInterval 3600 =0A=0A#ServerKeyBits = 768 =0A=0A =0A=0A# Logging =0A=0A#obsoletes QuietMode and FascistLogging = =0A=0ASyslogFacility AUTH =0A=0ALogLevel VERBOSE =0A=0A =0A=0A# Authenticat= ion: =0A=0A =0A=0A#LoginGraceTime 120 =0A=0APermitRootLogin yes =0A=0A#Stri= ctModes yes =0A=0A =0A=0A#RSAAuthentication yes =0A=0A#PubkeyAuthentication= yes =0A=0A#AuthorizedKeysFile .ssh/authorized_keys =0A=0A =0A=0A# rhos= ts authentication should not be used =0A=0A#RhostsAuthentication no =0A=0A#= Don't read the user's ~/.rhosts and ~/.shosts files =0A=0A#IgnoreRhosts ye= s =0A=0A# For this to work you will also need host keys in /etc/ssh/ssh_kno= wn_hosts =0A=0A#RhostsRSAAuthentication no =0A=0A# similar for protocol ver= sion 2 =0A=0AHostbasedAuthentication yes =0A=0A =0A=0A# Change to yes if yo= u don't trust ~/.ssh/known_hosts for =0A=0AHostbasedAuthentication yes =0A= =0A#IgnoreUserKnownHosts no =0A=0A =0A=0A# To disable tunneled clear text p= asswords, change to no here! =0A=0A#PasswordAuthentication yes =0A=0A#Permi= tEmptyPasswords no =0A=0A =0A=0A# Change to no to disable s/key passwords = =0A=0A#ChallengeResponseAuthentication yes =0A=0A =0A=0A# Kerberos options = =0A=0A#KerberosAuthentication no =0A=0A#KerberosOrLocalPasswd yes =0A=0A#Ke= rberosTicketCleanup yes =0A=0A =0A=0A#AFSTokenPassing no =0A=0A =0A=0A# Ker= beros TGT Passing only works with the AFS kaserver =0A=0A#KerberosTgtPassin= g no =0A=0A =0A=0A# Set this to 'yes' to enable PAM keyboard-interactive au= thentication =0A=0A# Warning: enabling this may bypass the setting of 'Pass= wordAuthentication' =0A=0A#PAMAuthenticationViaKbdInt no =0A=0A =0A=0A#X11F= orwarding no =0A=0A#X11DisplayOffset 10 =0A=0A#X11UseLocalhost yes =0A=0A#P= rintMotd yes =0A=0A#PrintLastLog yes =0A=0A#KeepAlive yes =0A=0A#UseLogin n= o =0A=0A#UsePrivilegeSeparation yes =0A=0A#PermitUserEnvironment no =0A=0A#= Compression yes =0A=0A =0A=0A#MaxStartups 10 =0A=0A# no default banner path= =0A=0A#Banner /some/path =0A=0A#VerifyReverseMapping no =0A=0A#ShowPatchLe= vel no =0A=0A =0A=0A# override default of no subsystems =0A=0ASubsystem = sftp /usr/libexec/openssh/sftp-server =0A=0ACiphers aes256-cbc,aes128= -cbc =0A=0A =0A=0A =0A=0AI am guessing that some tweaking to the config fil= e should solve the issue. =0A=0ACan you please throw some light on this??? = Or is this configuration not supported??? =0A=0A =0A=0AThanks, =0A=0APal=0A= =09=09=09=0A=0A=0A=0A ________________________________________________= ___________=0AYahoo! Answers - Got a question? Someone out there knows the = answer. Try it=0Anow.=0Ahttp://uk.answers.yahoo.com/ |
From: <ym...@jc...> - 2007-07-30 06:34:03
|
Hi, +-From: Palani velRajan <pal...@ya...> -- |_Date: Fri, 27 Jul 2007 07:32:23 -0700 (PDT) __________ | | I tried JSch to scp a file to a VMware ESX 3.0 host and |the session could not be established because of | Algorithm negotiation fail ... |Also the sshd_config file on the ESX 3.0 host is : ... |Ciphers aes256-cbc,aes128-cbc That line is the reason. By the default, jsch does not support the ciphers aes*-cbc, but it can handle them on J2SE 1.4.2(or later). Please refer to http://www.jcraft.com/jsch/examples/AES.java Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |
From: Oberhuber, M. <Mar...@wi...> - 2007-07-31 13:28:24
|
Hello Atsuhiko, > By the default, jsch does not support the ciphers aes*-cbc,=20 > but it can handle them on J2SE 1.4.2(or later). > Please refer to > http://www.jcraft.com/jsch/examples/AES.java Does this mean that in order to be most compatbile, any Jsch application that knows it's running on an 1.4 or later JVM should include code like this:=20 java.util.Hashtable config=3Dnew java.util.Hashtable(); config.put("cipher.s2c", "aes128-cbc,3des-cbc,blowfish-cbc"); config.put("cipher.c2s", "aes128-cbc,3des-cbc,blowfish-cbc"); session.setConfig(config); this is important for us as our Eclipse based application=20 is known to run on Java 1.4 or later, and we'd like to be most compatible. Can there be any negative side-effect of adding that config? Would would happen if that code were in an application but the JVM does not support AES? Why is AES disabled by default in Jsch? Thanks, -- Martin Oberhuber Wind River Systems, Inc. Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm=20 |
From: <ym...@jc...> - 2007-08-01 06:56:12
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Tue, 31 Jul 2007 15:27:49 +0200 _______________________ | |Does this mean that in order to be most compatbile, any Jsch |application that knows it's running on an 1.4 or later JVM |should include code like this: | java.util.Hashtable config=new java.util.Hashtable(); | config.put("cipher.s2c", "aes128-cbc,3des-cbc,blowfish-cbc"); | config.put("cipher.c2s", "aes128-cbc,3des-cbc,blowfish-cbc"); | session.setConfig(config); |this is important for us as our Eclipse based application |is known to run on Java 1.4 or later, and we'd like to be |most compatible. The situation is little bit complicated. Since J2SE 1.4.0, Sun's JREs have included JCE(Java Cryptography Extension) and Sun's JCE provider, but AES has been only available since J2SE 1.4.2. And then..., AES supports three key length; 128-bit, 192-bit and 256-bit keys and SSH2's RFC has defined following three ciphers, aes128-cbc, aes192-cbc, aes256-cbc. Unfortunately, J2SE 1.4.2(and Java5) only supports 128-bit key by the default, due to import control restrictions of some countries. To enable the support for 192-bit and 256-bit key, users must install some programs by themselves[1]. |Can there be any negative side-effect of adding that config? |Would would happen if that code were in an application but |the JVM does not support AES? On such a case, the session will not be established. As a commiter of 'org.eclipse.jsch.core' plug-in included in Eclipse Platform I have been thinking of enabling aes*-cbc ciphers if the AES cipher is available on user's environment. If you file an entry at Eclipse.org's. bugzilla, I'll address it. [1] http://java.sun.com/products/jce/javase.html#UnlimitedDownload Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |
From: Oberhuber, M. <Mar...@wi...> - 2007-08-02 16:56:02
|
Hello Atsuhiko, thanks for your answer. Yes I will likely file an Eclipse Bugzilla bug for this. Just wondering, why couldn't the core jsch library try and auto-detect what algorightms are available? Thanks, -- Martin Oberhuber Wind River Systems, Inc. Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm=20 > -----Original Message----- > From: Atsuhiko Yamanaka [mailto:ym...@jc...]=20 > Sent: Wednesday, August 01, 2007 8:54 AM > To: Oberhuber, Martin > Cc: jsc...@li... > Subject: Re: [JSch-users] AES ciphers on Jsch (was: JSch on=20 > Vmware ESX 3.0) >=20 > Hi, >=20 > +-From: "Oberhuber, Martin" <Mar...@wi...> -- > |_Date: Tue, 31 Jul 2007 15:27:49 +0200 _______________________ > | > |Does this mean that in order to be most compatbile, any Jsch > |application that knows it's running on an 1.4 or later JVM > |should include code like this:=20 > | java.util.Hashtable config=3Dnew java.util.Hashtable(); > | config.put("cipher.s2c",=20 > "aes128-cbc,3des-cbc,blowfish-cbc"); > | config.put("cipher.c2s",=20 > "aes128-cbc,3des-cbc,blowfish-cbc"); > | session.setConfig(config); > |this is important for us as our Eclipse based application=20 > |is known to run on Java 1.4 or later, and we'd like to be > |most compatible. >=20 > The situation is little bit complicated. >=20 > Since J2SE 1.4.0, Sun's JREs have included JCE(Java=20 > Cryptography Extension) > and Sun's JCE provider, but AES has been only available since=20 > J2SE 1.4.2. >=20 > And then..., AES supports three key length; 128-bit, 192-bit=20 > and 256-bit keys=20 > and SSH2's RFC has defined following three ciphers,=20 > aes128-cbc, aes192-cbc, aes256-cbc.=20 > Unfortunately, J2SE 1.4.2(and Java5) only supports 128-bit=20 > key by the default, > due to import control restrictions of some countries. =20 > To enable the support for 192-bit and 256-bit key,=20 > users must install some programs by themselves[1]. >=20 > |Can there be any negative side-effect of adding that config? > |Would would happen if that code were in an application but > |the JVM does not support AES? >=20 > On such a case, the session will not be established. >=20 > As a commiter of 'org.eclipse.jsch.core' plug-in included in=20 > Eclipse Platform > I have been thinking of enabling aes*-cbc ciphers if the AES=20 > cipher is=20 > available on user's environment. If you file an entry at=20 > Eclipse.org's. > bugzilla, I'll address it.=20 >=20 > [1] http://java.sun.com/products/jce/javase.html#UnlimitedDownload >=20 >=20 > Sincerely, > -- > Atsuhiko Yamanaka > JCraft,Inc. > 1-14-20 HONCHO AOBA-KU, > SENDAI, MIYAGI 980-0014 Japan. > Tel +81-22-723-2150 > +1-415-578-3454 > Fax +81-22-224-8773 > Skype callto://jcraft/ >=20 |
From: <ym...@jc...> - 2007-08-03 01:52:52
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Thu, 2 Aug 2007 18:55:27 +0200 ________________________ | |thanks for your answer. Yes I will likely file an Eclipse Bugzilla bug |for this. Just wondering, why couldn't the core jsch library try and |auto-detect what algorightms are available? It will be easy to check the availability of AES in jsch, but I'm not planing to do at the present time. As you can see at rfc2533[1], "3des-cbc" is REQUIRED and, IMHO, that problem comes from the fault of that admin who dropped the "3des-cbc" support without understanding what that means. Almost of all users will not have such problems in connecting to SSHDs, which are managed by usual admins and it is just a waist of CPU time for those users to check if AES is available or not. As rfc2533[1] states, "3des-cbc" will be not REQUIRED at some future time, we may need to check the availability of AES in jsch. If you and others have strong and reasonable counter arguments or suggestions, it may be checked in jsch. [1] http://tools.ietf.org/html/rfc4253 Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |
From: <ym...@jc...> - 2007-08-10 02:41:22
|
Hi, +-From: ym...@jc... (Atsuhiko Yamanaka) -- |_Date: Fri, 3 Aug 2007 10:50:44 +0900 _______ | |If you and others have strong and reasonable counter arguments or |suggestions, it may be checked in jsch. After investigations on these days, I have decided to enable AES cipher in the next release if it is available. It seems AES is lighter that 3des and it will be worth waisting CPU time to check its availability. For example, I have founded that sftp transfer rates will been increased by just switching from 3des-cbc to aes128-cbc. The next version will have the property "CheckCiphers" and you can check ciphers as follows, java.util.Hashtable config=new java.util.Hashtable(); config.put("cipher.s2c", // ciphers for the downward stream "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc"); config.put("cipher.c2s", // ciphers for the upward stream "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc"); config.put("CheckCiphers", "aes256-cbc,aes192-cbc,aes128-cbc"); session.setConfig(config); If some of ciphers specified by "CheckCiphers" are not available, they will be stripped from "cipher.s2c" and "cipher.c2s". The default value for those properties in the next release will be as follows, config.put("cipher.s2c", "aes128-cbc,3des-cbc,blowfish-cbc"); config.put("cipher.c2s", "aes128-cbc,3des-cbc,blowfish-cbc"); config.put("CheckCiphers", "aes128-cbc"); So, just updating jsch version, "aes128-cbc" will be chosen if AES 128-bit key is available. If you have confirmed the availability of AES support on your environment and you want to skip such a check, you need to re-set "CheckCiphers" as follows, config.put("CheckCiphers", ""); FYI, it seems that the GCJ included in Fedora has supported AES 256-bit key, because it has been using BouncyCastle's JCE provider. Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |
From: Oberhuber, M. <Mar...@wi...> - 2007-08-14 14:20:56
|
Hello Atsuhiko, this is great news! Especially hearing that SFTP performance can be improved by simply changing=20 the cipher is very interesting. I guess the only thing I don't quite understand is the way you want to handle the default settings. My understanding is that the default setting should * Allow most clients to simply work the best way they=20 can, without any additional configuration * Do so even if it slightly compromises security or=20 wastes CPU time * Allow clients that do not do special configuration to benefit from new features as they upgrade In other words, I think the default configuration should "just work" and whoever wants to optimize it in his application in order to be more secure, or not waste CPU cycles, should do special config. Based on these thoughts, I'd think that the default values should be as follows: "ciphers.s2c" "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc" "ciphers.c2s" "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc" "CheckCiphers" "aes256-cbc,aes192-cbc,aes128-cbc" This will enable maximum compatibility, and maximal speed (by using aes128 as first try) at the cost=20 of running the checks for availability by default.=20 Clients who know they only want a particular well-known set=20 of ciphers (for whatever reason), they can manually configure=20 ciphers.s2c to their favorite ciphers. Such clients will=20 only get those ciphers forever, even if Jsch is upgraded to provide more ciphers in the future. I think the problem if it's not the way I'm proposing is, that if I write my application today and I want to make use of aes192-cbc and aes256-cbc, I need to manually=20 override the config today; but if I do so, my application cannot benefit from future addition of ciphers, because I'm manually overriding the config already. What do you think about this? Cheers, -- Martin Oberhuber Wind River Systems, Inc. Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm=20 > -----Original Message----- > From: jsc...@li...=20 > [mailto:jsc...@li...] On Behalf=20 > Of Atsuhiko Yamanaka > Sent: Friday, August 10, 2007 4:39 AM > To: jsc...@li... > Subject: Re: [JSch-users] AES ciphers on Jsch (was: JSch on=20 > Vmware ESX 3.0) >=20 > Hi, >=20 > +-From: ym...@jc... (Atsuhiko Yamanaka) -- > |_Date: Fri, 3 Aug 2007 10:50:44 +0900 _______ > | > |If you and others have strong and reasonable counter arguments or=20 > |suggestions, it may be checked in jsch. >=20 > After investigations on these days, I have decided to enable=20 > AES cipher > in the next release if it is available. It seems AES is=20 > lighter that 3des > and it will be worth waisting CPU time to check its availability. > For example, I have founded that sftp transfer rates will=20 > been increased > by just switching from 3des-cbc to aes128-cbc. >=20 > The next version will have the property "CheckCiphers" and=20 > you can check > ciphers as follows, >=20 > java.util.Hashtable config=3Dnew java.util.Hashtable(); > config.put("cipher.s2c", // ciphers for the downward stream > =20 > "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc"); > config.put("cipher.c2s", // ciphers for the upward stream=20 > =20 > "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc"); > config.put("CheckCiphers", "aes256-cbc,aes192-cbc,aes128-cbc"); > session.setConfig(config); >=20 > If some of ciphers specified by "CheckCiphers" are not available, > they will be stripped from "cipher.s2c" and "cipher.c2s". =20 >=20 > The default value for those properties in the next release=20 > will be as follows, >=20 > config.put("cipher.s2c", "aes128-cbc,3des-cbc,blowfish-cbc"); > config.put("cipher.c2s", "aes128-cbc,3des-cbc,blowfish-cbc"); > config.put("CheckCiphers", "aes128-cbc"); >=20 > So, just updating jsch version, "aes128-cbc" will be chosen=20 > if AES 128-bit key is available.=20 >=20 > If you have confirmed the availability of AES support on your=20 > environment > and you want to skip such a check, you need to re-set=20 > "CheckCiphers" as=20 > follows, >=20 > config.put("CheckCiphers", ""); >=20 > FYI, it seems that the GCJ included in Fedora has supported=20 > AES 256-bit key, > because it has been using BouncyCastle's JCE provider. >=20 >=20 > Sincerely, > -- > Atsuhiko Yamanaka > JCraft,Inc. > 1-14-20 HONCHO AOBA-KU, > SENDAI, MIYAGI 980-0014 Japan. > Tel +81-22-723-2150 > +1-415-578-3454 > Fax +81-22-224-8773 > Skype callto://jcraft/ >=20 > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and=20 > a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users >=20 |
From: <ym...@jc...> - 2007-08-16 06:31:27
|
Hi, I'm sorry for my delay of replying to you. # I have been on the vacation and will not be able to make # responses promptly until the end of next week. +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Tue, 14 Aug 2007 16:20:42 +0200 _______________________ | |Based on these thoughts, I'd think that the default |values should be as follows: |"ciphers.s2c" "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc" |"ciphers.c2s" "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc" |"CheckCiphers" "aes256-cbc,aes192-cbc,aes128-cbc" ... |I think the problem if it's not the way I'm proposing is, |that if I write my application today and I want to make |use of aes192-cbc and aes256-cbc, I need to manually |override the config today; but if I do so, my application |cannot benefit from future addition of ciphers, because |I'm manually overriding the config already. I don't have strong counterarguments about ciphers, which should be checked. As I wrote in the previous message, AES 256/192 key will not be available on Sun's JRE(and also IBM's JRE?) by the default, and almost of all users can not use them, so I had drooped them from "CheckCiphers". Ok, now I don't hasitate to check them in the next release by the default. So,the default values will be as follows, "ciphers.s2c" "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc" "ciphers.c2s" "aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc" "CheckCiphers" "aes256-cbc,aes192-cbc,aes128-cbc" as you have suggested. Thank you for your suggestion. Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |