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 ?

  • I'd teach the users to remember their passwords :) – petrus Sep 15 '12 at 22:15
  • @petrus users remember their passwords. Unless they stop using them for 45 days. –  Sep 15 '12 at 23:00
  • Using keepass, secureCRT and TeraTerm on a daily basis, I don't type passwords very often. But my keepass remembers them for me :) – petrus Sep 15 '12 at 23:06
  • So your suggestion is to ask if keepass portable can be deployed on all user desktop? How would you ensure they change their master password every 45 days? –  Sep 15 '12 at 23:17
  • (I'll be asked such a question if i suggest keepass) –  Sep 15 '12 at 23:21
  • Keepass will only help your users to remember their pass when they have to change it. You still have to rely on your system to enforce the password policy. – petrus Sep 16 '12 at 13:29
  • 1
    By that logic, how do you ensure that your users change the passwords of their SSH keys ? – b0fh Sep 16 '12 at 18:14
  • Good point b0fh, that is something I'll have to dig. However, it seems doable : In the worst case I'll have to upgrade openssh and make people use certificates instead of keys(http://blog.habets.pp.se/2011/07/OpenSSH-certificates). –  Sep 17 '12 at 15:41

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,657
  • 2
  • 11
  • 25
  • I must agree that if user had to use the same password as their windows account, they wouldn't forget it. Thanks a lot for this nice workaround. The downside would be that if ldap/AD servers are down, user can't log in unices, but I'll try to dig I that direction. –  Sep 18 '12 at 17:11
  • @eric-dannielou, some workarounds for that: 1) You could set up several slave LDAP servers, that contain a full copy of the LDAP/AD servers content, and point your unices to them (the LDAP libraries all accept a list of LDAP servers, and fallback if the first doesn't respond, etc) thus avoiding the SPOF or 2) Run a tiny OpenLDAP server on each host that uses the proxycache overlay, which can proxy recently used data, including successful binds, making your machines effectively independent of the LDAP/AD servers, so long as the user logged in previously. The memory footprint is tiny. – Jonathan Clarke Sep 19 '12 at 07:08
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,892
  • 4
  • 22
  • 27
  • These settings are inoperant when `UsePAM` is enabled, which is probably what is causing the problem. – b0fh Sep 16 '12 at 18:16
  • When a someone uses ssh keys and their password has expired, they are prompted to change it when they attempt to log in. –  Sep 17 '12 at 16:01
  • 1
    What happens if the password is removed completely? – Luke Sep 17 '12 at 16:33
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
  • 21,910
  • 7
  • 55
  • 79
  • Thanks a lot for remembering the commands that modify /etc/shadow, I forgot to put them in the question. However, as already stated in the question, "setting back password expiration to 99999 days works but it requires extra work". –  Sep 06 '12 at 15:00
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,313
  • 1
  • 20
  • 32
  • Yes traditional passwd/shadow. I did not try disabling UsePAM : I'm afraid people with real expired password would be able to log in? –  Sep 17 '12 at 15:23
  • Answer edited, I tested it and password expiration seems to be handled properly for PasswordAuthentication even when UsePAM is set to no. – b0fh Sep 18 '12 at 14:35