Dear Yamanaka-san, Sorry to bother you again, but I just might need your help again.
As mention before, I test Jsch 0.1.35 from the command line. I test it to connect from Linux to Linux + Solaris, Solaris to Linux + Solaris, and Windows to Linux and Solaris. After sorting out the stderr messages that we discussed over the last e-mails, I was able to test the Unix programs successfully. In other words, a jsch program on unix connects successfully to a Unix machine to - Scp put and get a file, - Sftp put and get a file, and - open a shell, and all of the above were successful uses password and RSA and DSA keys. Then I proceed to test Windows, using Cygwin and Eclipse Europa. Surprisingly, Scp works fine, and so does the Shell programs, but Sftp fails on the put command. It appears that the path is somehow filtered and the backslashes were removed, resulting in a message of the form: 4: java.io.FileNotFoundException: Q:2007jschWin_0.1.35verifyp.htm (The system cannot find the file specified) It should have been Q:\2007\jsch\Win_0.1.35\verify\p.htm instead. The Sftp.java program I use is attached for your reference. As you can see, it is modified from the Sftp.java program in the examples directory, though based on one that is probably taken from 0.1.20. However, I tested the 0.1.35 Sftp.java in the examples directory and a similar message is received; the backslashes are all taken out somehow. Do you have the same problem on a Windows platform or is this just my issue? Best regards. --- cllee This e-mail is classified as INTERNAL USE ONLY. -- Chia-Ling LEE IT Security Risk Management UBS AG, Stamford Branch 400 Atlantic St, Stamford, CT 06901 Tel: +1-(203)719-3486 E-mail: [EMAIL PROTECTED] Internet: www.ubs.com -----Original Message----- From: Lee, Chia-Ling Sent: Friday, October 19, 2007 1:32 PM To: 'Atsuhiko Yamanaka' Cc: [email protected] Subject: RE: [JSch-users] ANNOUNCE: JSch 0.1.35 Dear Yamanaka-san, 1) Turns out that the messages is appearing in stderr, not stdout. Since my tests (based on the Makefile sent previously) are completely command line based, the messages all appeared together with stdout. 2) I tried -Djavax.security.auth.useSubjectCredsOnly=false That did not work at all, even when I use Java5 (normally, for reasons of my own, I use 1.4.2 and modify build.xml to force ant to use 1.4.2). Both gave the following error message: java.lang.SecurityException: Unable to locate a login configuration If I have more time, I might look into this a little more. 3) Going back to the GSSException error message (in stderr), it appears that the message is generated purely by Sun's jgss library, so it is not an issue with jsch. Just in case, here it is again: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Ticket) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential .java:143) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFact ory.java:70) at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.jav a:149) at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:334) at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:59) at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:36) at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:96 ) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:178) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:158) at com.jcraft.jsch.jgss.GSSContextKrb5.init(Unknown Source) at com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at ScpTo.main(ScpTo.java:53) ScpTo Password SUCCESS All the connections completed successfully, just that these error messages is annoying. So, once again, there is no impact on the technical functionality of Jsch; it is just that if those messages can be suppressed, it would be cleaner. 4) Removing UserAuthGSSAPIWiMIC.java and building jsch removed the problem completely; no more GSSException error messages. 5) Therefore, right now, there are a few options available to me: a) Advise users that if they use 0.1.35 there will be additional GSSException messages in stderr that they can safely ignore b) Advise users to set the PreferredAuthentications option before session.connect c) Build jsch without UserAuthGSSAPIWiMIC.java but let users know that this is how it is built in my organisation Because I want to keep the build as true to what is available from Jcraft, I would probably pursue (a). Let me know if there are other options I missed. Again, thanks for your help. Best regards. --- cllee This e-mail is classified as INTERNAL USE ONLY. -- Chia-Ling LEE IT Security Risk Management UBS AG, Stamford Branch 400 Atlantic St, Stamford, CT 06901 Tel: +1-(203)719-3486 E-mail: [EMAIL PROTECTED] Internet: www.ubs.com -----Original Message----- From: Atsuhiko Yamanaka [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 9:51 PM To: Lee, Chia-Ling Cc: [email protected] Subject: Re: [JSch-users] ANNOUNCE: JSch 0.1.35 Hi, +-From: <[EMAIL PROTECTED]> ---------- |_Date: Thu, 18 Oct 2007 11:12:57 -0400 __ | |GSSException: No valid credentials provided (Mechanism level: Failed to |find any Kerberos Ticket) I found this message on Java5's tutorial page[1], it seems -Djavax.security.auth.useSubjectCredsOnly=false will sold this problem. I, however, can not understand why it appears on the stdout. Is it from JavaVM, not from jsch? |In any case, your suggestion worked. Adding that line to everyone of my |test file now allows the connection to succeed without those messages. |Still, that would mean that every application that wants to now use the |0.1.35 library instead of the 0.1.30 library will now have to modify |their code. I would have preferred that those error message be |suppressed automatically in the Jsch source code, if it makes sense.=20 How about deleting com/jcraft/jsch/serAuthGSSAPIWiMIC.class from the 0.1.35.jar file? [1] http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubl eshooting.html 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/
Sftp.java
Description: Sftp.java
Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
------------------------------------------------------------------------- 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 a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ JSch-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsch-users
