Is it intentional that password auth using PAM continues trying to log on (giving password 3 prompts) in the case that a user is disabled (so that pam_account returns an error code). It can be argued both ways (saying 'you are disabled' is giving out too much information, making it look like you are entering the wrong password confuses and frustrates the user)
On Tue, Jan 10, 2006 at 01:50:52PM -0800, Paul Moore wrote:> Is it intentional that password auth using PAM continues trying to log > on (giving password 3 prompts) in the case that a user is disabled (so > that pam_account returns an error code). > > It can be argued both ways (saying 'you are disabled' is giving out too > much information, making it look like you are entering the wrong > password confuses and frustrates the user)Which version are you looking at? The last couple of versions will send the output from PAM to the client under most conditions, and there are a couple of fixes in the current development version that should fix the remaining cases (those will be in the next release). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Our test was with 4.1p1 I see that you display a message (if set). But then you proceed to repromt even though the pam module returned a disabled error code. I guess you are saying that the PAM module must tell the user they are disabled. -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Wednesday, January 11, 2006 1:12 AM To: Paul Moore Cc: openssh-unix-dev at mindrot.org Subject: Re: PAM auth with disabled user On Tue, Jan 10, 2006 at 01:50:52PM -0800, Paul Moore wrote:> Is it intentional that password auth using PAM continues trying to log> on (giving password 3 prompts) in the case that a user is disabled (so> that pam_account returns an error code). > > It can be argued both ways (saying 'you are disabled' is giving out > too much information, making it look like you are entering the wrong > password confuses and frustrates the user)Which version are you looking at? The last couple of versions will send the output from PAM to the client under most conditions, and there are a couple of fixes in the current development version that should fix the remaining cases (those will be in the next release). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On Thu, Jan 12, 2006 at 11:45:27AM -0800, Paul Moore wrote:> Our test was with 4.1p1 > > I see that you display a message (if set). But then you proceed to > repromt even though the pam module returned a disabled error code. > > I guess you are saying that the PAM module must tell the user they are > disabled.Yes. As a general rule, sshd tries to give the client no indication as to why an authentication failed. If you want to PAM to provide some information to the client then you can, but you need to configure PAM to do so. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
BTW it is our PAM module. I guess you are saying that the PAM module should have a config choice to say 'generate chatty failure messages'. We then end up with User: joe Password :xxxxxxx Your account is disabled please contact your system administrator Password: Which just looks stupid It can of course be argued that sshd should have the config choice 'explain rejection reasons'. Since the pam_account returns 'account locked' status you know what to say. The nice things about doing it that way is A) I don't have to write any code B) You can be systematic about it (lets say you decide for some non PAM reason to bounce a user - like the user does not exist) C) For non retryable errors (like locked) you can stop prompting (so we don't get the stupidness above) -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Friday, January 13, 2006 5:26 PM To: Paul Moore Cc: dtucker at zip.com.au; openssh-unix-dev at mindrot.org Subject: Re: PAM auth with disabled user On Thu, Jan 12, 2006 at 11:45:27AM -0800, Paul Moore wrote:> Our test was with 4.1p1 > > I see that you display a message (if set). But then you proceed to > repromt even though the pam module returned a disabled error code. > > I guess you are saying that the PAM module must tell the user they are> disabled.Yes. As a general rule, sshd tries to give the client no indication as to why an authentication failed. If you want to PAM to provide some information to the client then you can, but you need to configure PAM to do so. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On Fri, Jan 13, 2006 at 05:47:22PM -0800, Paul Moore wrote:> BTW it is our PAM module. > > I guess you are saying that the PAM module should have a config choice > to say 'generate chatty failure messages'. > > We then end up with > > User: joe > Password :xxxxxxx > Your account is disabled please contact your system administrator > Password:Ah, I see what you're referring to now. That occurs because currently the kbdint code does not distinguish between "authentication failed" (which should be retryable) and "account check failed" (which shouldn't). The non-kbdint code will terminate the connection after the pam_acct_mgmt() fails. The kbdint code doesn't, since it can do pam_chauthtok() via keyboard-interactive, so it needs to learn to treat "account check failed" differently. If you use PasswordAuthentication instead (assuming your module can work with it) then I think you'll get the behaviour you want (although with 4.1p1 you may see the "missing PAM messages" thing I mentioned earlier, if you see that then try a snapshot).> It can of course be argued that sshd should have the config choice > 'explain rejection reasons'. Since the pam_account returns 'account > locked' status you know what to say. The nice things about doing it that > way isWe're not going to add another knob to sshd for this but we can fix the kbdint thing above so it's consistent with the behaviour for the other auth types. It should then do what you want, right? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Here is a complete screenshot. After failing in Kerberos "keybord-interactive", authentication falls to the local "password authentication" (this would happen both before and after modifications, the only difference is the extra message indicating the account is locked). ssh fred.dref at rhel3-host Red Hat Enterprise Linux ES release 3 (Taroon Update 2) Kernel \r on an \m Password: Account cannot be accessed at this time. Please contact your system administrator Password: Account cannot be accessed at this time. Please contact your system administrator Password: Account cannot be accessed at this time. Please contact your system administrator fred.dref at rhel3-host's password: Permission denied, please try again. fred.dref at rhel3-host's password: Received disconnect from 192.168.175.50: 2: Too many authentication failures for fred.dref ---------- Without the changes, this is what would happens: ssh fred.dref at rhel3-host Red Hat Enterprise Linux ES release 3 (Taroon Update 2) Kernel \r on an \m Password: Password: Password: fred.dref at rhel3-host's password: Permission denied, please try again. fred.dref at rhel3-host's password: Received disconnect from 192.168.175.50: 2: Too many authentication failures for fred.dref -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Thursday, February 02, 2006 1:34 AM To: Peter Michalek Cc: openssh-unix-dev at mindrot.org; Paul Moore Subject: Re: Red: PAM auth with disabled user On Wed, Feb 01, 2006 at 05:28:40PM -0800, Peter Michalek wrote:> The patch you suggested works OK, I tried it on the snapshot of1/28/06> using a user authenticated via GSSAPI/Kerberos, with this result,which> I think is acceptable:[...] It's not clear to me from the output, but does the connection close after the PAM account check failed?> Could we make this part of the openssh sourcebase?I think so, once it's clear that it's doing what it is intended, which is to make the behaviour more consistent with the different auth methods. (Damien?) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.