6

Okay, we all care about security so users should change their passwords on a regular basis (who said passwords are like underwear?).

On redhat and centos (5.x and 6.x), it's possible to make every real user password expires after 45 days, and warn them 7 days before.

/etc/shadow entry then looks like :

testuser:$6$m8VQ7BWU$b3UBovxC5b9p2UxLxyT0QKKgG1RoOHoap2CV7HviDJ03AUvcFTqB.yiV4Dn7Rj6LgCBsJ1.obQpaLVCx5.Sx90:15588:1:45:7:::

It works very well and most users often change their passwords.

Some users find it convenient not to use any password but ssh public key (and I'd like to encourage them).

Then after 45 days they can't log in as they forgot their password and are asked to change it.

Is there a way to prevent password expiration if and only if password is disabled?

Setting testuser:!!:15588:1:45:7::: in /etc/shadow did not work : testuser is asked to change his password after 45 days.

Of course, setting back password expiration to 99999 days works but :

  • It requires extra work.
  • Security auditors might not be happy.

Is there a system wide parameter that would prompt the user to change expired password only if he really has one ?

4 Answers4

3

If users aren't remembering their passwords, it's certainly because they don't have to use them. I would recommend using a centralized authentication system such as LDAP, so that each user has just one password that gives him access to everything.

This solves several problems in one:

  • You don't have to worry about managing individual passwords on each host
  • Users will actually remember their passwords because they need them
  • You can manage password policy in one central place (the LDAP directory) and get users to change the password there, when needed (think of an email warning them about the expiration a few days before, etc...)
  • You have centralized user management, saving everyone time when a new account needs creating, or an old one needs disabling (who's never heard "disable that user's account ASAP on all systems"?)
Jonathan Clarke
  • 1,667
2

According to this answer on SU, the user should still be able to login with their private key even if their password has expired.

I think the "key" is the user does have a password to expire. A private key is just another way for them to login. I believe that unless you disable password based logins (setting is PasswordAuthentication in sshd_config), the user can still login with their password.

There is another setting in sshd_config called PermitEmptyPasswords, which the default is "no". If you remove the user's password the only way to login should be with their private key. Since at that point there isn't a password, perhaps it won't expire.

This is just based on the ssh though. There are other areas to look at, such as console and su. I'm not sure how they handle empty passwords.

As a last resort you could always put a bash script on a cron to check which users have keys and set their expiration date accordingly. I would also do the reverse: If a user doesn't have a key make sure their expiration date isn't too far away.

Personally I would make everyone user public/private key pairs.

Community
  • 1
Luke
  • 1,962
1

So you can query the info via

chage -l username

And you can override the system wide default with the following

chage -I -1 -m 0 -M 99999 -E -1 username

I don't think there is anything you can set that says.. a user has no password so ignore it.

Mike
  • 22,748
1

Are you using the traditional unix passwd/shadow files ? If so, did you try disabling UsePAM in the sshd config ?

I tested disabling UsePAM on OpenSSH 5.8_p1, and users going trough PasswordAuthentication are properly rejected if their account has expired, and are properly asked to change their password; and nothing is asked when logging in with a key (and when UsePAM is enabled I can confirm that when using a key, the system still requests a password change.)

b0fh
  • 3,353
  • 1
  • 23
  • 32