Bugzilla – Full Text Bug Listing
| Summary: | [SSH2] An undetermined authentication failure | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tomasz Zarna <tomasz.zarna> | ||||||||||||||||
| Component: | CVS | Assignee: | Krzysztof Daniel <krzysztof.daniel> | ||||||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||||||
| Severity: | normal | ||||||||||||||||||
| Priority: | P3 | CC: | Brian_Young, jacek.pospychala, krzysztof.daniel, Szymon.Brandys, ymnk | ||||||||||||||||
| Version: | 3.4.1 | ||||||||||||||||||
| Target Milestone: | 3.6 M1 | ||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||
| OS: | Windows XP | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Tomasz Zarna
Created attachment 123854 [details]
Temporary workaround by Jacek
Jacek has provided patch that rolls back the authentication mechanism, this is a workaround.
yes, so far I have found that problem appears only when using "gssapi-with-mic" authentication. SSH connection worked in Eclipse 3.2.2 (jsch-0.1.28) which didn't had this authentication yet, but fails will all further Eclipse versions (Eclipse 3.3/jsch-0.1.31, Eclipse 3.4/jsch-0.1.37, jsch-0.1.41) which use this method as default. jsch also worked for me with OpenSSH_4.3p2, OpenSSL 0.9.8b (I don't have 0.9.8a) I don't know configuration details of the problematic ssh server, but can get that if needed. (In reply to comment #3) > jsch also worked for me with OpenSSH_4.3p2, OpenSSL 0.9.8b (I don't have > 0.9.8a) > > I don't know configuration details of the problematic ssh server, but can get > that if needed. > I guess that RuntimeException has been thrown at com.jcraft.jsch.UserAuthGSSAPIWithMIC#start method in invoking GSS API. Which JVM are you using? Is it from Sun or IBM? Even if such an exception is thrown, it should be ignored silently and the next authentication method should be tried. It must be a bug in jsch. I can not reproduce such a problem in my environment. May I ask you to check if my guess is right? The soure code plugins are available at http://eclipse.jcraft.com/plugins/com.jcraft.jsch.source_0.1.37.v200803061811.jar http://eclipse.jcraft.com/plugins/com.jcraft.jsch.source_0.1.41.jar or http://eclipse.jcraft.com/ as the update site. (In reply to comment #4) > in invoking GSS API. Which JVM are you using? Is it from Sun or IBM? I tried Sun and IBM with no difference. Let me check the RuntimeException I'm testing with jsch-0.1.41 When connecting, UserAuthGSSAPIWithMIC.start() hangs at read and throws following exception: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at com.jcraft.jsch.IO.getByte(IO.java:82) at com.jcraft.jsch.Session.read(Session.java:809) at com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(UserAuthGSSAPIWithMIC.java:77) at com.jcraft.jsch.Session.connect(Session.java:419) at com.jcraft.jcterm.JSchSession.createSession(JSchSession.java:101) at com.jcraft.jcterm.JSchSession.getSession(JSchSession.java:49) at com.jcraft.jcterm.JCTermSwingFrame.run(JCTermSwingFrame.java:155) at java.lang.Thread.run(Unknown Source) (In reply to comment #6) > I'm testing with jsch-0.1.41 > When connecting, UserAuthGSSAPIWithMIC.start() hangs at read and throws > following exception: > > java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(Unknown Source) > at com.jcraft.jsch.IO.getByte(IO.java:82) > at com.jcraft.jsch.Session.read(Session.java:809) > at com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(UserAuthGSSAPIWithMIC.java:77) Thank you for your help. It seems that, in negotiating authentication methods, remote sshd states that it supports gssapi-with-mic, but it has not be correctly configured. It seems sshd has hanged-up. Do you have openssh client? If you have, may I ask you to connecting to that sshd? % ssh -v -v -v xxx@yyyyyy The recent openssh client will also try "gssapi-with-mic" at first. I have connected to that host using putty.exe and there: $ ssh -v -v -v testcvs@localhost debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /home/testcvs/.ssh/identity type -1 debug1: identity file /home/testcvs/.ssh/id_rsa type -1 debug1: identity file /home/testcvs/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, 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.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 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 debug2: dh_gen_key: priv key bits set: 129/256 debug2: bits set: 517/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/testcvs/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/testcvs/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 0 for host localhost debug3: check_host_in_hostfile: filename /home/testcvs/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /home/testcvs/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 2 for host localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is e6:af:2e:00:3a:0c:a5:81:02:af:da:1f:f0:4b:7b:00. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. debug2: bits set: 502/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/testcvs/.ssh/identity ((nil)) debug2: key: /home/testcvs/.ssh/id_rsa ((nil)) debug2: key: /home/testcvs/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-with-mic,password debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug1: Miscellaneous failure Unknown code krb5 195 debug1: Miscellaneous failure Unknown code krb5 195 debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/testcvs/.ssh/identity debug3: no such identity: /home/testcvs/.ssh/identity debug1: Trying private key: /home/testcvs/.ssh/id_rsa debug3: no such identity: /home/testcvs/.ssh/id_rsa debug1: Trying private key: /home/testcvs/.ssh/id_dsa debug3: no such identity: /home/testcvs/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password testcvs@localhost's password: debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 0 debug3: tty_make_modes: 7 0 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 0 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 0 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug1: Sending environment. debug3: Ignored env HOSTNAME debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env HISTSIZE debug3: Ignored env SSH_CLIENT debug3: Ignored env QTDIR debug3: Ignored env QTINC debug3: Ignored env SSH_TTY debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env MAIL debug3: Ignored env PATH debug3: Ignored env INPUTRC debug3: Ignored env PWD debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env SSH_ASKPASS debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env QTLIB debug3: Ignored env CVS_RSH debug3: Ignored env SSH_CONNECTION debug3: Ignored env LESSOPEN debug3: Ignored env G_BROKEN_FILENAMES debug3: Ignored env _ debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Note: debug1: Next authentication method: gssapi-with-mic debug1: Miscellaneous failure Unknown code krb5 195 There's noticeable delay before "Miscellaneous failure" appears. Atsuhiko, how about a following fix to com.jcraft.jsch.Session.connect(int):
catch(RuntimeException ee){
throw ee;
}
+ catch(IOException ioe) {
+ auth_cancel=false;
+ continue loop;
+ }
catch(Exception ee){
//System.err.println("ee: "+ee); // SSH_MSG_DISCONNECT: 2 Too many authentication failures
break loop;
(In reply to comment #9) > Note: > debug1: Next authentication method: gssapi-with-mic > debug1: Miscellaneous failure > Unknown code krb5 195 > There's noticeable delay before "Miscellaneous failure" appears. How long noticable delay? (In reply to comment #10) > Atsuhiko, how about a following fix to com.jcraft.jsch.Session.connect(int): > catch(RuntimeException ee){ > throw ee; > } > + catch(IOException ioe) { > + auth_cancel=false; > + continue loop; > + } > catch(Exception ee){ > //System.err.println("ee: "+ee); // SSH_MSG_DISCONNECT: 2 Too > many authentication failures > break loop; IMHO, I guess that change will not resolve your problem, because IOExecption means that the TCP connection has been dropped. Have you succeed with this change? re delay: it could be few seconds. Hard to say, because it was remote host and I had generally slow connection. I no longer have access to that host so I played with it by explicitely throwing SocketTimeoutException in UserAuthGSSAPIWithMIC.java:77 Then catching IOException in Session.connect helped, but you're right, with real STE connection would be dropped. I have look at this case and I have some thoughts: debug1: Miscellaneous failure Unknown code krb5 195 (1) Code 195 means that something wrong at the server side. For us it is not important what. The interesting thing is that server provides us with error code. (2) regular SSH is able to connect to the server and displays error message (3) The IOException happens at the beginning of com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(Session) while (true) loop. The (3) looks like first read but I doubt if it is really first if (2) receives feedback. I'd rather assume that this loop goes once and after second attempt it receives no answer from server. This indicates that SSH_MSG_USERAUTH_BANNER was returned (line 102-111) and the message is ignored. Atsuhiko-san, Is this possible? (In reply to comment #14) > I have look at this case and I have some thoughts: > > debug1: Miscellaneous failure > Unknown code krb5 195 > > (1) Code 195 means that something wrong at the server side. For us it is not > important what. The interesting thing is that server provides us with error > code. > > (2) regular SSH is able to connect to the server and displays error message > > (3) The IOException happens at the beginning of > com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(Session) while (true) loop. > > The (3) looks like first read but I doubt if it is really first if (2) receives > feedback. > > I'd rather assume that this loop goes once and after second attempt it receives > no answer from server. This indicates that SSH_MSG_USERAUTH_BANNER was returned > (line 102-111) and the message is ignored. IMHO, I don't think so. If BANNER is received, it will be displayed by userinfo.showMessage(message) and, at that timing, krb5 has not been requested yet. The krb5 will be requested at line 146. As for the success of regular SSH, it will wait for the response from the remote forever. On the other hand, extssh will wait for it with timeout. If the long period is given as the timeout, extssh will also be able to connect to that server, but with long delay at every connection trials. The essence of the problem is that the remote sshd lists unavailable auth method "gssapi-with-mic". Should we allow users to choose preferred auth methods at Window > Preferences > General > Network Connections > SSH2 ? Created attachment 141630 [details]
Screenshot
Is something like this sufficient?
Created attachment 141631 [details]
Patch proposition
A patch that allows for disabling particular authentication methods
Created attachment 141632 [details]
mylyn/context/zip
(In reply to comment #16) > Created an attachment (id=141630) [details] > Screenshot > > Is something like this sufficient? > IMHO, it must be enough for this bugzilla entry, but it may be nice if users are allowed to choose the order of auth methods. Created attachment 141995 [details]
Patch that allows for method order selection
Created attachment 141996 [details]
mylyn/context/zip
Created attachment 141997 [details]
Solution preview
Atsuhiko-san, will you find time to review latest patch? Sorry for my delay. (In reply to comment #23) > Atsuhiko-san, > > will you find time to review latest patch? I'll promise to review it in this weekend, and response to this entry soon. (In reply to comment #23) > Atsuhiko-san, > > will you find time to review latest patch? > I have reviewed it, and have not found any problem. I think it should be committed. (In reply to comment #25) > (In reply to comment #23) > > Atsuhiko-san, > > > > will you find time to review latest patch? > > > > I have reviewed it, and have not found any problem. > I think it should be committed. > Could you do that? Are there any plans to release my patch? (In reply to comment #27) > Are there any plans to release my patch? > It has been committed to the HEAD. Marking as fixed. The code is there. Ordering and enabling authentication methods works correctly. |