password expiry vs ssh keys and accessibility during failure

[NoahKunin]

From @janearc

Last login: Tue Nov 18 13:40:37 2014 from 63-232-44-84.dia.static.qwest.net
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for jane.
(current) UNIX password: 
passwd: Authentication token manipulation error
passwd: password unchanged
Connection to 54.164.4.21 closed.
haram:jane jane$ 

I can't shell into the machine anymore. This is A Big Deal. When I give myself an account on a new machine, I make my own user look something like this:

jane:*:1001:1001:jane avriette:/home/jane:/bin/bash

And I install an ssh key. Thereafter, I don't worry about it. I started this practice when I worked at NOAA and we had incessant dictionary/fuzz attacks on our ssh daemons from various Asian countries. I decided that I was just not comfortable using any password I myself could remember, given that if I could remember it, there was a scheme behind it, and that scheme was guessable.

If you look at John the Ripper's wordfiles, in fact, you see a lot of these sorts of things. Like a mapping for "yrlnry" to "telnet". Various ciphers for "l33tsp34k" and the like.

Which is to say passwords are, in my mind, pretty worthless. Accordingly, I disable password authentication entirely in the ssh daemons I manage, and insist on users logging in with ssh keys.

This machine is now unusable to me; the original ubuntu user cannot log in for the same reason, jane cannot log in, and there is no password that will work as the "current unix password."

My understanding of this is that I will have to terminate the instance, mount its volume elsewhere on a new machine (I am not even sure how to go about doing this with LVM and so forth), with a password, and get back to work. By definition this "new" setup is less secure, and is going to cost me a lot of time when I could have been doing my job.

Surely there is a way around this? With the STIGs we were able to have an exception to the password complexity policy by mandating use of ssh keys.

[NoahKunin]

If you have access, you can see some commentary at https://github.com/18F/DevOps/issues/148

[dlapiduz]

It looks like we are already blocking password logins: https://github.com/fisma-ready/ubuntu-lts/blob/master/files/ubuntu/etc/ssh/sshd_config#L52

[konklone]

Right, but this affects user accounts which have a password set, even when you login via a public key. It's happened to me on two of my boxes too -- very frustrating.

[dlapiduz]

@konklone can we prevent users from setting passwords? I think that we talked about this before...

[konklone]

I'm not sure. Probably we could make --disable-password the default for adduser? But if Jane was getting hit by this for the ubuntu user, then the problem was also the ubuntu user made by the AMI, and that'll need to be fixed.

[janearc]

Please remember there is adduser and useradd(1) and they do the same thing in different ways. I use the latter generally. useradd -m jane -s /bin/bash.

There's another issue discussing some of this related to chsh being broken. There are other, useful & relevant details there (iirc; it was August, so..).

[konklone]

This just bit me again, in the form of silently broken cronjobs for analytics.usa.gov.

The ubuntu user on the box already has a password expiry of 99999 days, which I'm fine with. The default for the user I'd created, analytics, was 90 days, a threshold we just passed.

I believe this can be fixed by changing the PASS_MAX_DAYS value in /etc/login.defs to 99999. This is the relevant section of the /etc/login.defs on my box:

# Password aging controls:
#
#       PASS_MAX_DAYS   Maximum number of days a password may be used.
#       PASS_MIN_DAYS   Minimum number of days allowed between password changes.
#       PASS_WARN_AGE   Number of days warning given before a password expires.
#
PASS_MAX_DAYS   90
PASS_MIN_DAYS   7
PASS_WARN_AGE   10

I believe if we change this to PASS_MAX_DAYS 99999, the same as what the root and ubuntu users are apparently already set to, we should mitigate us running into this.

Identified through this source, which says that most distros don't even enable this. It doesn't happen for my eric user on my desktop Ubuntu computers, so perhaps it's a default for Ubuntu 14.04 server edition.

[janearc]

I can't see the harm of having other users set up the way the ubuntu user is (that is, beyond the ubuntu user itself being set that way; I think it's a negligible risk).

edit: provided we can ensure they aren't using passwords. Obviously, setting their passwords to not expire Breaks The Rules.

[konklone]

@janearc Is there a setting to disallow passwords (or to make --disabled-password the default) when creating user accounts? I can't find anything in /etc/login.defs that would do this.