strong passwords with pam_cracklib

Traditionally I have checked weak passwords with jtr, but one problem is that you have to run it after a user already has a password.  A much more standard way is to check weak passwords with pam.  There are a couple modules for this – one is pam_cracklib.  Another is passwdqc.  I chose cracklib.  You should never use both.

Typically, you’ll edit a conf file in /etc/pam.d/ – normally like commmon-auth or common-password.  The entry you need to add is at the top.  All the entries are of course related to ‘password’.

password    requisite     pam_cracklib.so difok=2 minlen=10 dcredit=2 ocredit=2 try_first_pass retry=3

The fields are pretty straightforward.  Requisite means it’s required. difok specifies how many characters in your new password need to be different from the old password.  minlen is not as straightforward as it may seem.  It specifies the minimum length of the password, for sure, but you can get ‘credit’ for harder passwords.  This is where dcredit and ocredit come into play (amongst others).  dcredit=2 means if your password contains digits you get a bonus character. ocredit is the same thing but with special characters.  retry is the maximum trys you can have to change your password before you have to start again.

The cracklib also checks for particularly weak passwords (it runs them against the unix dictionary with some basic permutations/numbers etc). It’s not close to as strong as jtr, but still pretty darn good, and it’s nice to have your authentication stuff in one place.

The rest of the password rules come next, and should look something like the following.

password    sufficient    pam_unix.so nullok use_authtok md5 shadow
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

This checks the unix passwords, followed by the ldap. use_authtok means strong passwords are already enabled so the modules don’t need to check for themselves (it’d be redundant). The pam_fail indicates failure.

Anyways, though many distros have password checking by default, ubuntu doesn’t. It’s probably a good idea to turn it on if you have a multi-user system

Really global environment variables for ssh

<mopey> how do I export a variable in pvm?  I add it to my .bashrc or .profile but it ignores it.
<mopey> an environment variable
<mopey> Because I get this error:
<mopey> The value of the $PVM_ROOT environment
<mopey> variable on compute-0-1 is invalid (“”).
<mopey> Use the absolute path to the pvm3/ directory.
<mopey> but if I ssh into compute-0-1, echo $PVM_ROOT it is set correctly
<staynalive_> mopey: I don’t know much about PVM
<staynalive_> but I would check to see if it gets set for non-login sessions
<staynalive_> by doing (in one command) “ssh compute-0-1 printenv”
<staynalive_> Yeah, I just tested it and that’s the issue.
<mopey> good call, it’s not being set for some reason, although it’s “being set” in ~/.bashrc
<mopey> where would I set it, if not bashrc?
<staynalive_> Umm
<mopey> my .profile calls bashrc btw, although that shouldn’t really matter since that’s only on interactive logins, right?
<staynalive_> Yeah
<staynalive_> I think I actully changed a ssh flag to carry the environment variables through to the new machine in a ssh session.
<staynalive_> “PermitUserEnvironment yes”
<mopey> oh.  well that’s handy.
<staynalive_> That way if users set something up funky they can carry it to the nodes.
<staynalive_> But the manual warns of some possible security issues…
<mopey> if someone is on my frontend node, it’s only being used on the compute nodes, so it shouldn’t be that big of a deal.
<mopey> since they are basically thin
<mopey> aaah, ssh has env variables all of it’s own…
<mopey> I remember telling you that at one point.  I guess I’m losing my marbles

<mopey> has anyone ever gotten sshrc to succesfully set ssh environment variables?
<mopey> it *should* be straightforward
<mopey> the sshd man page says:  8.  If $HOME/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth.  The “rc” files are
<mopey>  given the X11 authentication protocol and cookie in standard input.
<mopey> is this not run (when I do ‘ssh compute-0-0 env’) because it is too late in the process?
<mopey> because my $HOME/.ssh/environment _is_ run, and I can set them that way.  Except that I want to do it for all users and that seems to be a lame solution.
<mopey> It seems like the command should be executed *after* the rc files are read (it’s step 9)
<mopey> So I wonder why the hell it’s being ignored…
<mopey> staynalive, you said you use “PermitUserEnvironment yes”.  So do you just set a $HOME/.ssh/environment for each user?

<mopey> haha
<mopey> for those who care, pam overrides my ssh variables for the most part
<mopey> so you can define variables in /etc/security/pam_env.conf
<mopey> god, that took forever to figure out why my /etc/environment variables weren’t getting set over ssh
* Vog-work has quit (“ChatZilla 0.9.79 [Firefox 2.0.0.10/2007111504]”)
<twinprism> thanks for sharing, mopey, I care…
<mopey> weird.
<mopey> :)
<_sera> I don’y
<_sera> sheesh… don’t
<mopey> Normally it probably doesn’t matter I’m sure.  Like if you get a bash shell and can actually execute profile/bashrc
<mopey> But if you have a crippled pvm shell or something, it’s way important
<mopey> plus I think pam_env is how PATHs and junk get set on login – at least on ubuntu
<mopey> *gdm/kdm/xdm login