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

UsePAM should probably default to yes on Red Hat Linux 7 #96

Closed
elyscape opened this Issue Jul 26, 2015 · 16 comments

Comments

Projects
None yet
6 participants
@elyscape

elyscape commented Jul 26, 2015

From the sshd_config file on a CentOS 7 box:

# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
# problems.

As such, it's probably a good idea to default default['ssh']['use_pam'] to true on RedHat 7.

This warning isn't in the CentOS 6 sshd_config file, but there is an article in the Red Hat 6 knowledgebase about not being able to SSH into a system if UsePAM is off and SELinux is on. I don't have an account and can't see the solution, though, so there might be a way to deal with that.

See also dev-sec/puppet-ssh-hardening#53 and dev-sec/ansible-ssh-hardening#23.

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Jul 26, 2015

Contributor

I've seen this (the inability to ssh in with use_pam = false) with Debian-based distributions, too.

Contributor

michaelklishin commented Jul 26, 2015

I've seen this (the inability to ssh in with use_pam = false) with Debian-based distributions, too.

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Jul 26, 2015

Member

Thanks @elyscape and @michaelklishin We've scheduled RHEL7 support for the next weeks.

@michaelklishin Especially with Ubuntu cloud machines, you normally run into locked accounts: https://github.com/hardening-io/chef-ssh-hardening#faq--pitfalls In such cases, use_pam works around this.

Member

chris-rock commented Jul 26, 2015

Thanks @elyscape and @michaelklishin We've scheduled RHEL7 support for the next weeks.

@michaelklishin Especially with Ubuntu cloud machines, you normally run into locked accounts: https://github.com/hardening-io/chef-ssh-hardening#faq--pitfalls In such cases, use_pam works around this.

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock
Member

chris-rock commented Jul 26, 2015

@michaelklishin

This comment has been minimized.

Show comment
Hide comment
@michaelklishin

michaelklishin Aug 7, 2015

Contributor

@chris-rock I'm pretty sure my account was not locked. So was a decision made on making this default to true at laest on RHEL7 and Ubuntu/Debian?

Contributor

michaelklishin commented Aug 7, 2015

@chris-rock I'm pretty sure my account was not locked. So was a decision made on making this default to true at laest on RHEL7 and Ubuntu/Debian?

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Aug 7, 2015

Member

let me double-check, do you have any documentation that indicates usepam is required on rhel7

Member

chris-rock commented Aug 7, 2015

let me double-check, do you have any documentation that indicates usepam is required on rhel7

@elyscape

This comment has been minimized.

Show comment
Hide comment
@elyscape

elyscape Aug 7, 2015

@chris-rock: As mentioned in the issue, the sshd_config file on EL7-based systems contains the following comment above the UsePAM option:

# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
# problems.

elyscape commented Aug 7, 2015

@chris-rock: As mentioned in the issue, the sshd_config file on EL7-based systems contains the following comment above the UsePAM option:

# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
# problems.
@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Aug 8, 2015

Member

thanks @elyscape Then we should make it default on RHEL7

Member

chris-rock commented Aug 8, 2015

thanks @elyscape Then we should make it default on RHEL7

@artem-sidorenko

This comment has been minimized.

Show comment
Hide comment
@artem-sidorenko

artem-sidorenko Aug 8, 2015

Member

I guess its not only RHEL7 related, I remember some discussion with RH about 3-4 years ago about this flag (and about SUID bits).
I do not know all details any more, but we decided to go with UsePAM no (and with SUID bit removal) as there were no particular technical reasons (at least for our deployments), but only a question about supported configuration by RH.
(As far as I remember the trade off for support cases for ssh or related things was something like we would have to reproduce the issue on the supported config first, and only in this case raise the support case)

Member

artem-sidorenko commented Aug 8, 2015

I guess its not only RHEL7 related, I remember some discussion with RH about 3-4 years ago about this flag (and about SUID bits).
I do not know all details any more, but we decided to go with UsePAM no (and with SUID bit removal) as there were no particular technical reasons (at least for our deployments), but only a question about supported configuration by RH.
(As far as I remember the trade off for support cases for ssh or related things was something like we would have to reproduce the issue on the supported config first, and only in this case raise the support case)

@artem-sidorenko

This comment has been minimized.

Show comment
Hide comment
@artem-sidorenko

artem-sidorenko Aug 8, 2015

Member

Probably its a good idea to change the default options to a supported config to avoid any issues in general. In deployments like we have, the users will have to take care about this option and change the defaults. But in my eyes it makes sense to keep the support for UsePAM no and to keep/extend the test cases for both scenarios if possible

Member

artem-sidorenko commented Aug 8, 2015

