openssh bugs - Sep 2005 - [Bug 1087] SSH fails to show PAM password expiry message from LDAP on login

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Group|Portable OpenSSH            |






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From senthilkumar_sen at hotpop.com  2005-09-21
19:54 -------
The problem happens because the messages generated from PAM_Acct_Mgmt() get 
displayed to client only if it not returns PAM_SUCCESS or PAM_NEW_AUTHTOK_REQD. 
But as expiry messages are warning ones they are not getting displayed here 
because pam_acct_mgmt() returns PAM_SUCCESS here. The following code part in 
auth2.c is responsible for this,

#ifdef USE_PAM
	if (options.use_pam && authenticated) {
		if (!PRIVSEP(do_pam_account())) {
			/* if PAM returned a message, send it to the user */
			if (buffer_len(&loginmsg) > 0) {
				buffer_append(&loginmsg, "\0", 1);
				userauth_send_banner(buffer_ptr(&loginmsg));
				packet_write_wait();
			}
			fatal("Access denied for user %s by PAM account "
			   "configuration", authctxt->user);
		}
	}
#endif

I think fix would be easy for me if the above said reason is correct?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From selvesteen at gmail.com  2005-09-22 00:27
-------
The problem also seen with PAM_UNIX. In HP-UX (Trusted Mode) SSH 4.2 misses to
report the message to the client.
For Example ( Using SSH 3.9 ) :
Password:
Last   successful login for test: Wed Sep 21 22:00:18 PST-5:30 2005
Last unsuccessful login for test: NEVER
Your password will expire on Thu Sep 22 05:30:00 PST-5:30 2005

But this message is missed when I use SSH 4.0 and above. I suspect this problem
may be a side effect of the bug http://bugzilla.mindrot.org/show_bug.cgi?id=892

B'coz when I removed "buffer_clear(&loginmsg);" from monitor.c
(line :839) I can
see the message on client side.

Please let us know your views.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From dtucker at zip.com.au  2005-09-22 12:27 -------
It looks like you're using keyboard-interactive authentication, right?  If
so, I
think this is actually bug #1028.  (sshd tries to send as much of the PAM
exchange as possible via keyboard-interactive, however doesn't quite get it
quite right).

If you force password authentication with 4.2 (eg "ssh -o
preferredauthentications=password foo.example.com") does the warning
appear?

(BTW: I had not applied the patch in bug #1028 because it occured to me that
it's a special case the message handling mentioned at
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111973493522390&w=2
(look for
"For the SSHv2/kbdint case I guess it could pass the messages
through") where
sshd could generate N kbdint messages rather than accumulating them, where N==0.
 I intended to get to this before 4.2 but didn't.  In hindsight, I should
have
committed the patch then for replacement later).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From selvesteen at gmail.com  2005-09-22 14:22
-------
No, The warning have'nt appeared even when I forced password authentication
with
4.2

# ssh -o'preferredauthentications=password'  pluto
root at pluto's password:
Last login: Thu Sep 22 12:05:44 2005 from pluto

I also tried patch in bug #1028 but it too failed.

Please let me know any other methods to try or test.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From selvesteen at gmail.com  2005-09-22 14:23
-------
Created an attachment (id=960)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=960&action=view)
server log

server debug log attached



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From selvesteen at gmail.com  2005-09-22 14:24
-------
Created an attachment (id=961)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=961&action=view)
cleint log

client debug log attached



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


selvesteen at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    Attachment #961|cleint log                  |client log
        description|                            |






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From senthilkumar_sen at hotpop.com  2005-09-22
14:39 -------
I think the pam_acct_mgmt() returns PAM_SUCESS here. Its not returning 
PAM_AUTH_ERR as described in bug #1028 which is a separate scenario. This 
message is just a warning from PAM and the PAM module returns success. But the 
thing is tht only messages are sent back to client if PAM_SUCESS is not returned
by pam_acct_mgmt(). The code part doing this is in auth-pam.c 

if (sshpam_err != PAM_SUCCESS && sshpam_err != PAM_NEW_AUTHTOK_REQD) {
		sshpam_account_status = 0;
		return (sshpam_account_status);
	}

This can also be viewed from the update of attachment id 960,
> debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success)
I also checked that the warning messages get collected properly but they are not
passed to client as said in comment #1.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From senthilkumar_sen at hotpop.com  2005-09-22
21:30 -------
Created an attachment (id=962)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=962&action=view)
Patch to send PAM messages to client even on PAM_SUCCESS

