SSH 4.2 fails to show the message "Your password will expire on " from LDAP if privilege separation is enabled. It shows the message on client side when privilege separation is disabled. Also the problem is not found in the releases before SSH 4.0 (SSH 3.8 and SSH 3.9 works correctly) Example : SSH 3.9 ssh <host name> Password: Your password will expire on Thu Sep 22 13:55:27 PST-5:30 2005 Last login: Wed Sep 21 13:55:27 2005 from <host name> SSH 4.0, 4.1, 4.2 ssh <host name> Password: Last login: Wed Sep 21 14:00:35 2005 from <hostname> Note: sshd runs with 'UsePAM yes' using pam_ldap authentication.
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?
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.
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).
No, The warning have'nt appeared even when I forced password authentication with 4.2 # ssh -o'preferredauthentications=password' pluto root@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.
Created attachment 960 [details] server log server debug log attached
Created attachment 961 [details] client log client debug log attached
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.
Created attachment 962 [details] 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.
Comment on attachment 962 [details] Patch to send PAM messages to client even on PAM_SUCCESS > 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.
Created attachment 969 [details] 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?
Comment on attachment 969 [details] Rework patch #962 This looks sane to me. The spec says multiple SSH_MSG_USERAUTH_BANNER messages are OK too.
Yes, My GUI client shows the expiry messages in a pop up window which I think is an intended one.
I suspect that will become annoying fast. Let me see if there's another way to resolve this that won't bug GUI users.
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);
(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.
Created attachment 972 [details] Only send loginmsg for display if PAM account check fails
(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'll be disconnected on failure anyway so there can't be the consecutive success. Or am I wrong?
(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.
OK, Tomas' patch is the simplest fix so I've applied it to both -HEAD and the 4.2 branch. Thanks all.
*** Bug 1053 has been marked as a duplicate of this bug. ***
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.