Probably its a good idea to change the default options to a supported config to avoid any issues in general. In deployments like we have, the users will have to take care about this option and change the defaults. But in my eyes it makes sense to keep the support for UsePAM no and to keep/extend the test cases for both scenarios if possible

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Aug 8, 2015

Member

We could switch to UsePam yes on all RHEL systems to meet the default supported way.

Member

chris-rock commented Aug 8, 2015

We could switch to UsePam yes on all RHEL systems to meet the default supported way.

@rndmh3ro

This comment has been minimized.

Show comment
Hide comment
@rndmh3ro

rndmh3ro Aug 8, 2015

Member

As per this post.

The workaround mentioned by RedHat is:
The workaround would be to create an additional policy that allow sshd to read password file directly

We could create that policy and add it to selinux, when use_pam is off and selinux is on.
Does this happen on all OS's?

Member

rndmh3ro commented Aug 8, 2015

As per this post.

The workaround mentioned by RedHat is:
The workaround would be to create an additional policy that allow sshd to read password file directly

We could create that policy and add it to selinux, when use_pam is off and selinux is on.
Does this happen on all OS's?

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Aug 8, 2015

Member

Maybe it is a good a approach to implement the idea @rndmh3ro mentioned to keep usePam=no as default for this cookbook version.
@artem-sidorenko @arlimus @atomic111 what do you think about changing the default for usePam to yes on our next major release? I'd like to keep a consistent approach for all OSes.

Member

chris-rock commented Aug 8, 2015

Maybe it is a good a approach to implement the idea @rndmh3ro mentioned to keep usePam=no as default for this cookbook version.
@artem-sidorenko @arlimus @atomic111 what do you think about changing the default for usePam to yes on our next major release? I'd like to keep a consistent approach for all OSes.

@artem-sidorenko

This comment has been minimized.

Show comment
Hide comment
@artem-sidorenko

artem-sidorenko Aug 8, 2015

Member

@chris-rock I think its a good approach

  • to keep usepam=no and the described selinux idea in this cookbook version
  • to go to usepam=yes in the next major version to have consistency, here I would suggest to take the selinux idea and to provide support for usepam=no (to allow transitions and upgrades and not to break it completely)

FYI:
On Monday I'll take a look to our Hardening&RHEL7 eval notes if I find something like this.

CC @larsjuetten as far as I remember you did the quick evaluation of chef-(os/ssh)-hardening on RHEL/Centos 7, can you remember if you got this issue or have any details which might be useful here?

Member

artem-sidorenko commented Aug 8, 2015

@chris-rock I think its a good approach

  • to keep usepam=no and the described selinux idea in this cookbook version
  • to go to usepam=yes in the next major version to have consistency, here I would suggest to take the selinux idea and to provide support for usepam=no (to allow transitions and upgrades and not to break it completely)

FYI:
On Monday I'll take a look to our Hardening&RHEL7 eval notes if I find something like this.

CC @larsjuetten as far as I remember you did the quick evaluation of chef-(os/ssh)-hardening on RHEL/Centos 7, can you remember if you got this issue or have any details which might be useful here?

@artem-sidorenko

This comment has been minimized.

Show comment
Hide comment
@artem-sidorenko

artem-sidorenko Aug 10, 2015

Member
...
        :ssh => { :use_pam => true }
....
ssh-use_pam->true ensures, that the users are still able to login.

So, we had exactly this issue as well:)

Member

artem-sidorenko commented Aug 10, 2015

...
        :ssh => { :use_pam => true }
....
ssh-use_pam->true ensures, that the users are still able to login.

So, we had exactly this issue as well:)

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Aug 12, 2015

Member

Thanks for the great discussion. Lets make usePam=yes the default version for all implementations. We should bump a major though and add a proper no implementation for RedHat as suggested by @rndmh3ro

Member

chris-rock commented Aug 12, 2015

Thanks for the great discussion. Lets make usePam=yes the default version for all implementations. We should bump a major though and add a proper no implementation for RedHat as suggested by @rndmh3ro

@boldandbusted

This comment has been minimized.

Show comment
Hide comment
@boldandbusted

boldandbusted commented Feb 12, 2016

👍 :)

@artem-sidorenko artem-sidorenko added this to the v2.0.0 milestone Nov 8, 2016

@artem-sidorenko artem-sidorenko self-assigned this Dec 23, 2016

artem-sidorenko added a commit to artem-forks/ssh-baseline that referenced this issue Dec 23, 2016

artem-sidorenko added a commit to artem-forks/ssh-baseline that referenced this issue Dec 23, 2016

artem-sidorenko added a commit to artem-forks/ssh-baseline that referenced this issue Dec 23, 2016

@atomic111 atomic111 closed this in #157 Jan 12, 2017

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