TelekomLabs/chef-ssh-hardening — pull request #18 by bkw (2014-06-11 11:17:16+00:00)
Title: passwordless users not able to log in

I moved TelekomLabs/chef-os-hardening#32 here, since the ssh-hardening seems to be the culprit. Contents have been updated.

After applying the ssh-hardening recipe, I could no longer login into the default user via ssh.
Here is what happened:

The machine was an ubuntu 14.04 LTS vm set up by openstack heat. This creates a default user "ec2-user".
Without further provisioning, this user has no password. This usually poses no problem for me, since ssh is configured to allow RSA key based login only.
The user is locked ("!" in /etc/shadow) since he has no password, but in its default configuration with pam enabled, ssh will allow logins anyway.

After pam was disabled by this recipe, the "locked" flag IS being evaluated, resulting in the following entries in /var/log/auth.log:

sshd[xxx]: User ec2-user not allowed because account is locked
sshd[xxx]: input_userauth_request: invalid user ec2-user [preauth]
sshd[xxx]: Disconnecting: Too many authentication failures for ec2-user [preauth]

I believe this may hit many users. I'm not sure how to deal with this, at least we should document it, since it is not only a surprising side effect of using this recipe, but also one with possibly severe consequences.

Solutions I can think of, off the top of my head:

1. Try to find out what the "default" user is an forcefully unlock it, as long as we enforce rsa-only ssh logins
2. supply a list of accounts to be unlocked as an attribute, possibly with sane defaults. If an account of that name exists, unlock it, emit a warning (or an exception even?) it that account has no password.
3. Reenable pam. What was the point of disabling it in the first place? To disable password based authentication, disabling pam is not needed.

Other thoughts?