New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

passwordless users not able to log in #18

Merged
merged 2 commits into from Jun 16, 2014

Conversation

Projects
None yet
3 participants
@bkw
Contributor

bkw commented Jun 11, 2014

I moved dev-sec/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?

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Jun 11, 2014

Member

Dear @bkw thanks for reporting this issue. It sounds really annoying. From my background I assume this issue may occur with all default Ubuntu cloud images and their default users in combination with cloud-init. At first of all we need to find the original problem.

I am not sure I we find a proper automatic detection. I would find it difficult if we unlock locked accounts by any automatic pattern? With this approach we may run from one issue into another. A quick hack for you would be to run https://github.com/fnichol/chef-user and unlock the account during the chef run.

Let's discuss the proposed options:

  1. I think the tricky part will be the determination of the default user
  2. Sounds like an approach, but I would rather not like to include a complete user management here. Otherwise we force users to stick to a specific module. To throw an exception could be an option.
  3. Normally we activate only pam. And PAM takes the locked flag into account, therefore the issue occurs. This will be done by os-hardening https://github.com/TelekomLabs/chef-os-hardening/blob/master/recipes/pam.rb

Difficult, since the original issues is located in the locked account.

Member

chris-rock commented Jun 11, 2014

Dear @bkw thanks for reporting this issue. It sounds really annoying. From my background I assume this issue may occur with all default Ubuntu cloud images and their default users in combination with cloud-init. At first of all we need to find the original problem.

I am not sure I we find a proper automatic detection. I would find it difficult if we unlock locked accounts by any automatic pattern? With this approach we may run from one issue into another. A quick hack for you would be to run https://github.com/fnichol/chef-user and unlock the account during the chef run.

Let's discuss the proposed options:

  1. I think the tricky part will be the determination of the default user
  2. Sounds like an approach, but I would rather not like to include a complete user management here. Otherwise we force users to stick to a specific module. To throw an exception could be an option.
  3. Normally we activate only pam. And PAM takes the locked flag into account, therefore the issue occurs. This will be done by os-hardening https://github.com/TelekomLabs/chef-os-hardening/blob/master/recipes/pam.rb

Difficult, since the original issues is located in the locked account.

@bkw

This comment has been minimized.

Show comment
Hide comment
@bkw

bkw Jun 11, 2014

Contributor
  1. Normally we activate only pam. And PAM takes the locked flag into account, therefore the issue occurs. This will be done by os-hardening https://github.com/TelekomLabs/chef-os-hardening/blob/master/recipes/pam.rb

Then why do we specifically disable the use of PAM in sshd.conf, leading to this issue in the first place? See:
https://github.com/TelekomLabs/chef-ssh-hardening/blob/master/templates/default/opensshd.conf.erb#L106

Contributor

bkw commented Jun 11, 2014

  1. Normally we activate only pam. And PAM takes the locked flag into account, therefore the issue occurs. This will be done by os-hardening https://github.com/TelekomLabs/chef-os-hardening/blob/master/recipes/pam.rb

Then why do we specifically disable the use of PAM in sshd.conf, leading to this issue in the first place? See:
https://github.com/TelekomLabs/chef-ssh-hardening/blob/master/templates/default/opensshd.conf.erb#L106

@bkw

This comment has been minimized.

Show comment
Hide comment
@bkw

bkw Jun 11, 2014

Contributor

Replace that line with "UsePAM yes" and bob's your uncle. Hence my question: Why do we disable it in the first place? What security problem are we trying to close by that that has not been addressed by "PasswordAuthentication no" and "PermitEmptyPasswords no"?

Contributor

bkw commented Jun 11, 2014

Replace that line with "UsePAM yes" and bob's your uncle. Hence my question: Why do we disable it in the first place? What security problem are we trying to close by that that has not been addressed by "PasswordAuthentication no" and "PermitEmptyPasswords no"?

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Jun 11, 2014

Member

I see.... ;-)

Member

chris-rock commented Jun 11, 2014

I see.... ;-)

@bkw

This comment has been minimized.

Show comment
Hide comment
@bkw

bkw Jun 11, 2014

Contributor

I changed this into a PR with a changeset to enable PAM. Maybe we can get more people to weigh in on this.

Contributor

bkw commented Jun 11, 2014

I changed this into a PR with a changeset to enable PAM. Maybe we can get more people to weigh in on this.

@atomic111

This comment has been minimized.

Show comment
Hide comment
@atomic111

atomic111 Jun 16, 2014

Member

great, thank you

Member

atomic111 commented Jun 16, 2014

great, thank you

atomic111 added a commit that referenced this pull request Jun 16, 2014

Merge pull request #18 from bkw/reenablePam
passwordless users not able to log in

@atomic111 atomic111 merged commit 5ec76f4 into dev-sec:master Jun 16, 2014

@bkw

This comment has been minimized.

Show comment
Hide comment
@bkw

bkw Jun 16, 2014

Contributor

Is this enough? I only set the default to 'false' to preserve the existing functionality. Still I'd like to learn why we disable Pam by default and lock out the Ubuntu user, unless this new attribute is overridden. At the very least we should document this. I'd volunteer to do this but I need to understand why we think disabling pam for ssh is a good thing at should be the default.

Contributor

bkw commented Jun 16, 2014

Is this enough? I only set the default to 'false' to preserve the existing functionality. Still I'd like to learn why we disable Pam by default and lock out the Ubuntu user, unless this new attribute is overridden. At the very least we should document this. I'd volunteer to do this but I need to understand why we think disabling pam for ssh is a good thing at should be the default.

@bkw bkw deleted the bkw:reenablePam branch Oct 14, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment