Community
Participate
Working Groups
Build Identifier: 3.6.0 GA We are using the jcraft SSH client to connect the the zLinux system with the password authentication. In the case the the user password is expired, we expect the user to be prompted for the new password, which will be handled by the userInfo we provide. Our userInfo is an instance of UIKeyboardInteractive. But promptKeyboardInteractive() of our userInfo was not called. And the session appears to be an active one which it is not. It was found that the return code command somehow was SSH_MSG_USERAUTH_SUCCESS instead of SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. Please advise. Reproducible: Always
I assume SSH is contributed by CVS. If not, please reassign.
3.6 is using com.jcraft.jsch in version 1.41. Could you try doing the same thing with JSch 1.44, which is available on Orbit[1]? [1] http://wiki.eclipse.org/Orbit/FAQ#How_do_I_work_with_a_bundle_in_Orbit.3F
I think this is a duplicate of Bug 109043.
Tested with JSch 1.44 and ran into the same problem. Here is what was found with the Logger class provided in bug 320665. 1. When using keyboard-interactive authentication, the expired password was detected and the user was prompted for new password 2. When using password authentication, the session was connected and the user was brought to the session console and asked for changing password from there. Since our application does really open a command shell, we need the SSH client to handle it for us as in the interactive authentication. 3. The following messages are genereated by Logger. INFO: Authentications that can continue: publickey,keyboard-interactive,password INFO: Next authentication method: publickey INFO: Authentications that can continue: keyboard-interactive,password INFO: Next authentication method: keyboard-interactive INFO: Authentications that can continue: password INFO: Next authentication method: password INFO: Authentication succeeded (password). Password change requested. Choose a new password. WARNING: Your password has expired. You must change your password now and login again! Changing password for tpftvt4. Old Password:
Atsuhiko, any suggestions? Could it be fixed in the next release?
(In reply to comment #4) > 2. When using password authentication, the session was connected and the user > was brought to the session console and asked for changing password from there. > Since our application does really open a command shell, we need the SSH client > to handle it for us as in the interactive authentication. As explained in Bug 109043, the reason for the prompt for changing password is that it has been run with pty. The one of problems is that the remotely execed command "cvs server" will be run without pty, and the prompt must not be given. Of course, it will be possible to run "cvs server" with pty, but it may change its behavior and may break the functionality of r.e.t.cvs.core plug-in.
Well, our usage of SSH client doesn't involve cvs and I think the SSH client should be more general.
(In reply to comment #7) > Well, our usage of SSH client doesn't involve cvs and I think the SSH client > should be more general. In that case, the process for changing password will be done over I/O streams from remotely executed command, and it is difficult to find if messages from input-stream is for changing password or not. In fact, the following message, Password change requested. Choose a new password. WARNING: Your password has expired. You must change your password now and login again! Changing password for tpftvt4. Old Password: depends on the implementation of sshd and there is no normal definition. IMHO, this bugzilla entry should be marked as WONTFIX, and users should be recommended to use keyboard-interactive or publickey auth method.
I still hope this can be fixed in the SSH client for the following reasons. 1. It may not be an easy fix. But if the problem is passed over to the user of the SSH client, the user needs to handle exactly the same situation. 2. The user of SSH client can only fix the problem for himself while the fix in the SSH client will benifit all the users 3. The owner of SSH client knows much more than the user abut this SSH client and it would be relatively easier to come up with a better fix.
(In reply to comment #9) Samuel, couldn't you just switch to use keyboard-interactive?
We actually need support to both interactive and password authentication. Some customers choose to turn off interactive/password authentication for some reason.
From an offline discussion with Samuel it looks like the workaround is to use Putty which handles this case correctly. I think it would be nice to handle it seamlessly in Eclipse. What do you think Atsuhiko?
We just found out that keyboard-interactive authentication is not supported on zOS (see bug 320665).
(In reply to comment #13) > We just found out that keyboard-interactive authentication is not supported on > zOS (see bug 320665). So it is even more important now to have the password authentication handled properly.
(In reply to comment #12) > From an offline discussion with Samuel it looks like the workaround is to use > Putty which handles this case correctly. I think it would be nice to handle it > seamlessly in Eclipse. What do you think Atsuhiko? I don't think that it is possible to support such a case efficiently without disturbing behaviors for usual cases. As I had written, the problem is that password reset process will be done on I/O stream of executed command.
(In reply to comment #15) > (In reply to comment #12) > > From an offline discussion with Samuel it looks like the workaround is to use > > Putty which handles this case correctly. I think it would be nice to handle it > > seamlessly in Eclipse. What do you think Atsuhiko? > > I don't think that it is possible to support such a case efficiently > without disturbing behaviors for usual cases. As I had written, the problem > is that password reset process will be done on I/O stream of executed command. How do other clients e.g. Putty handle it then? Do you know? And what did you mean by "without disturbing behaviors for usual cases"? (In reply to comment #8) > In fact, the following message, > > Password change requested. Choose a new password. > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for tpftvt4. > Old Password: > > depends on the implementation of sshd and there is no normal definition. Maybe we could handle the most popular cases and just give users a way to define messages that should be treated as requests for password change?
(In reply to comment #16) > How do other clients e.g. Putty handle it then? Do you know? Putty is a terminal emulator, and terminal emulators can handle it. You may know that terminal emulator plug-ins like "Target Management"[1] and our JCTerm[2] will handle it successfully. > And what did you > mean by "without disturbing behaviors for usual cases"? It will be possible to write code for such a rare case, but it will cause the problem for the normal or usual case. I have worried that we have not shared the consensus what is the problem. If the consensus has been shared, it is trivial what kind of code should be written. > (In reply to comment #8) > Maybe we could handle the most popular cases and just give users a way to > define messages that should be treated as requests for password change? Do you mean add a preference page for it? Frankly to say, I'll not write code for this bugzilla entry, but if you write it, I may be able to support you. [1] http://eclipse.org/tm/ [2] http://www.jcraft.com/eclipse-jcterm/
(In reply to comment #17) > (In reply to comment #16) > > How do other clients e.g. Putty handle it then? Do you know? > > Putty is a terminal emulator, and terminal emulators can handle it. > You may know that terminal emulator plug-ins like "Target Management"[1] > and our JCTerm[2] will handle it successfully. Correct me if I am wrong, but even if I use JCTerm or TM Terminal I have to know first that my password expired. Samuel got SSH_MSG_USERAUTH_SUCCESS. Despite it the session was inactive, so he tried Putty and then he realized where the problem was. I guess he would expect at least some kind of notification that the password expired. Then he could change it using JCTerm, TM Terminal or even Putty.
(In reply to comment #18) > Correct me if I am wrong, but even if I use JCTerm or TM Terminal I have to > know first that my password expired. Samuel got SSH_MSG_USERAUTH_SUCCESS. > Despite it the session was inactive, so he tried Putty and then he realized > where the problem was. > > I guess he would expect at least some kind of notification that the password > expired. Then he could change it using JCTerm, TM Terminal or even Putty. The session is 'active'. After 'successful' login, password re-setting prompt will appear on the terminal emulator instead of the shell prompt. I hope you to try one of them by yourself.
(In reply to comment #19) > > I guess he would expect at least some kind of notification that the password > > expired. Then he could change it using JCTerm, TM Terminal or even Putty. > > The session is 'active'. After 'successful' login, password re-setting > prompt will appear on the terminal emulator instead of the shell prompt. > I hope you to try one of them by yourself. I should have been more precise. These are Samuel's steps: 1. His client tries to connect to a ssh server using jsch. 2. There is no notification about expired password. 3. Now he opens a terminal (Putty, but he could use JCTerm or TM Terminal) and there he sees the password change prompt. My point was, it would be nice, if during 1) jsch could log a warning or show a prompt saying that the password expired. Then the user could just open a terminal and change the password there.
(In reply to comment #20) > (In reply to comment #19) > > > I guess he would expect at least some kind of notification that the password > > > expired. Then he could change it using JCTerm, TM Terminal or even Putty. > > > > The session is 'active'. After 'successful' login, password re-setting > > prompt will appear on the terminal emulator instead of the shell prompt. > > I hope you to try one of them by yourself. > > I should have been more precise. These are Samuel's steps: > 1. His client tries to connect to a ssh server using jsch. > 2. There is no notification about expired password. > 3. Now he opens a terminal (Putty, but he could use JCTerm or TM Terminal) and > there he sees the password change prompt. Your previous question is the following, (In reply to comment #16) > How do other clients e.g. Putty handle it then? Do you know? So, I have just introduced that other clients in Eclipse plug-ins will handle it successfully. > My point was, it would be nice, if during 1) jsch could log a warning or show a > prompt saying that the password expired. Then the user could just open a > terminal and change the password there. As I have written several times, sshd will drop the connections immediately in processing remote exec request without pty for that case. This is the problem of the remote sshd, and ssh clients have nothing to do for it.
This issue should be addressed either by the client using Jsch library or sshd on zOs by adding the keyboard-interactive mode. In both cases this is not Eclipse. Thanks Atsuhiko for shedding light on it.
