su: cannot open session: Permission denied

Question

I'm getting "access denied" attempting to login as root on the console and via ssh (Yes, I know root ssh access should be disabled - I've just inherited this box). I can login as non-root user who has sudo access to "ALL", but when I sudo su - I get:

su: cannot open session: Permission denied

If I run 'su' with what I believe is the right password, I get "Authentication failure".

Looking around the internet, I can see lots of instances where people cannot "su - non-root-user" but none of the remedies which worked there seem to apply here. Permissions on /etc, /etc/pam.d are 0755, and /etc/pam.d/* are all 0644 except for the symlinks which are more permissive. Root's shell in /etc/passwd is /bin/bash (working for my non-root user). There is no /etc/nologin

This is a rather aged Centos host.

I would prefer not to take the box offline to repair it unless I have to. What else could be preventing root logins / su / sudo su ?

Update The host isn't as old as I thought - its Centos 7.4

I can get to root privileges by running

sudo -u root /bin/bash

(but the more conventional methods are still failing with the same error).

On attempting to run 'su' the following log entries appear (but su reports the error to stdout and exits)

 May 17 15:25:06 myhost su: pam_limits(su:session): Could not set limit for 'nofile': Operation not permitted
 May 17 15:25:06 myhost su: pam_unix(su:session): session opened for user root by symcbean(uid=0)

Solution

While @doneal24 is quite correct to point out that the first place to look is in the logs, since this box is logging locally, I couldn't that without root privileges! :(

But when I identified I could still get to root using sudo -u root /bin/bash I was able to see the logs....google the error messages and found that there was an issue with /etc/security/limits.conf.

Removing the references to 'root' restored the access.

Comments

[doneal24]

Couple of places to look. It's unlikely, but the console could be marked as non-secure by /etc/securetty. More likely is logging in is blocked by /etc/default/access.conf. Have you checked in /var/log/secure after your authentication failures to see if any reason for the failure is being logged?

[RubberStamp]

Possibly related

[derobert]

Errr... does sudo -i work?

[chrishollinworth]

@doneal24: /etc/securetty is the same as on machines not exhibiting the same problem and rpm -V setup suggests it has not been changed. /etc/security/access.conf has no policies enabled.