PuTTY not printing a password expiration warning from a SunSSH server

I think I saw that before but it popped up now again. One of our customers complains that PuTTY (did you know that PuTTY runs on Symbian as well?) is not displaying a warning message about a password expiration when run against the SunSSH server. So, while both OpenSSH and SunSSH clients print the following warning when a correct password is provided but it is expired:

Password:
Warning: Your password has expired, please change it now.
New Password:

PuTTY (even the last version 0.60 out there) prints just this:

login as: janp
Using keyboard-interactive authentication.
Password:
Using keyboard-interactive authentication.
New Password:

It might confuse users since they do not know what is going on and why the new password is requested. What is worse is that it does not show other warnings either about why the password has not been accepted. See SunSSH's output:

Password: 
Warning: Your password has expired, please change it now.
New Password: 
sshd-kbdint: Password too short - must be at least 6 characters.

PuTTY, however, prints just this:

login as: janp2
this is a banner
Using keyboard-interactive authentication.
Password:
Using keyboard-interactive authentication.
New Password:
Using keyboard-interactive authentication.
New Password:

The reason why PuTTY does not show the warnings is that the SSH_MSG_USERAUTH_INFO_REQUEST packet returned by the SunSSH server, the one containing the warning, does not contain any prompts. And, if the packet does not contain any prompts PuTTY does not show the instruction field. However, sending the packet without any prompts is perfectly OK according to the SSH protocol specification for the keyboard-interactive authentication method (RFC 4256, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH):

The num-prompts field may be `0', in which case there will be no prompt/echo fields in the message, but the client SHOULD still display the name and instruction fields (as described below).

Strictly speaking, it is not againt the SSH protocol not to show the instruction field since the word "SHOULD" was used but I consider it a bug anyway. See RFC 2119, Key words for use in RFCs to Indicate Requirement Levels about explanation of the word "SHOULD" in RFC documents. To make the patch really simple so that I do not have to change indentation, the following small change seems to fix the issue. The final fix might look differently, of course. It will make PuTTY to always use the get_userpass_input() function. I checked that it should really be OK since if the number of prompts is 0, the instruction field is printed and the function returns without trying to prompt the user:

--- ssh.c-old   Sat Dec 12 17:55:58 2009
+++ ssh.c       Sat Dec 12 17:56:16 2009
@@ -7478,7 +7478,7 @@
                    /\*
                     \* Get the user's responses.
                     \*/
-                   if (s->num_prompts) {
+                   {
                        int ret; /\* not live over crReturn \*/
                        ret = get_userpass_input(s->cur_prompt, NULL, 0);
                        while (ret < 0) {

If you want to use the patch you are doing it at your own risk, of course. Note that the patch should contain some tabelators so do not paste it, get it here (use gpatch on Solaris, not patch). Or, just edit the ssh.c file. Open it in a text editor and go to line 7481. After the patch is applied and PuTTY is recompiled, you can see all those warnings now:

login as: janp
Using keyboard-interactive authentication.
Password:
Using keyboard-interactive authentication.
Warning: Your password has expired, please change it now.
Using keyboard-interactive authentication.
New Password:
Using keyboard-interactive authentication.
sshd-kbdint: Password too short - must be at least 6 characters.
Using keyboard-interactive authentication.
New Password:
Using keyboard-interactive authentication.
sshd-kbdint: The password must contain at least 1 numeric or special character(s).

Using keyboard-interactive authentication.
New Password:
...
...

UPDATE: After I wrote this blog entry, I checked the latest PuTTY code and I can see in the PuTTY's repository that the fix has been already there since Sep 2008, see the revision ID 8172 or the problem description. Aside from some comment changes, the code change is the same as shown above. However, there is no new PuTTY release having the fix. The last version 0.60 was released in 2007-04-29 and I have no idea when to expect a new one. On the other hand, you can always try the development snapshot, see the PuTTY download page.

Comments:

This is one annoying impedance mismatch between keyboard-interactive and PAM. PAM conversations can include any number of informational and error messages, as well as any number of prompts (echo on or off). But keyboard-interactive has a single slot for an informational message string, with unlimited slots only for prompts. This means that sshd has to gather all informational/error messages from a PAM conversation and then format them as a single string. \*sigh\*

Posted by Nico on December 14, 2009 at 12:48 PM CET #

I've been combing your weblog tyring to find reference to the change in sftp where batch mode processing will accept a "-" in front of the command to continue on failure. It is in the Feb 2010 "beta" documentation but I could find no reference to this feature or any version that may included it. Can you post information on this or point us in a direction???

Posted by Russ on February 20, 2010 at 09:47 PM CET #

Russ, check "6481668 sftp(1)/sftp-server(1m) needs a resync with OpenSSH" which hasn't been backported to S10.

Posted by Jan on February 24, 2010 at 04:51 AM CET #

Hi Jan,
I know this is not the proper venue, and i apologize for the off-topic intrusion, but i thought you could possibly help me with an issue. related to this issue: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6540060
bug report on OpenSolaris, which relates to an issue i'm having and could not find information on it anywhere.

Maybe if you could possibly tell me what was the fix for that bug, as i'm having similar "alert bad record mac" error during load on an OpenSsl project, usually on the negotiation phase, and racking my brains on it for a week now.

Threading callbacks are implemented.

Maybe you can shed some light on the reason for these errors? or maybe point to where i can find information?

Any reply will be greatly appreciated.

Sincerly
Amit

Posted by Amit on June 29, 2010 at 07:44 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Jan Pechanec

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today