maybe this is a silly question ;-) But why is it possible to login on a machine with a locked account (passwd -l ) via pubkey-authentication (authorized_keys) ? I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not happen. If this is the normal behaviour and built in intentionally what would be the easiest way to lock an account without deleting the users authorized_keys ? If not, what output do you need to verify the problem ? Alex
On Tue, 29 Jan 2002, Dost, Alexander wrote:> maybe this is a silly question ;-) But why is it possible to > login on a machine with a locked account (passwd -l ) via > pubkey-authentication (authorized_keys) ? I use OpenSSH3.01p1on > Solaris8 with PAM support so I thought this should not happen. > > If this is the normal behaviour and built in intentionally what > would be the easiest way to lock an account without deleting the > users authorized_keys ? If not, what output do you need to verify > the problem ?"locking" an account is really locking the password, since you are not using password authentication this is ignored. A way that should work is to mark the account as expired, or just rename the ~/.ssh/authorized_keys file -d
Thanks for the answer. Funny solution to my problem now is: do a passwd -l and -f so the account is expired and locked. When logging in, the user is asked to change the password (as password auth is enabled also) and entering the old login pw fails :-) Dirty but working. I agree that changing the authorized_keys file is a better way. Thanks for the help. Alex> -----Original Message----- > From: Damien Miller [SMTP:djm at mindrot.org] > Sent: Tuesday, January 29, 2002 13:16 > To: Dost, Alexander > Cc: openssh-unix-dev at mindrot.org > Subject: Re: locked account accessable via pubkey auth > > On Tue, 29 Jan 2002, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to > > login on a machine with a locked account (passwd -l ) via > > pubkey-authentication (authorized_keys) ? I use OpenSSH3.01p1on > > Solaris8 with PAM support so I thought this should not happen. > > > > If this is the normal behaviour and built in intentionally what > > would be the easiest way to lock an account without deleting the > > users authorized_keys ? If not, what output do you need to verify > > the problem ? > > "locking" an account is really locking the password, since you > are not using password authentication this is ignored. > > A way that should work is to mark the account as expired, or > just rename the ~/.ssh/authorized_keys file > > -dIf you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender.
What we're doing is adding the users to a special group called "disabled" and we have "DenyGroups disabled" directive in our sshd_config file. Since we're rolling out an account provisioning tool, we can customized it to add the user to that group when they're disabled. Alternatively, it could be done manually by policies/procedures, but I don't trust our operations folk to get it right. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dost, Alexander [mailto:Alexander.Dost at drkw.com] Sent: Tuesday, January 29, 2002 6:28 To: 'Damien Miller' Cc: openssh-unix-dev at mindrot.org Subject: RE: locked account accessable via pubkey auth Thanks for the answer. Funny solution to my problem now is: do a passwd -l and -f so the account is expired and locked. When logging in, the user is asked to change the password (as password auth is enabled also) and entering the old login pw fails :-) Dirty but working. I agree that changing the authorized_keys file is a better way. Thanks for the help. Alex> -----Original Message----- > From: Damien Miller [SMTP:djm at mindrot.org] > Sent: Tuesday, January 29, 2002 13:16 > To: Dost, Alexander > Cc: openssh-unix-dev at mindrot.org > Subject: Re: locked account accessable via pubkey auth > > On Tue, 29 Jan 2002, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to > > login on a machine with a locked account (passwd -l ) via > > pubkey-authentication (authorized_keys) ? I use OpenSSH3.01p1on > > Solaris8 with PAM support so I thought this should not happen. > > > > If this is the normal behaviour and built in intentionally what > > would be the easiest way to lock an account without deleting the > > users authorized_keys ? If not, what output do you need to verify > > the problem ? > > "locking" an account is really locking the password, since you > are not using password authentication this is ignored. > > A way that should work is to mark the account as expired, or > just rename the ~/.ssh/authorized_keys file > > -dIf you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020129/35ead2cb/attachment.html
On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote:> maybe this is a silly question ;-) But why is it possible to login on a > machine with a locked account (passwd -l ) via pubkey-authentication > (authorized_keys) ? > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > happen.Check the list archives and you'll find others with the same problem. Noone has turned up a solution with Solaris 8/PAM yet. -- albert chin (china at thewrittenword.com)
On Tue, 29 Jan 2002, Dost, Alexander wrote: :maybe this is a silly question ;-) But why is it possible to login on a :machine with a locked account (passwd -l ) via pubkey-authentication :(authorized_keys) ? :I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not :happen. what does rlogind do under the same conditions with host equivalency configured? :If this is the normal behaviour and built in intentionally what would be the :easiest way to lock an account without deleting the users authorized_keys ? :If not, what output do you need to verify the problem ? in the PAM case, PAM decides, via pam_acct_mgmt(). if i do ``passwd -l user'' on HP-UX i see: Jan 29 07:34:26 jenny sshd[2601]: PAM rejected by account configuration[28]: Account is disabled - see Account Administrator
If it is locked, the users is not allowed to change his own password. So he can not unlock it. You get a permission denied when trying to do so. Alex> -----Original Message----- > From: Dan Kaminsky [SMTP:dan at doxpara.com] > Sent: Wednesday, January 30, 2002 09:48 > To: Damien Miller; Frank Cusack > Cc: openssh-unix-dev at mindrot.org; Dost, Alexander > Subject: Re: locked account accessable via pubkey auth > > > I don't think it is a bug even. Having accounts with locked passwords, > but > > still accessible via pubkey auth is a very useful thing. > > I agree, with one small caveat: Can a user unlock his own password? > > --Dan >
I can only speak for Solaris (8). But the comand 'passwd -l' is restricted for root. I think this behaviour is the same for all Solaris versions, as the only way to unlock your password is to change it. Then the *LK* string is replaced by the new password in /etc/shadow. But when you try to change your password the first thing is to enter your login password, which is locked... Alex> -----Original Message----- > From: Dan Kaminsky [SMTP:dan at doxpara.com] > Sent: Wednesday, January 30, 2002 10:14 > To: Dost, Alexander; Damien Miller; Frank Cusack > Cc: openssh-unix-dev at mindrot.org > Subject: Re: locked account accessable via pubkey auth > > > If it is locked, the users is not allowed to change his own password. So > he > > can not unlock it. You get a permission denied when trying to do so. > > Actually, that's really useful and very cool! Which platforms support > this > behavior -- just recent Solaris, or most Unixen? > > Can a user lock their own account? > > --Dan > >If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender.
On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote:> maybe this is a silly question ;-) But why is it possible to login on a > machine with a locked account (passwd -l ) via pubkey-authentication > (authorized_keys) ?expired passwords are very different from expired accounts: if a password is expired the password can longer be used. if an account is expired the account can longer be used. or am I missing something?
No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote:> On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login ona> > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought thisshould not> > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so.I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/0d7eed4a/attachment.html
As an interesting side note, HP-UX used to also have this problem, but I just tested on an 11.0 trusted HP-UX box and disabling my account in SAM did actually disable it to ssh. Unfortunately, we don't have any untrusted systems, so I can't tell if it's a ramification of the HPs whole tcb shananigans (their version of shadow files) or if all of HP is similarly fixed. Also, I'm pretty sure that this behavior in Solaris way predated version 8. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:17 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Since normally it's impossible to access the account of a password-disabled account, should default behavior on Solaris be to assume password-disabled means access-disabled? It seems to me that the rest of the Solaris tools assume "no password = no access". Perhaps we should as well, and provide a separate configuration option to override to the useful but non-obvious pubkey-only mode. Thoughts? --Dan ----- Original Message ----- From: Lacoss-Arnold, Jason <mailto:Jason.Lacoss-Arnold at AGEDWARDS.com> To: 'Damien Miller' <mailto:djm at mindrot.org> ; Frank Cusack <mailto:fcusack at fcusack.com> Cc: openssh-unix-dev at mindrot.org <mailto:openssh-unix-dev at mindrot.org> ; Dost, <mailto:Alexander.Dost at drkw.com> Alexander Sent: Wednesday, January 30, 2002 4:59 AM Subject: RE: locked account accessable via pubkey auth No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [ mailto:djm at mindrot.org <mailto:djm at mindrot.org> ] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote:> On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login ona> > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought thisshould not> > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so.I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev <http://www.mindrot.org/mailman/listinfo/openssh-unix-dev> **************************************************************************** *********** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. **************************************************************************** *********** *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/54eb8e22/attachment.html
No. ftp doesn't allow it. The console doesn't allow it. The r* commands would allow it, but we don't allow them for obvious reasons. But we feel that the tool we're using to rid ourselves of security holes shouldn't replicate security holes. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:43 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Without SSH, is there *any* other way to access a password-locked account than to su in from root? If not, I don't see it as being valid to allow a pubkey "backdoor" by default. It comes down to whether the platforms are equating "no password no access". Unless something else has access with no password, we shouldn't be allowing such. Now, do we generally directly manage passwd/shadow files on Solaris, or do we usually go through PAM? Can PAM report an LK password state, so we could check for it before allowing pubkey? --dan ----- Original Message ----- From: Lacoss-Arnold, Jason <mailto:Jason.Lacoss-Arnold at AGEDWARDS.com> To: 'Dan Kaminsky' <mailto:dan at doxpara.com> ; 'Damien Miller' <mailto:djm at mindrot.org> ; Frank Cusack <mailto:fcusack at fcusack.com> Cc: openssh-unix-dev at mindrot.org <mailto:openssh-unix-dev at mindrot.org> ; Dost, <mailto:Alexander.Dost at drkw.com> Alexander Sent: Wednesday, January 30, 2002 5:26 AM Subject: RE: locked account accessable via pubkey auth As an interesting side note, HP-UX used to also have this problem, but I just tested on an 11.0 trusted HP-UX box and disabling my account in SAM did actually disable it to ssh. Unfortunately, we don't have any untrusted systems, so I can't tell if it's a ramification of the HPs whole tcb shananigans (their version of shadow files) or if all of HP is similarly fixed. Also, I'm pretty sure that this behavior in Solaris way predated version 8. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:17 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Since normally it's impossible to access the account of a password-disabled account, should default behavior on Solaris be to assume password-disabled means access-disabled? It seems to me that the rest of the Solaris tools assume "no password = no access". Perhaps we should as well, and provide a separate configuration option to override to the useful but non-obvious pubkey-only mode. Thoughts? --Dan ----- Original Message ----- From: Lacoss-Arnold, Jason <mailto:Jason.Lacoss-Arnold at AGEDWARDS.com> To: 'Damien Miller' <mailto:djm at mindrot.org> ; Frank <mailto:fcusack at fcusack.com> Cusack Cc: openssh-unix-dev at mindrot.org <mailto:openssh-unix-dev at mindrot.org> ; Dost, Alexander <mailto:Alexander.Dost at drkw.com> Sent: Wednesday, January 30, 2002 4:59 AM Subject: RE: locked account accessable via pubkey auth No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [ mailto:djm at mindrot.org <mailto:djm at mindrot.org> ] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote:> On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login ona> > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought thisshould not> > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so.I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev <http://www.mindrot.org/mailman/listinfo/openssh-unix-dev> **************************************************************************** *********** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. **************************************************************************** *********** **************************************************************************** *********** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. **************************************************************************** *********** *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/2d670479/attachment.html
>On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: >> maybe this is a silly question ;-) But why is it possible to login on a >> machine with a locked account (passwd -l ) via pubkey-authentication >> (authorized_keys) ? > >expired passwords are very different from expired accounts:which are different to locked accounts.>if a password is expired the password can longer be used.correct. The password can be changed either by the user at login, r*/telnet/ssh/dtlogin in Solaris support this. ftp doesn't and can't due to protocol restrictions.>if an account is expired the account can longer be used.correct. This in Solaris is an absoulte date in time. The passwd command is used to set this but we have no easy way to reactivate the account other than chaning the date to something in the future. OpenSSH honours this when PAM is used.>or am I missing something?A locked account in Solaris is one who's password begins *LK*, this is what happens when running passwd -l <user>. *NP* means that the password wasn't accessible to that user - either passwd.adjunct is in use for NIS or the NIS+ password table permissions are set so that only the user can see their password (if it was the user doing the lookup then it means that they haven't had their AUTH_DH keys registered with the local keyserv (ie not done a keylogin or had pam_unix run)). This works because *LK* can't possibly match the hashed password the user types in when crypt(3c) is used. But if like OpenSSH you don't always use pam_authenticate then this doesn't stop the user getting in if you only call pam_acct_mgmt. This is fixed in Solaris 9 the pam_unix_account module in Solaris 9 explicitly checks for the *LK* string so SSH logins with publickey to an account with *LK* as the first 4 chars of the password field will be denied - which is the correct behaviour. If you wish to disable password based login but do want to have publickey based login then use NP which is no password (this is what is used for the "system" accounts that should never have a login password set on them). An account can also be refused login because it has been idle too long, this is based on the last login date in lastlog - this is pretty much useless because it is on a per host basis rather than network wide. -- Darren J Moffat
>On Solaris 8, passwd(8) says -l "Locks password entry for _name_". It does >not say that it locks the *account*. So this would seem to be consistent >with pubkey auth still being allowed. Even so, I would tend to think it >should lock the "account". I don't know if this list is a good place for >it, but personally I would be interested in hearing arguments for either.It is a bug and it has been fixed in Solaris 9, see my other email for the details. -- Darren J Moffat
On Wed, Jan 30, 2002 at 09:55:09AM -0800, Darren Moffat wrote:> This is fixed in Solaris 9 the pam_unix_account module in Solaris 9 explicitly > checks for the *LK* string so SSH logins with publickey to an account with > *LK* as the first 4 chars of the password field will be denied - which is the > correct behaviour.Please make sure the man page is updated. :-) For Solaris 8 it says the password is locked (not the account). /fc
>On Wed, Jan 30, 2002 at 11:23:31AM -0500, Nicolas Williams wrote: >> Leave things as they are please - do not add a check to see if the >> password field in the shadow entry is *LK*, that would not be generally >> useful (think: what if you're using only Kerberos for password >> validation?).The you should NOT be marking the account as being locked you should give it an invalid password entry - eg NP.>I have to agree with Nico here, don't try to second guess the system >designers. On Solaris (up to 8, anyway), it seems that 'passwd -l' is >NOT intended to lock the account. Those that want other behaviour should >take it up with the vendor (or switch vendors).It has always been a bug. However until PAM became a public API in Solaris 2.6 it wasn't possible to augment the authentication so most apps just did strcmp(crypt(getpass()), sp->sp_pwd) and with *LK* you couldn't get a success. When PAM was introduced the difference between the account being locked and password being something invalid be came more obvious, pam_sm_uthenticate() in pam_unix(5) checks the password that the user offers matches what is stored encrypted in the relevant nameservice. pam_acct_mgmt() checks the account validity (password aging, expiry etc). Most of the time applications call pam_authenticate() first and with the pam_unix(5) module you never get any further. sshd, cron are the obvious exceptions to that. cron was where we found this issue. It is logged as bug# 4506972 in SunSolve. As justification from existing documentation I offer: pam_sm_acct_mgmt(3pam) says: The pam_sm_acct_mgmt() function determines whether or not the current user's account and password are valid. This includes checking for password and account expiration, and valid login times. The user in question is specified by a prior call to pam_start(), and is referenced by the authen- tication handle, pamh, which is passed as the first argument to pam_sm_acct_mgmt(). The following flags may be set in the flags field: The pam_acct_mgmt() function is called to determine if the current user's account is valid. It checks for password and account expiration, and verifies access hour restrictions. This function is typically called after the user has been authenticated with pam_authenticate(3PAM). pam_unix(5) says: Unix Account Management Module The UNIX account management component provides a function to perform account management, pam_sm_acct_mgmt(). The function retrieves the user's password entry from the UNIX password database and verifies that the user's account and password have not expired. The following options may be passed in to the UNIX service module: shadow(4) defines a valid password: password A 13-character encrypted password for the user, a lock string to indicate that the login is not accessible, or no string, which shows that there is no password for the login. All Solaris code used *LK* to mean locked. NIS+ uses *NP* to mean I'm not giving it to you. Note that it doesn't actually say what the lock string is until Solaris 9. New in Solaris 9 is pam_unix_account(5) which says: pam_unix_account provides functionality to the PAM account management stack. The function pam(3PAM) function retrieves password aging information from the repositories specified in nsswitch.conf(4), and verifies that the user's account and password have not expired. passwd(1)'s description of the -l flag does still say: -l Locks password entry for name. Note that it doesn't say it locks the password it says locks the "password entry", implying it disables access to the account. I agree this could be clearer - I'll see what I can do about getting it changed. -- Darren J Moffat
HP-UX 11.00
from: man passwd
-l Lock user account.
from: man getspent
getspent(3C) getspent(3C)
NAME
getspent, getspnam, setspent, endspent - access secure password
entries, for trusted systems only.
SYNOPSIS
#include <shadow.h>
struct spwd * getspent (void);
struct spwd * getspnam (const char *name);
void setspent (void);
void endspent (void);
DESCRIPTION
The routines getspent() and getspnam() return a pointer to the next
secured password entry. Each entry is a spwd structure, declared in
the shadow.h header file with the following members:
char *sp_namp; /* the user's login name */
char *sp_pwdp; /* the encrypted password for the user */
long sp_lstchg; /* # of days from 1/1/70 when passwd was last
modified */
long sp_min; /* min # of days allowed between password
changes */
long sp_max; /* max # of days allowed between password
changes */
long sp_warn; /* # of days before password expires and warning
issued*/
long sp_inact; /* # of days between account inactive and
disabled */
long sp_expire; /* # of days from 1/1/70 when account is locked
*/
unsigned long sp_flag;/* currently unused */
The getspent() routine returns a pointer to the first spwd structure
when first called. Subsequent calls return pointers to successive spwd
structures. Repeated calls to getspent() can be used to search all
entries in the protected password database. The getspnam () routine
searches password entries from beginning to end until a login name
matching name is found, and returns a pointer to that entry.
If the fields corresponding to sp_min, sp_max, sp_lstchg, sp_warn,
sp_inact, sp_expire, or sp_flag are not specified in the entry, they
default to -1. If an end-of-file or an error is encountered in reading
or a format error is detected, these functions return a null pointer
and; for an error, errno is set to EINVAL.
The setspent() routine is used to reset access to the secured password
entries. After setspent() is called, the subsequent call to getspent()
returns the first secured password entry. This mechanism is used to
allow repeated searches of the secured password entries. The
endspent() routine is used to indicate that processing of secured
password entries is complete.
Hewlett-Packard Company - 1 - HP-UX Release 11.00: October 1997
getspent(3C) getspent(3C)
getspent() is only supported on trusted systems.
The secured password facility is implemented without the use of the
/etc/shadow file. getspent(), getspnam(), setspent(), and endspent()
read from the trusted system's protected password database
(/tcb/files/auth/*/*) and not /etc/shadow. The file /etc/shadow is
not used in any way by the HP-UX login facility.
These routines return a null pointer and sets ERRNO to ENOENT if the
system has not been converted to trusted system. In all other cases,
the return value is set similarly to getprpwent(). See getprpwent(3)
for more information.
Programs using these routines must be compiled with -lsec.
FILES
/etc/passwd System Password file.
/tcb/files/auth/*/* Protected password database, for trusted
systems.
SEE ALSO
getpwent(3C), getprpwent(3), passwd(4).
DIAGNOSTICS
getspent(), getspnam(), and fgetspent() return a null pointer on EOF
or error.
STANDARDS CONFORMANCE
getspent : SVID3
Thanks,
--Jason Lacoss-Arnold, Systems Technical Specialist
Technical Services - Unix Arch.
314-955-8501
-----Original Message-----
From: Frank Cusack [mailto:fcusack at fcusack.com]
Sent: Wednesday, January 30, 2002 18:01
To: Damien Miller
Cc: openssh-unix-dev at mindrot.org; Dost, Alexander
Subject: Re: locked account accessable via pubkey auth
On Wed, Jan 30, 2002 at 03:39:38PM +1100, Damien Miller
wrote:> On Tue, 29 Jan 2002, Frank Cusack wrote:
>
> > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote:
> > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote:
> > > > maybe this is a silly question ;-) But why is it possible to
login
on a> > > > machine with a locked account (passwd -l ) via
pubkey-authentication
> > > > (authorized_keys) ?
> >
> > huh.. This is definitely a bug; probably in the Solaris PAM libs. I
can> > look into this, unfortunately not within a day or so.
>
> I don't think it is a bug even. Having accounts with locked passwords,
but
> still accessible via pubkey auth is a very useful thing.
I agree, that is useful, but whether or not it's a bug depends on the
meaning
of 'passwd -l'. SUSv2 does not define the passwd command, so I guess
this
is implementation-dependent.
On Solaris 8, passwd(8) says -l "Locks password entry for _name_". It
does
not say that it locks the *account*. So this would seem to be consistent
with pubkey auth still being allowed. Even so, I would tend to think it
should lock the "account". I don't know if this list is a good
place for
it, but personally I would be interested in hearing arguments for either.
Can someone report on what the HP-UX man page says? I'd also be interested
to see the man page for HP-UX getspent(). (Another email in this thread
says HP-UX prevents pubkey auth after 'passwd -l'.)
/fc
_______________________________________________
openssh-unix-dev at mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
***************************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
***************************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020131/cf61d62b/attachment.html
>On Wed, Jan 30, 2002 at 05:02:37PM -0800, Darren Moffat wrote: >> New in Solaris 9 is pam_unix_account(5) which says: >> >> pam_unix_account provides functionality to the PAM account >> management stack. The function pam(3PAM) function retrieves >> password aging information from the repositories specified >> in nsswitch.conf(4), and verifies that the user's account >> and password have not expired. > >hmm... This seems broken. If I want a certain service to check pam_unix, >I list it in pam.conf. Instead, I'm now supposed to call pam_unix_account() >specifically? Is pam_unix_account() somehow different than the normal >pam account mgmt w/ pam_unix in pam.conf? The intent of this (AFAICT) is >so that an app can always check against pam_unix, regardless of what's in >pam.conf -- broken. Sorry, this is getting OT.You completely missunderstood what pam_unix_account(5) is. The 5 is the hint - it is a module not a function. We have made no changes to the API for applications or modules. We took the big gob of pam_unix that we had from 2.6 though 8 and split it into smaller chunks to be more consistant with what is in the Open Group spec and to make it easier for people to just replace the password validation routines. The new default pam.conf is attached.>> passwd(1)'s description of the -l flag does still say: >> -l Locks password entry for name. >> >> >> Note that it doesn't say it locks the password it says locks the "password >> entry", implying it disables access to the account. I agree this could >> be clearer - I'll see what I can do about getting it changed. > >Do you know if a patch will be available for Solaris 8?I'll look into it. -- Darren J Moffat -------------- next part -------------- # #ident "@(#)pam.conf 1.20 02/01/23 SMI" # # Copyright 1996-2002 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # PAM configuration # # Unless explicitly defined, all services use the modules # defined in the "other" section. # # Modules are defined with relative pathnames, i.e., they are # relative to /usr/lib/security/$ISA. Absolute path names, as # present in this file in previous releases are still acceptable. # # Authentication management # # login service (explicit because of pam_dial_auth) # login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 # # rlogin service (explicit because of pam_rhost_auth) # rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_auth.so.1 # # rsh service (explicit because of pam_rhost_auth, # and pam_unix_auth for meaningful pam_setcred) # rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_auth.so.1 # # PPP service (explicit because of pam_dial_auth) # ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1 # # Default definitions for Authentication management # Used when service name is not explicitly mentioned for authenctication # other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_auth.so.1 # # passwd command (explicit because of a different authentication module) # passwd auth required pam_passwd_auth.so.1 # # cron service (explicit because of non-usage of pam_roles.so.1) # cron account required pam_projects.so.1 cron account required pam_unix_account.so.1 # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account required pam_unix_account.so.1 # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session required pam_unix_session.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 # # Support for Kerberos V5 authentication (uncomment to use Kerberos) # #rlogin auth optional pam_krb5.so.1 try_first_pass #login auth optional pam_krb5.so.1 try_first_pass #other auth optional pam_krb5.so.1 try_first_pass #cron account optional pam_krb5.so.1 #other account optional pam_krb5.so.1 #other session optional pam_krb5.so.1 #other password optional pam_krb5.so.1 try_first_pass
On Thu, Jan 31, 2002 at 09:11:35AM -0800, Darren Moffat wrote:> You completely missunderstood what pam_unix_account(5) is. The 5 is the > hint - it is a module not a function. We have made no changes to > the API for applications or modules. > > We took the big gob of pam_unix that we had from 2.6 though 8 and > split it into smaller chunks to be more consistant with what is in the > Open Group spec and to make it easier for people to just replace the > password validation routines. > > The new default pam.conf is attached. > > -- > Darren J MoffatContent-Description: pam.conf> login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_auth.so.1 > login auth required pam_dial_auth.so.1Cool. Very cool. I have wanted this sort of thing... Now, it would be cooler still if you could specify which Unix account backend to use (files, nis, nisplus, ldap). And with respect to pam_krb5, is your current approach still to make it a sort of convenience kinit-in-PAM? Or can Solaris 9 really use Kerberos V for user password authentication? Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Offtopic for this list but I believe there are people who hang out here that would be interested in the answer.>And with respect to pam_krb5, is your current approach still to make it >a sort of convenience kinit-in-PAM? Or can Solaris 9 really use Kerberos >V for user password authentication?It is really authentication. Fixed under bug# 4516495 for Solaris 9. -- Darren J Moffat
On Thu, 31 Jan 2002, Darren Moffat wrote:> We took the big gob of pam_unix that we had from 2.6 though 8 and > split it into smaller chunks to be more consistant with what is in the > Open Group spec and to make it easier for people to just replace the > password validation routines. > > The new default pam.conf is attached.What version of Solaris will this pam.conf and the associated libraries be available in? Thanks, Ed Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key
>On Thu, 31 Jan 2002, Darren Moffat wrote: > >> We took the big gob of pam_unix that we had from 2.6 though 8 and >> split it into smaller chunks to be more consistant with what is in the >> Open Group spec and to make it easier for people to just replace the >> password validation routines. >> >> The new default pam.conf is attached. > >What version of Solaris will this pam.conf and the associated libraries be >available in?Solaris 9. -- Darren J Moffat