> As far as the people I know, passwd -d and passwd -l are the most > common ways to do this. They do NOT change the shell. Changing the > shell to lock out an account is laughable expiredate would be more appropriate but again it didn't seem to be instant. locking the password is good but it 'reportedly' won't stop key/token authentication nor should it. >Who said that setting the user's shell to /bin/false means disabling a user? googling disabling a unix account often lists this and I know I've read a few books listing this. I'm not saying it's the most correct answer, but given that this shell only refers to a login shell if this isn't valid why should they be able to login? we set system accounts like postgresql to this for this reason, they aren't supposed to be logging in. again even though this is likely largely misinformation, it's far to common to ignore. also if you look at an account and there shell is /(s)bin/nologin wouldn't you assume that they aren't supposed to be able to login? >So basically you just need to add "auth required >pam_shells.so" to all pam files related to login, correct ? mostly yes. >Or what were the other problematic settings of pam.d/kde ? but I believe all of the login files should be mostly similar. the suggestion of using common files is actually good and tweaking for the last few modules. for example anything that provides login should also be logging to faillog. basically unless it's medium specific they should basically be doing the same things. I also noticed arch hasn't changed to used pam_tally2 which I believe is a replacement for pam_tally. I don't have much details on this though. I should also say that the practices of kde-np concern me and I'm going to review them. I assume that's the file for 'no password'? it seems to be too permissive. it should check other stuff and just not password. but I haven't had time to check it over yet. -- Caleb Cushing http://xenoterracide.blogspot.com
