Thread: [JSch-users] NoSuchAlgorithmException in ssh
Status: Alpha
Brought to you by:
ymnk
From: Conrad <cb...@em...> - 2007-08-31 09:54:41
|
Hello all, i try to establish an ssh Connection on a remote maschine there is the rsa key. my code looks like this try{ JSch jsch=new JSch(); String passphrase = "way/to/the/rsa_id"; jsch.addIdentity(passphrase ); String user="root"; String host="10.0.0.104"; Session session=jsch.getSession(user, host, 22); // username and passphrase will be given via UserInfo interface. UserInfo ui=new MyUserInfo(null, user, ""); session.setUserInfo(ui); try { session.connect(); // making connection with timeout. } catch (JSchException ex) { System.out.println("sshConnection : " + ex.getMessage()); } Channel channel=session.openChannel("shell"); channel.setInputStream(System.in); channel.setOutputStream(System.out); channel.connect(); } catch(Exception e){ System.out.println(e); } This is from the sch examples. But the output is java.security.NoSuchAlgorithmException: DESede/CBC/NoPadding: DESede sshConnection : java.security.NoSuchAlgorithmException: HmacMD5 I use this code from eclipse While Connecting , a Warning with The authenticy of host 10.0.0.104 can't be established. RSA key fingerprint is .... will be shown What i am missing? Any hints thanks c~ |
From: <ym...@jc...> - 2007-09-03 09:55:14
|
Hi, +-From: Conrad =?iso-8859-1?q?Berh=F6rster?= <cb...@em...> -- |_Date: Fri, 31 Aug 2007 11:54:13 +0200 ______________________ | ... |This is from the sch examples. But the output is |java.security.NoSuchAlgorithmException: DESede/CBC/NoPadding: DESede |sshConnection : java.security.NoSuchAlgorithmException: HmacMD5 |I use this code from eclipse It seems there is a problem in accessing to JCE(Java Cryptography Extension) on your environment. 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: Conrad <cb...@em...> - 2007-09-04 15:32:58
|
Hello Atsuhiko, thanks for your reply, After sending this issue, i saw the issue http://sourceforge.net/mailarchive/forum.php?thread_name=46D5DCE5.3000404%40ajk-solutions.com&forum_name=jsch-users and i think it is the same problem. Anyway, i am using java 1.4 and the webside mentioned, that JCE is included into the download. What puzzles me is, that there is some example code of jsch included in TM-Terminal, which use the same code and works perfect. Since there is no documentation and no useful Exception, i have no idea to handle this problem. How can i ensure of accessing JCE on my enironment. Thanks c~ Am Montag, 3. September 2007 09:18 schrieb Atsuhiko Yamanaka: > Hi, > > |This is from the sch examples. But the output is > |java.security.NoSuchAlgorithmException: DESede/CBC/NoPadding: DESede > |sshConnection : java.security.NoSuchAlgorithmException: HmacMD5 > |I use this code from eclipse > > It seems there is a problem in accessing to JCE(Java Cryptography Extension) > on your environment. > > > 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-09-05 15:40:11
|
Hello Conrad, how are you starting your application? What is the CLASSPATH variable, what is the PATH variable? The message from the forum you mentioned concluded in the end that it was a server issue, so I'm not sure it's the same=20 issue as you are seeing. 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 Conrad Berh=F6rster > Sent: Tuesday, September 04, 2007 5:32 PM > To: jsc...@li... > Subject: Re: [JSch-users] NoSuchAlgorithmException in ssh >=20 >=20 > Hello Atsuhiko,=20 >=20 > thanks for your reply,=20 >=20 > After sending this issue, i saw the issue > http://sourceforge.net/mailarchive/forum.php?thread_name=3D46D5D > CE5.3000404%40ajk-solutions.com&forum_name=3Djsch-users > and i think it is the same problem.=20 >=20 > Anyway, i am using java 1.4 and the webside mentioned, that=20 > JCE is included into the download.=20 > What puzzles me is, that there is some example code of jsch=20 > included in TM-Terminal, which use the same code=20 > and works perfect.=20 >=20 > Since there is no documentation and no useful Exception, i=20 > have no idea to handle this problem. > How can i ensure of accessing JCE on my enironment.=20 >=20 >=20 > Thanks c~ >=20 > Am Montag, 3. September 2007 09:18 schrieb Atsuhiko Yamanaka: > > Hi, > >=20 > > |This is from the sch examples. But the output is > > |java.security.NoSuchAlgorithmException:=20 > DESede/CBC/NoPadding: DESede > > |sshConnection : java.security.NoSuchAlgorithmException: HmacMD5 > > |I use this code from eclipse=20 > >=20 > > It seems there is a problem in accessing to JCE(Java=20 > Cryptography Extension) > > on your environment. > >=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 >=20 >=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: Conrad <cb...@em...> - 2007-09-06 12:15:17
|
Hello Martin, Am Mittwoch, 5. September 2007 17:38 schrieb Oberhuber, Martin: > Hello Conrad, > > how are you starting your application? > What is the CLASSPATH variable, what is the > PATH variable? the CLASSPATH is empty, the PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games the application is eclipse europa with a plugin, which i am developing. I have defined a view similar to the TM example i have connected a embedded system via ethernet. on the target is a rsa key in the .ssh directory. As i mentioned before, the TM 2.0 is working perfect. > > The message from the forum you mentioned > concluded in the end that it was a server > issue, so I'm not sure it's the same > issue as you are seeing. > anyway, i get the same error messages. First there is an eclipse message box and on the konsole, there is the NoSuchAlgorithmException. thanks for your help c~ > Cheers, > -- > Martin Oberhuber > Wind River Systems, Inc. > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > |
From: Oberhuber, M. <Mar...@wi...> - 2007-09-06 12:53:24
|
Hello Conrad, based on your environment, the issue could be because of the way Eclipse is loading classes. sunjce_provider.jar is in JRE/lib/ext, so it is a=20 JVM extension. By default, Eclipse / OSGi bundles only load well-known classes from the JVM when you have this in your meta-inf/ manifest.mf: Bundle-RequiredExecutionEnvironment: J2SE-1.4 In order to allow the JVM loading VM extensions, you need to add this to your meta-inf/manifest.mf: Eclipse-BuddyPolicy: ext I'm not sure why the TM ssh terminal does not have this issue, perhaps it's because we're still using Jsch 0.1.31 .. anyways, sending your MANIFEST.MF and .classpath files might help so we get an idea what's going on. Hope this helps, -- Martin Oberhuber Wind River Systems, Inc. Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm=20 |
From: Conrad <cb...@em...> - 2007-09-10 09:06:49
|
Hello Martin, sorry for that delay. Thanks for your hints. Unfortunately , they won't help I am also using sch 0.1.31. . Futher i am using Eclipse SDK 3.3.0. with the buildid I20070625-1500 So, there are no .classpath files in the project directories my Metafile.inf is -------------------- schnipp ----------------------- Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Emlipse Plug-in Bundle-SymbolicName: com.emlix.emlipse;singleton:=true Bundle-Version: 1.0.0 Bundle-Activator: com.emlix.emlipse.EmlipsePlugin Bundle-Vendor: EMLIX Bundle-RequiredExecutionEnvironment: J2SE-1.4 Require-Bundle: org.eclipse.core.runtime, org.eclipse.cdt.managedbuilder.core, org.eclipse.ui, org.eclipse.debug.ui, org.eclipse.cdt.launch, org.eclipse.cdt.core, org.eclipse.cdt.debug.core, org.eclipse.cdt.debug.mi.core, org.eclipse.cdt.debug.ui, org.eclipse.cdt.debug.mi.ui, com.jcraft.jsch, org.eclipse.ui.console, org.eclipse.cdt.make.ui, org.eclipse.jface.text, org.eclipse.ui.views, org.eclipse.jsch.core Eclipse-LazyStart: true Eclipse-BuddyPolicy: ext Import-Package: org.eclipse.cdt.debug.internal.ui, org.eclipse.cdt.debug.mi.internal.ui, org.eclipse.cdt.debug.mi.internal.ui.dialogfields, org.eclipse.cdt.make.core, org.eclipse.cdt.ui.newui, org.eclipse.cdt.utils.ui.controls, org.eclipse.ui.wizards.newresource ----------------------------- schnipp ------------------- if i use the ssh command in a shell , i need to add the -i flag, which specifies the path to the id_file. this flag is need to added into jsch by String passphrase = "/path/to/target/targetfs/root/.ssh/id_rsa"; jsch.addIdentity(passphrase); right?? i have overloaded the MessageClass UserInfo, like i have been done in the jsch Demo. This produce a Error "The authenticy of host '10.0.0.105' can't be establisched. RSA key fingerprint dd:07:<etc> . Are you sure you want to continue connecting? " This Message comes from jsch and will Produce the NoSuchAlgorthmException: DESede/CBC/NoPadding: DESede and an Exception Error String HmacMD5. Do you need more info ?? Thanks c~ Am Donnerstag, 6. September 2007 14:52 schrieb Oberhuber, Martin: > Hello Conrad, > > based on your environment, the issue could be because > of the way Eclipse is loading classes. > > sunjce_provider.jar is in JRE/lib/ext, so it is a > JVM extension. > > By default, Eclipse / OSGi bundles only load well-known > classes from the JVM when you have this in your meta-inf/ > manifest.mf: > > Bundle-RequiredExecutionEnvironment: J2SE-1.4 > > In order to allow the JVM loading VM extensions, you need > to add this to your meta-inf/manifest.mf: > > Eclipse-BuddyPolicy: ext > > I'm not sure why the TM ssh terminal does not have this > issue, perhaps it's because we're still using Jsch 0.1.31 > .. anyways, sending your MANIFEST.MF and .classpath files > might help so we get an idea what's going on. > > Hope this helps, > -- > Martin Oberhuber > Wind River Systems, Inc. > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > |
From: Conrad <cb...@em...> - 2007-09-10 12:17:22
|
Hello Martin, sorry for that delay. Thanks for your hints. Unfortunately , they won't help I am also using sch 0.1.31. . Futher i am using Eclipse SDK 3.3.0. with the buildid I20070625-1500 So, there are no .classpath files in the project directories my Metafile.inf is -------------------- schnipp ----------------------- Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Emlipse Plug-in Bundle-SymbolicName: com.emlix.emlipse;singleton:=true Bundle-Version: 1.0.0 Bundle-Activator: com.emlix.emlipse.EmlipsePlugin Bundle-Vendor: EMLIX Bundle-RequiredExecutionEnvironment: J2SE-1.4 Require-Bundle: org.eclipse.core.runtime, org.eclipse.cdt.managedbuilder.core, org.eclipse.ui, org.eclipse.debug.ui, org.eclipse.cdt.launch, org.eclipse.cdt.core, org.eclipse.cdt.debug.core, org.eclipse.cdt.debug.mi.core, org.eclipse.cdt.debug.ui, org.eclipse.cdt.debug.mi.ui, com.jcraft.jsch, org.eclipse.ui.console, org.eclipse.cdt.make.ui, org.eclipse.jface.text, org.eclipse.ui.views, org.eclipse.jsch.core Eclipse-LazyStart: true Eclipse-BuddyPolicy: ext Import-Package: org.eclipse.cdt.debug.internal.ui, org.eclipse.cdt.debug.mi.internal.ui, org.eclipse.cdt.debug.mi.internal.ui.dialogfields, org.eclipse.cdt.make.core, org.eclipse.cdt.ui.newui, org.eclipse.cdt.utils.ui.controls, org.eclipse.ui.wizards.newresource ----------------------------- schnipp ------------------- if i use the ssh command in a shell , i need to add the -i flag, which specifies the path to the id_file. this flag is need to added into jsch by String passphrase = "/path/to/target/targetfs/root/.ssh/id_rsa"; jsch.addIdentity(passphrase); right?? i have overloaded the MessageClass UserInfo, like i have been done in the jsch Demo. This produce a Error "The authenticy of host '10.0.0.105' can't be establisched. RSA key fingerprint dd:07:<etc> . Are you sure you want to continue connecting? " This Message comes from jsch and will Produce the NoSuchAlgorthmException: DESede/CBC/NoPadding: DESede and an Exception Error String HmacMD5. Do you need more info ?? Thanks c~ Am Donnerstag, 6. September 2007 14:52 schrieb Oberhuber, Martin: > Hello Conrad, > > based on your environment, the issue could be because > of the way Eclipse is loading classes. > > sunjce_provider.jar is in JRE/lib/ext, so it is a > JVM extension. > > By default, Eclipse / OSGi bundles only load well-known > classes from the JVM when you have this in your meta-inf/ > manifest.mf: > > Bundle-RequiredExecutionEnvironment: J2SE-1.4 > > In order to allow the JVM loading VM extensions, you need > to add this to your meta-inf/manifest.mf: > > Eclipse-BuddyPolicy: ext > > I'm not sure why the TM ssh terminal does not have this > issue, perhaps it's because we're still using Jsch 0.1.31 > .. anyways, sending your MANIFEST.MF and .classpath files > might help so we get an idea what's going on. > > Hope this helps, > -- > Martin Oberhuber > Wind River Systems, Inc. > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > |
From: Oberhuber, M. <Mar...@wi...> - 2007-09-10 12:32:09
|
Hello Conrad, > "The authenticy of host '10.0.0.105' can't be establisched.=20 > RSA key fingerprint dd:07:<etc> .=20 > Are you sure you want to continue connecting? " This message is normal when you connect to a host for the=20 first time. Jsch will save the host key of that host in=20 the known_hosts file in the SSH homedir. Does your app tell Jsch where the SSH homedir is, such that the known_hosts file can be read and written? You might want to consider IJSchService.createSession() in order to set up SSH Preferences as specified in the General > Networ Connections Preferences screen. About the "No such algorithm" exception, I'm not sure. Atsuhiko might have an idea. I do not know the "DESede/CBC/NoPadding" algorithm, perhaps this is different than the 3des algorithm that JSch supports. Perhaps you'd have to configure your SSH server to allow other kinds of algorithms. What kind of SSH server is this? Can you send it's config? It might also help if you try connecting your remote from a (cygwin or UNIX) ssh client: ssh -v 10.0.0.105 the debug messages being logged might help understanding what kind of algorithms or MD's your remote expects. Cheers, -- Martin Oberhuber Wind River Systems, Inc. Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm=20 > -----Original Message----- > From: Conrad Berh=F6rster [mailto:cb...@em...]=20 > Sent: Monday, September 10, 2007 2:17 PM > To: Oberhuber, Martin > Cc: jsc...@li... > Subject: Re: [JSch-users] NoSuchAlgorithmException in ssh >=20 > Hello Martin,=20 >=20 > sorry for that delay.=20 > Thanks for your hints. Unfortunately , they won't help=20 > I am also using sch 0.1.31. . Futher i am using Eclipse SDK 3.3.0. > with the buildid I20070625-1500=20 > So, there are no .classpath files in the project directories=20 > my Metafile.inf is=20 >=20 > -------------------- schnipp ----------------------- > Manifest-Version: 1.0 > Bundle-ManifestVersion: 2 > Bundle-Name: Emlipse Plug-in > Bundle-SymbolicName: com.emlix.emlipse;singleton:=3Dtrue > Bundle-Version: 1.0.0 > Bundle-Activator: com.emlix.emlipse.EmlipsePlugin > Bundle-Vendor: EMLIX > Bundle-RequiredExecutionEnvironment: J2SE-1.4 > Require-Bundle: org.eclipse.core.runtime, > org.eclipse.cdt.managedbuilder.core, > org.eclipse.ui, > org.eclipse.debug.ui, > org.eclipse.cdt.launch, > org.eclipse.cdt.core, > org.eclipse.cdt.debug.core, > org.eclipse.cdt.debug.mi.core, > org.eclipse.cdt.debug.ui, > org.eclipse.cdt.debug.mi.ui, > com.jcraft.jsch, > org.eclipse.ui.console, > org.eclipse.cdt.make.ui, > org.eclipse.jface.text, > org.eclipse.ui.views, > org.eclipse.jsch.core > Eclipse-LazyStart: true > Eclipse-BuddyPolicy: ext > Import-Package: org.eclipse.cdt.debug.internal.ui, > org.eclipse.cdt.debug.mi.internal.ui, > org.eclipse.cdt.debug.mi.internal.ui.dialogfields, > org.eclipse.cdt.make.core, > org.eclipse.cdt.ui.newui, > org.eclipse.cdt.utils.ui.controls, > org.eclipse.ui.wizards.newresource > ----------------------------- schnipp ------------------- >=20 > if i use the ssh command in a shell , i need to add the -i flag,=20 > which specifies the path to the id_file. this flag is need to=20 > added into jsch by >=20 >=20 > String passphrase =3D "/path/to/target/targetfs/root/.ssh/id_rsa";=20 > jsch.addIdentity(passphrase); >=20 > right??=20 >=20 > i have overloaded the MessageClass UserInfo, like i have been=20 > done in the jsch Demo.=20 > This produce a Error=20 > "The authenticy of host '10.0.0.105' can't be establisched.=20 > RSA key fingerprint dd:07:<etc> .=20 > Are you sure you want to continue connecting? " > This Message comes from jsch and will Produce the=20 > NoSuchAlgorthmException: DESede/CBC/NoPadding: DESede >=20 > and an Exception Error String HmacMD5.=20 >=20 >=20 > Do you need more info ??=20 >=20 > Thanks c~ >=20 >=20 > Am Donnerstag, 6. September 2007 14:52 schrieb Oberhuber, Martin: > > Hello Conrad, > >=20 > > based on your environment, the issue could be because > > of the way Eclipse is loading classes. > >=20 > > sunjce_provider.jar is in JRE/lib/ext, so it is a=20 > > JVM extension. > >=20 > > By default, Eclipse / OSGi bundles only load well-known > > classes from the JVM when you have this in your meta-inf/ > > manifest.mf: > >=20 > > Bundle-RequiredExecutionEnvironment: J2SE-1.4 > >=20 > > In order to allow the JVM loading VM extensions, you need > > to add this to your meta-inf/manifest.mf: > >=20 > > Eclipse-BuddyPolicy: ext > >=20 > > I'm not sure why the TM ssh terminal does not have this > > issue, perhaps it's because we're still using Jsch 0.1.31 > > .. anyways, sending your MANIFEST.MF and .classpath files > > might help so we get an idea what's going on. > >=20 > > Hope this helps, > > -- > > Martin Oberhuber > > Wind River Systems, Inc. > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm=20 > >=20 >=20 |
From: Conrad <cb...@em...> - 2007-09-10 16:25:08
|
Hello Martin, Am Montag, 10. September 2007 14:31 schrieb Oberhuber, Martin: > Hello Conrad, > > > This message is normal when you connect to a host for the > first time. Jsch will save the host key of that host in > the known_hosts file in the SSH homedir. Does your app > tell Jsch where the SSH homedir is, such that the > known_hosts file can be read and written? Do i need to tell Jsch this explicitly oder will the API take the information from the below Preferences? > > You might want to consider IJSchService.createSession() > in order to set up SSH Preferences as specified in the > General > Networ Connections Preferences screen. > They were set proberly, i think. The file rsa_id exists! i never made some changes there. They all are default. > About the "No such algorithm" exception, I'm not sure. > Atsuhiko might have an idea. I do not know the > "DESede/CBC/NoPadding" > algorithm, perhaps this is different than the 3des > algorithm that JSch supports. Perhaps you'd have > to configure your SSH server to allow other kinds > of algorithms. > > What kind of SSH server is this? Can you send it's > config? It might also help if you try connecting > your remote from a (cygwin or UNIX) ssh client: > ssh -v 10.0.0.105 > the debug messages being logged might help understanding > what kind of algorithms or MD's your remote expects. > I'm running two linux machines , host and target. different users cberh@zucchini:~/.ssh$ ssh -v 10.0.0.105 OpenSSH_4.2p1 Debian-7ubuntu3.1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 10.0.0.105 [10.0.0.105] port 22. debug1: Connection established. debug1: identity file /home/cberh/.ssh/identity type -1 debug1: identity file /home/cberh/.ssh/id_rsa type 1 debug1: identity file /home/cberh/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host '10.0.0.105 (10.0.0.105)' can't be established. RSA key fingerprint is dd:07:2a:3e:07:62:9a:ad:b2:a6:1c:3c:1d:47:d7:21. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.0.105' (RSA) to the list of known hosts. debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/cberh/.ssh/identity debug1: Offering public key: /home/cberh/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /home/cberh/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password thanks c~ |
From: <ym...@jc...> - 2007-09-11 07:50:56
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Mon, 10 Sep 2007 14:31:31 +0200 _______________________ | |About the "No such algorithm" exception, I'm not sure. |Atsuhiko might have an idea. I do not know the | "DESede/CBC/NoPadding" |algorithm, perhaps this is different than the 3des |algorithm that JSch supports. That means the Triple DES in the Cipher Block Channing mode and it is required for the "3des-cbc" cipher method defined in ssh2 protocol. 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: Conrad <cb...@em...> - 2007-09-11 08:31:48
|
Hello Atsuhiko , Am Dienstag, 11. September 2007 09:49 schrieb Atsuhiko Yamanaka: > Hi, > > +-From: "Oberhuber, Martin" <Mar...@wi...> -- > |_Date: Mon, 10 Sep 2007 14:31:31 +0200 _______________________ > | > |About the "No such algorithm" exception, I'm not sure. > |Atsuhiko might have an idea. I do not know the > | "DESede/CBC/NoPadding" > |algorithm, perhaps this is different than the 3des > |algorithm that JSch supports. > > That means the Triple DES in the Cipher Block Channing mode and > it is required for the "3des-cbc" cipher method defined in ssh2 protocol. > I'm a no crypto expert, sorry. Therefore, i don't can follow your explanation. Anyway, is there a way to configure a different mode? Is there some sample code, how i can obtain a comand like ssh -i <path_to_public_key> <hostname> with jsch Do you have any idea, why that protocol works with the TM example, but not with mine? Thanks c~ |
From: <ym...@jc...> - 2007-09-11 14:30:29
|
Hi, +-From: Conrad =?iso-8859-1?q?Berh=F6rster?= <cb...@em...> -- |_Date: Tue, 11 Sep 2007 10:31:39 +0200 ______________________ | |Do you have any idea, why that protocol works with the TM example, |but not with mine? May I ask you to run following chunk of code before invoking Session#connect()? java.security.Provider[] providers=java.security.Security.getProviders(); for(int i=0; i<providers.length; i++){ System.out.println(providers[i].getName()); } I have remembered the similar problem, https://bugs.eclipse.org/bugs/show_bug.cgi?id=175058 and I guess that your plug-in may install the JCE provider dynamically. |Is there some sample code, how i can obtain a comand like ssh -i | <path_to_public_key> <hostname> with jsch As Martin has suggested you, IJSchService.createSession() will automatically check the private keys specified at SSH2 Preference page and you don't have to take care about them. 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: Conrad <cb...@em...> - 2007-09-11 15:44:14
|
Hello, Am Dienstag, 11. September 2007 16:29 schrieb Atsuhiko Yamanaka: > Hi, > > +-From: Conrad =?iso-8859-1?q?Berh=F6rster?= <cb...@em...> -- > |_Date: Tue, 11 Sep 2007 10:31:39 +0200 ______________________ > | > |Do you have any idea, why that protocol works with the TM example, > |but not with mine? > > May I ask you to run following chunk of code before invoking > Session#connect()? Sure you can ;=) Everything that helps to fix this task. > > java.security.Provider[] providers=java.security.Security.getProviders(); > for(int i=0; i<providers.length; i++){ > System.out.println(providers[i].getName()); > } > The Output is GNU > I have remembered the similar problem, > https://bugs.eclipse.org/bugs/show_bug.cgi?id=175058 Do i need to have so many other providers? thanks c~ |
From: Oberhuber, M. <Mar...@wi...> - 2007-09-11 16:16:49
|
> The Output is GNU Ha! Looks to me like you're not running the Sun JVM but gcj ... you should check your PATH which java 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 Conrad Berh=F6rster > Sent: Tuesday, September 11, 2007 5:44 PM > To: jsc...@li... > Subject: Re: [JSch-users] NoSuchAlgorithmException in ssh >=20 > Hello,=20 >=20 >=20 > Am Dienstag, 11. September 2007 16:29 schrieb Atsuhiko Yamanaka: > > Hi, > >=20 > > +-From: Conrad =3D?iso-8859-1?q?Berh=3DF6rster?=3D <cb...@em...> = -- > > |_Date: Tue, 11 Sep 2007 10:31:39 +0200 ______________________ > > | > > |Do you have any idea, why that protocol works with the=20 > TM example,=20 > > |but not with mine?=20 > >=20 > > May I ask you to run following chunk of code before invoking > > Session#connect()? >=20 > Sure you can ;=3D) Everything that helps to fix this task. =20 >=20 >=20 > >=20 > > java.security.Provider[]=20 > providers=3Djava.security.Security.getProviders(); > > for(int i=3D0; i<providers.length; i++){ > > System.out.println(providers[i].getName()); > > } > >=20 >=20 > The Output is GNU >=20 > > I have remembered the similar problem, > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D175058 > Do i need to have so many other providers?=20 >=20 > thanks c~ >=20 > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users >=20 |
From: <ym...@jc...> - 2007-09-12 03:09:46
|
Hi, +-From: Conrad =?utf-8?q?Berh=C3=B6rster?= <cb...@em...> -- |_Date: Tue, 11 Sep 2007 17:43:43 +0200 ____________________ | >> java.security.Provider[] >> providers=java.security.Security.getProviders(); for(int i=0; >> i<providers.length; i++){ >> System.out.println(providers[i].getName()); } >> |The Output is GNU Humm... This is the first time to hear that you are running Eclipse on the Unices(GNU/Linux?) and using gjc. On the Fedora Core release 5, I have the following output, GNU BC Jessie GNU-CRYPTO At least, BC(BouncyCastle) must be appeared there to enjoy "3des-cbc" and I really can not understand why DSDP's TM can drive jsch on your environment. By the way, if your plug-in is for your business and not for your fun, I suggest you to choose other Java runtime environment. You may know that gcj is not on the Target Operating Environments for Eclipse 3.3[1] . If you have other problems related to gcj, you may have difficulties in searching for answers. [1] http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#TargetOperatingEnvironments 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: Conrad <cb...@em...> - 2007-09-12 09:34:36
|
Hello, huh martin, your are right. That was the Problem. I upgraded the system to the sun jdk and it worked without the error. this is really assuasive ;=) Only the warning with the RSA key appered. But this can be in my sources. Am Mittwoch, 12. September 2007 04:54 schrieb Atsuhiko Yamanaka: > Hi, > > +-From: Conrad =?utf-8?q?Berh=C3=B6rster?= <cb...@em...> -- > |_Date: Tue, 11 Sep 2007 17:43:43 +0200 ____________________ > | > >> java.security.Provider[] > >> providers=java.security.Security.getProviders(); for(int i=0; > >> i<providers.length; i++){ > >> System.out.println(providers[i].getName()); } > >> > |The Output is GNU > > Humm... > This is the first time to hear that you are running Eclipse on > the Unices(GNU/Linux?) and using gjc. > > On the Fedora Core release 5, I have the following output, > > GNU > BC > Jessie > GNU-CRYPTO I have used the ubuntu version java version "1.4.2" gij (GNU libgcj) version 4.1.0 (Ubuntu 4.1.0-1ubuntu8) the actual list of providers is SUN SunRsaSign SunJSSE SunJCE SunJGSS SunSASL XMLDSig SunPCSC ~ > > At least, BC(BouncyCastle) must be appeared there to enjoy "3des-cbc" and > I really can not understand why DSDP's TM can drive jsch on your environment. ;=) > > By the way, if your plug-in is for your business and not for your fun, > I suggest you to choose other Java runtime environment. yes for sure Thanks very much for your help c~ |
From: <ym...@jc...> - 2007-09-12 14:42:28
|
Hi, +-From: Conrad =?utf-8?q?Berh=C3=B6rster?= <cb...@em...> -- |_Date: Wed, 12 Sep 2007 11:34:30 +0200 ____________________ | |I have used the ubuntu version java version "1.4.2" gij (GNU |libgcj) version 4.1.0 (Ubuntu 4.1.0-1ubuntu8) | |the actual list of providers is |SUN |SunRsaSign |SunJSSE |SunJCE |SunJGSS |SunSASL |XMLDSig |SunPCSC I guess that above list must be from Sun's JRE. Is it right? 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-09-19 09:47:52
|
Hello, I'm wondering if anybody thought about the case yet where I'd like to transfer files via Sftp, where the file names Use non-ASCII foreign language characters, and the character Encoding on the local system is different than the remote. Say, I want to transfer from a Windows box to a Linux box. On Windows, my encoding is Cp1252 On remote Linux, my encoding is UTF-8 I want to transfer file "m=F6chte" Currently, channel always seems to encode Java Unicode Strings With Platform default encoding (Cp1252 in my case). On the=20 Remote, file names will not appear as expected. Things get worse when I have an application that should create Files on the remote where the names can only be expressed as UTF-8 But not in the local default encoding (for instance, turkish Characters or Japanese). Creating file "a=F0b" Is encoded by Cp1252 as "a?b" But I cannot create such files on the remote To fix this, I think there should be=20 Channel.setControlEncoding(String encoding) So I can specify the encoding to use forr file and Path names on the remote. At the time the Java unicode String for arguments is converted to byte arrray, it Should do so with the default encoding specified by me. Any thoughts? Thanks Martin -----Original Message----- From: jsc...@li... = [mailto:jsc...@li...] On Behalf Of Atsuhiko = Yamanaka Sent: Wednesday, September 12, 2007 4:41 PM To: cb...@em... Cc: jsc...@li... Subject: Re: [JSch-users] NoSuchAlgorithmException in ssh Hi, +-From: Conrad =3D?utf-8?q?Berh=3DC3=3DB6rster?=3D <cb...@em...> -- |_Date: Wed, 12 Sep 2007 11:34:30 +0200 ____________________ | |I have used the ubuntu version java version "1.4.2" gij (GNU |libgcj) version 4.1.0 (Ubuntu 4.1.0-1ubuntu8) | |the actual list of providers is |SUN |SunRsaSign |SunJSSE |SunJCE |SunJGSS |SunSASL |XMLDSig |SunPCSC I guess that above list must be from Sun's JRE. Is it right? =09 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/ -------------------------------------------------------------------------= This SF.net email is sponsored by: Microsoft Defy all challenges. = Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ JSch-users mailing list JSc...@li... https://lists.sourceforge.net/lists/listinfo/jsch-users |
From: <ym...@jc...> - 2007-09-20 02:58:59
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Wed, 19 Sep 2007 11:47:37 +0200 _______________________ | |I'm wondering if anybody thought about the case yet where |I'd like to transfer files via Sftp, where the file names |Use non-ASCII foreign language characters, and the character |Encoding on the local system is different than the remote. | |Say, I want to transfer from a Windows box to a Linux box. |On Windows, my encoding is Cp1252 |On remote Linux, my encoding is UTF-8 |I want to transfer file "m,Mv(Bchte" | |Currently, channel always seems to encode Java Unicode Strings |With Platform default encoding (Cp1252 in my case). On the |Remote, file names will not appear as expected. Yes, it is a bug/incompleteness of jsch. As far as I have understood, we have to send filenames in UTF-8 over sftp protocol. For example, its IETF draft[1] has said as follows, 8.1.1. Opening a File Files are opened and created using the SSH_FXP_OPEN message. byte SSH_FXP_OPEN uint32 request-id string filename [UTF-8] uint32 desired-access uint32 flags ATTRS attrs On the other hand, in the current jsch implementation, filenames have been sent in the local default encoding. I'll fix it in the next version, but it will cause the troubles for others. It seems to me that OpenSSH(for example, openssh-4.7p1)'s sftp-server has not implemented such encoding conversion. So, as for the avobe case, if the remote host does not use UTF-8, users will get unexpected results. This is the reason I had not implemented it. |To fix this, I think there should be | Channel.setControlEncoding(String encoding) |So I can specify the encoding to use forr file and |Path names on the remote. At the time the Java unicode |String for arguments is converted to byte arrray, it |Should do so with the default encoding specified by me. Unfortunately, the client does not have the initiative to choose the encoding and filenames must be sent in UTF-8 according to the RFC. [1] http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 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-09-21 09:48:00
|
Hello Atsuhiko, I'm not a big expert on encodings, but it seems to me that unconditionally focing UTF-8 is not the right=20 thing to do, at least for the following reasons: 1.) As I understand it, on a UNIX box every user is free=20 to choose his own encoding. User A could be using UTF-8 but user B could be using ISO8859-1 or whatever he prefers. In the shell, the change is made by setting an environment variable. But how would the SSHD know what encoding a user prefers? It's running as root, isn't it? So how would it convert from UTF-8 to the user's preferred encoding? 2.) Although RFC seems to recomment UTF-8, it looks like=20 practical implementation does not use it to recode. 3.) Old version of Jsch defaulted to something else, so if files with extended chars were written with old Jsch they cannot be read properly with new Jsch when you=20 force UTF-8. because of all these reasons, I still think the better way is to allow client choose the default encoding, as I was proposing. If it turns out that UTF-8 is the correct default, client can=20 Channel.setDefaultEncoding("UTF-8"); otherwise, other client's favorite encoding can be set. But as I said, I'm not the big expert on encodings and I'm happy to discuss 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: Atsuhiko Yamanaka [mailto:ym...@jc...]=20 > Sent: Thursday, September 20, 2007 4:58 AM > To: Oberhuber, Martin > Cc: jsc...@li... > Subject: Re: [JSch-users] Jsch ChannelSftp and character encodings >=20 > Hi, >=20 > +-From: "Oberhuber, Martin" <Mar...@wi...> -- > |_Date: Wed, 19 Sep 2007 11:47:37 +0200 _______________________ > | > |I'm wondering if anybody thought about the case yet where > |I'd like to transfer files via Sftp, where the file names > |Use non-ASCII foreign language characters, and the character > |Encoding on the local system is different than the remote. > | > |Say, I want to transfer from a Windows box to a Linux box. > |On Windows, my encoding is Cp1252 > |On remote Linux, my encoding is UTF-8 > |I want to transfer file "m=1B,Mv=1B(Bchte" > | > |Currently, channel always seems to encode Java Unicode Strings > |With Platform default encoding (Cp1252 in my case). On the=20 > |Remote, file names will not appear as expected. >=20 > Yes, it is a bug/incompleteness of jsch. >=20 > As far as I have understood, we have to send filenames in UTF-8 over > sftp protocol. For example, its IETF draft[1] has said as follows, >=20 > 8.1.1. Opening a File > Files are opened and created using the SSH_FXP_OPEN message. > byte SSH_FXP_OPEN > uint32 request-id > string filename [UTF-8] > uint32 desired-access > uint32 flags > ATTRS attrs >=20 > On the other hand, in the current jsch implementation, > filenames have been sent in the local default encoding. >=20 > I'll fix it in the next version, but it will cause the=20 > troubles for others. > It seems to me that OpenSSH(for example, openssh-4.7p1)'s=20 > sftp-server has > not implemented such encoding conversion. So, as for the avobe case,=20 > if the remote host does not use UTF-8, users will get=20 > unexpected results. > This is the reason I had not implemented it. >=20 > |To fix this, I think there should be=20 > | Channel.setControlEncoding(String encoding) > |So I can specify the encoding to use forr file and > |Path names on the remote. At the time the Java unicode > |String for arguments is converted to byte arrray, it > |Should do so with the default encoding specified by me. >=20 > Unfortunately, the client does not have the initiative to choose the > encoding and filenames must be sent in UTF-8 according to the RFC. >=20 >=20 > [1] http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 >=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: Oberhuber, M. <Mar...@wi...> - 2007-09-25 13:46:23
|
Hello, I found another problem with using the local Platform default encoding for ChannelSftp: * Take a local Windows box with default encoding ("Cp1252") and a remote Linux (RHEL4) box with UTF-8 encoding. * There are some Unicode characters that lead to bytes which cannot be expressed in Cp1252: For instance, the character '=E8' includes 0x8d in UTF-8 and byte 0x8d is not defined in Cp1252. * As a result, when reading the directory with the standard encoding, Jsch replaces character '=E8' by a question mark '?' * But even glob_remote cannot resolve the question mark by=20 the original bytes --> as a result, remote files which=20 include the '=E8' character cannot be worked on at all! --> no stat(), no ls() etc... no Jsch ChannelSftp command at all works on such files. I thus find this issue REALLY problematic, and I'd vote for - provide a ChannelSftp.setControlEncoding() - have the default encoding be UTF-8 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 Oberhuber, Martin > Sent: Friday, September 21, 2007 11:48 AM > To: Atsuhiko Yamanaka > Cc: jsc...@li... > Subject: Re: [JSch-users] Jsch ChannelSftp and character encodings >=20 > Hello Atsuhiko, >=20 > I'm not a big expert on encodings, but it seems to me > that unconditionally focing UTF-8 is not the right=20 > thing to do, at least for the following reasons: >=20 > 1.) As I understand it, on a UNIX box every user is free=20 > to choose his own encoding. User A could be using UTF-8 > but user B could be using ISO8859-1 or whatever he prefers. > In the shell, the change is made by setting an environment > variable. > But how would the SSHD know what encoding a user prefers? > It's running as root, isn't it? So how would it convert > from UTF-8 to the user's preferred encoding? >=20 > 2.) Although RFC seems to recomment UTF-8, it looks like=20 > practical implementation does not use it to recode. >=20 > 3.) Old version of Jsch defaulted to something else, so if > files with extended chars were written with old Jsch > they cannot be read properly with new Jsch when you=20 > force UTF-8. >=20 > because of all these reasons, I still think the better way > is to allow client choose the default encoding, as I was > proposing. If it turns out that UTF-8 is the correct default, > client can=20 > Channel.setDefaultEncoding("UTF-8"); > otherwise, other client's favorite encoding can be set. >=20 > But as I said, I'm not the big expert on encodings and I'm > happy to discuss this. >=20 > Cheers, > -- > Martin Oberhuber > Wind River Systems, Inc. > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm=20 >=20 > > -----Original Message----- > > From: Atsuhiko Yamanaka [mailto:ym...@jc...]=20 > > Sent: Thursday, September 20, 2007 4:58 AM > > To: Oberhuber, Martin > > Cc: jsc...@li... > > Subject: Re: [JSch-users] Jsch ChannelSftp and character encodings > >=20 > > Hi, > >=20 > > +-From: "Oberhuber, Martin" <Mar...@wi...> -- > > |_Date: Wed, 19 Sep 2007 11:47:37 +0200 _______________________ > > | > > |I'm wondering if anybody thought about the case yet where > > |I'd like to transfer files via Sftp, where the file names > > |Use non-ASCII foreign language characters, and the character > > |Encoding on the local system is different than the remote. > > | > > |Say, I want to transfer from a Windows box to a Linux box. > > |On Windows, my encoding is Cp1252 > > |On remote Linux, my encoding is UTF-8 > > |I want to transfer file "m=1B,Mv=1B(Bchte" > > | > > |Currently, channel always seems to encode Java Unicode Strings > > |With Platform default encoding (Cp1252 in my case). On the=20 > > |Remote, file names will not appear as expected. > >=20 > > Yes, it is a bug/incompleteness of jsch. > >=20 > > As far as I have understood, we have to send filenames in UTF-8 over > > sftp protocol. For example, its IETF draft[1] has said as follows, > >=20 > > 8.1.1. Opening a File > > Files are opened and created using the SSH_FXP_OPEN message. > > byte SSH_FXP_OPEN > > uint32 request-id > > string filename [UTF-8] > > uint32 desired-access > > uint32 flags > > ATTRS attrs > >=20 > > On the other hand, in the current jsch implementation, > > filenames have been sent in the local default encoding. > >=20 > > I'll fix it in the next version, but it will cause the=20 > > troubles for others. > > It seems to me that OpenSSH(for example, openssh-4.7p1)'s=20 > > sftp-server has > > not implemented such encoding conversion. So, as for the=20 > avobe case,=20 > > if the remote host does not use UTF-8, users will get=20 > > unexpected results. > > This is the reason I had not implemented it. > >=20 > > |To fix this, I think there should be=20 > > | Channel.setControlEncoding(String encoding) > > |So I can specify the encoding to use forr file and > > |Path names on the remote. At the time the Java unicode > > |String for arguments is converted to byte arrray, it > > |Should do so with the default encoding specified by me. > >=20 > > Unfortunately, the client does not have the initiative to choose the > > encoding and filenames must be sent in UTF-8 according to the RFC. > >=20 > >=20 > > [1] http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 > >=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 >=20 > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users >=20 |
From: <ym...@jc...> - 2007-09-26 01:33:47
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Tue, 25 Sep 2007 15:45:56 +0200 _______________________ | |* Take a local Windows box with default encoding ("Cp1252") | and a remote Linux (RHEL4) box with UTF-8 encoding. |* There are some Unicode characters that lead to bytes | which cannot be expressed in Cp1252: For instance, the | character ',Bh(B' includes 0x8d in UTF-8 and byte 0x8d | is not defined in Cp1252. |* As a result, when reading the directory with the standard | encoding, Jsch replaces character ',Bh(B' by a question mark | '?' |* But even glob_remote cannot resolve the question mark by | the original bytes --> as a result, remote files which | include the ',Bh(B' character cannot be worked on at all! |no stat(), no ls() etc... no Jsch ChannelSftp command | at all works on such files. |I thus find this issue REALLY problematic, and I'd vote for | - have the default encoding be UTF-8 I'll also vote for it, because it is what I wrote in the last mail. | - provide a ChannelSftp.setControlEncoding() I'm confusing a little bit. Do you think that this method will resolve some of above problems? 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-09-26 11:15:34
|
> |I thus find this issue REALLY problematic, and I'd vote for > | - have the default encoding be UTF-8 >=20 > I'll also vote for it, because it is what I wrote in the last mail. >=20 > | - provide a ChannelSftp.setControlEncoding() >=20 > I'm confusing a little bit. Do you think that this method > will resolve some of above problems? As you mentioned yourself, there are SSH servers (e.g. OpenSSH) which do not recode the arguments of commands from UTF-8 to the locally used encoding -- they simply take the byte stream they read from a command (e.g. stat()) and pass it to the OS.=20 As a result, on a system where no recoding happens and a user=20 can not or does not want to use UTF-8 for file and directory=20 path encoding, the user needs to be able to specify the encoding=20 that Jsch should use when sending file and path names. Only with=20 custom selected encoding can the user produce the right byte=20 stream for file and path names that the remote side needs. That's what I think -- I might be wrong though and I'm happy to dicuss these things. Thanks, Martin |
From: <ym...@jc...> - 2007-09-27 06:33:21
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Wed, 26 Sep 2007 13:15:20 +0200 _______________________ | | >> | - provide a ChannelSftp.setControlEncoding() |As you mentioned yourself, there are SSH servers (e.g. OpenSSH) |which do not recode the arguments of commands from UTF-8 to |the locally used encoding -- they simply take the byte stream |they read from a command (e.g. stat()) and pass it to the OS. |As a result, on a system where no recoding happens and a user |can not or does not want to use UTF-8 for file and directory |path encoding, the user needs to be able to specify the encoding |that Jsch should use when sending file and path names. Only with |custom selected encoding can the user produce the right byte |stream for file and path names that the remote side needs. Frankly to say, I have hesitated to add such an API, which expects the sftpd's noncompliances to the sftp protocol[1]. Other sftpd implementations may have supported it correctly and OpenSSH may suddenly change its implementation in the future. I think that the proposed method may become the source of the trouble. If that method is added, are you really planning to use it in your product? It must be easy to add that method, but I really worry about the result. [1] http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 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/ |