The attached patch will send PAM messages back to the client even on
PAM_SUCCESS. I used priv_sep flag to turn off duplicate warnings that are
generated with privilegeseparation off. Im not sure whether this breaks any
other behaviour.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From dtucker at zip.com.au  2005-09-28 20:31 -------
(From update of attachment 962)
> userauth_finish(Authctxt *authctxt, int authenticated, char *method)
> {
>        char *methods;
>+       int ret;
A minor style point: this will cause "unused variable" warnings when
compiling
without PAM.  To avoid this put the variable declaration inside an #ifdef,
where possible at the start of an existing {} block.
>        if (options.use_pam && authenticated) {
>-               if (!PRIVSEP(do_pam_account())) {
>+               ret = PRIVSEP(do_pam_account());
>+
>+               if(use_privsep)
>                        /* if PAM returned a message, send it to the user */
Using use_privsep for this means you'll get different behaviour with and
without privsep.  I prefer to avoid this where possible, so I would just clear
loginmsg after sending the message to the user.

Will attach an updated patch shortly.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #962 is|0                           |1
           obsolete|                            |




------- Additional Comments From dtucker at zip.com.au  2005-09-28 21:01 -------
Created an attachment (id=969)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=969&action=view)
Rework patch #962

Thinking about it, the extra SSH2 Banner messages may prove annoying to GUI
users if they cause additional popup dialog boxes.

PuTTY displays them inline, though.  Can any users of other GUI clients confirm
or deny this?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    Attachment #969|                            |ok+
               Flag|                            |




------- Additional Comments From djm at mindrot.org  2005-09-28 21:29 -------
(From update of attachment 969)
This looks sane to me. The spec says multiple SSH_MSG_USERAUTH_BANNER messages
are OK too.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From senthilkumar_sen at hotpop.com  2005-09-28
22:36 -------
Yes, My GUI client shows the expiry messages in a pop up window which I think is
an intended one.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From dtucker at zip.com.au  2005-09-28 22:40 -------
I suspect that will become annoying fast.  Let me see if there's another way
to
resolve this that won't bug GUI users.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


t8m at centrum.cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t8m at centrum.cz




------- Additional Comments From t8m at centrum.cz  2005-09-29 23:00 -------
This will leave the message from pam_account in loginmsg to be picked up later
when pty is allocated.

--- openssh-4.1p1/monitor.c.nologin     2005-06-29 11:30:56.000000000 +0200
+++ openssh-4.1p1/monitor.c     2005-06-29 11:32:18.000000000 +0200
@@ -854,9 +854,7 @@
        ret = do_pam_account();

        buffer_put_int(m, ret);
-       buffer_append(&loginmsg, "\0", 1);
-       buffer_put_cstring(m, buffer_ptr(&loginmsg));
-       buffer_clear(&loginmsg);
+       buffer_put_string(m, buffer_ptr(&loginmsg),
buffer_len(&loginmsg));

        mm_request_send(sock, MONITOR_ANS_PAM_ACCOUNT, m);





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From dtucker at zip.com.au  2005-09-29 23:16 -------
(In reply to comment #14)
> +       buffer_put_string(m, buffer_ptr(&loginmsg),
buffer_len(&loginmsg));
I think this will cause duplicate messages if you have consecutive failures (eg
kbdint auth succeeds but account check fails).  I have an alternative patch
which I'll attach shortly.





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #969 is|0                           |1
           obsolete|                            |




------- Additional Comments From dtucker at zip.com.au  2005-09-29 23:18 -------
Created an attachment (id=972)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=972&action=view)
Only send loginmsg for display if PAM account check fails




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From dtucker at zip.com.au  2005-09-29 23:23 -------
(In reply to comment #15)
> I think this will cause duplicate messages if you have consecutive failures
Make that: if you have a failure followed by a success.

ie if the account check fails the first time and succeeds the second time, when
you log in then you'll get both messages.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From t8m at centrum.cz  2005-09-30 01:26 -------
You'll be disconnected on failure anyway so there can't be the
consecutive
success. Or am I wrong?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From dtucker at zip.com.au  2005-09-30 10:14 -------
(In reply to comment #18)
> You'll be disconnected on failure anyway so there can't be the
consecutive
> success. Or am I wrong?
No, you're right.  It's during keyboard-interactive where this might
happen, not
the generic account check in monitor.c.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From dtucker at zip.com.au  2005-09-30 10:25 -------
OK, Tomas' patch is the simplest fix so I've applied it to both -HEAD
and the
4.2 branch.  Thanks all.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |1047
              nThis|                            |






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1087





------- Additional Comments From t8m at centrum.cz  2005-09-30 18:51 -------
*** Bug 1053 has been marked as a duplicate of this bug. ***



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.