LinuxQuestions.org - Can't login to root -- What protocols manage user login besides PAM?

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Can't login to root -- What protocols manage user login besides PAM? (https://www.linuxquestions.org/questions/linux-security-4/cant-login-to-root-what-protocols-manage-user-login-besides-pam-4175512423/)

Can't login to root -- What protocols manage user login besides PAM?

Tracing the threads of this error, it appears as though some authentication is working because I was able to change the root password using `sudo`.

I don't know the authentication process for `authconfig` but this command works using the updated password for root.

Does this sound like a failure within PAM? or could it be within another group of protocols?

If it matters. I was working on my server remotely and shutdown via ssh, but I think a root account was still logged in at the server. When I rebooted the next day, root was borked.

Below are the only log file to show any real sign of the problem in `/var/log/secure`.

First attempt to login with root:

Code:

    Jul 26 09:38:49 mrwizard login: pam_unix(login:session): session opened for user root by LOGIN(uid=0)

    Jul 26 09:38:49 mrwizard login: ROOT LOGIN ON tty1

    Jul 26 09:38:50 mrwizard login: pam_unix(login:session): session closed for user root

Trying su - and sudo su -

Code:

    Jul 26 09:58:33 mrwizard su: pam_unix(su-l:session): session opened for user root by xtian(uid=0)

    Jul 26 09:58:33 mrwizard su: pam_unix(su-l:session): session closed for user root

    Jul 26 09:58:41 mrwizard su: pam_unix(su-l:auth): authentication failure; logname=xtian uid=500 euid=0 tty=tty1 ruser=xtian rhost=  user=root

    Jul 26 09:58:51 mrwizard su: pam_unix(su-l:session): session opened for user root by xtian(uid=500)

    Jul 26 09:58:51 mrwizard su: pam_unix(su-l:session): session closed for user root

    Jul 26 09:58:58 mrwizard sudo:    xtian : TTY=tty1 ; PWD=/etc ; USER=root ; COMMAND=/bin/su -

    Jul 26 09:58:58 mrwizard su: pam_unix(su-l:session): session opened for user root by xtian(uid=0)

    Jul 26 09:58:58 mrwizard su: pam_unix(su-l:session): session closed for user root

Changing password for root produced this keyring error:

Code:

    Jul 26 09:59:32 mrwizard passwd: gkr-pam: couldn't update the 'login' keyring password: no old password was entered

Off hand, it sounds like the root account is disabled. I know Ubuntu and derivs do this as a matter of course.

The easy work around is

Code:

sudo bash

which opens a bash shell with sudo permissions.

I wish it was that simple. The machine is solely mine and the root account was working. The server is _mostly_ headless and I was doing some extensive reorganizing of my web server's files and directories. But after a reboot, Bonk! No root. No `su -`. Only sudo.

So, I think its best I figure out what's up, or risk losing all access...

Also, tried the `#sudo bash` trick, but no go...

Maybe if authentication for root was turned off? (pam_debug?) Thereby focusing solely on switching user accounts...

Quote:

Originally Posted by xtiansimon (Post 5211345)

The server is _mostly_ headless and I was doing some extensive reorganizing of my web server's files and directories.

Exactly what did you do? Maybe here something got screwed up, please tell us with as much detail as possible what you did.
A few other things:
Is the /root directory present? If so, what are the permissions?
Check disk space & that all partitions are properly mounted.
Post the pam configuration files concerning login - can't tell exactly which files right now, go for the names.

Thank you for posting!

> Exactly what did you do? Maybe here something got screwed up, please tell us with as much detail as possible what you did.
Not a lot really. Just started the server. Worked around a AMP tutorial to re-familiarize myself with the basic setup before I stared working on other things. Not installing anything. Just added the requested iptables for the server access. I just recall that I shut down from the remote without exiting the user account on the system (since its headless, I don't usually login from the actual system, but this time I did).

>Is the /root directory present?
Yes.

>If so, what are the permissions?
550 /root <--------- that's right...?
700, 600, etc inside...

> Check disk space & that all partitions are properly mounted.
The system's fully operational. Its a RAID. If somethings not mounted all manner of flashing lights go off.

Post the pam configuration files concerning login - can't tell exactly which files right now, go for the names.[/QUOTE]

[xtian@mrwizard pam.d]$ cat password-auth

Code:

#%PAM-1.0

# This file is auto-generated.

# User changes will be destroyed the next time authconfig is run.

auth        required      pam_env.so

auth        sufficient    pam_unix.so nullok try_first_pass

auth        requisite    pam_succeed_if.so uid >= 500 quiet

auth        required      pam_deny.so



account    required      pam_unix.so

account    sufficient    pam_localuser.so

account    sufficient    pam_succeed_if.so uid < 500 quiet

account    required      pam_permit.so



password    requisite    pam_cracklib.so try_first_pass retry=3 type=

password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok

password    required      pam_deny.so



session    optional      pam_keyinit.so revoke

session    required      pam_limits.so

session    [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid

session    required      pam_unix.so

[xtian@mrwizard pam.d]$ cat system-auth

Code:

#%PAM-1.0

# This file is auto-generated.

# User changes will be destroyed the next time authconfig is run.

auth        required      pam_env.so

auth        sufficient    pam_fprintd.so

auth        sufficient    pam_unix.so nullok try_first_pass

auth        requisite    pam_succeed_if.so uid >= 500 debug

auth        required      pam_deny.so



account    required      pam_unix.so

account    sufficient    pam_localuser.so

account    sufficient    pam_succeed_if.so uid < 500 debug

account    required      pam_permit.so



password    requisite    pam_cracklib.so try_first_pass retry=3 type=

password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok

password    required      pam_deny.so



session    optional      pam_keyinit.so revoke

session    required      pam_limits.so

session    [success=1 default=ignore] pam_succeed_if.so service in crond debug use_uid

session    required      pam_unix.so

CentOS installs a load of PAM modules...

Code:

[xtian@mrwizard pam.d]$ ls

atd            cvs                  halt          newrole          remote            smtp.postfix    system-config-authentication  vsftpd

authconfig      eject                kcheckpass    other            run_init          sshd            system-config-date            wireshark

authconfig-gtk  fingerprint-auth    kdm          passwd            runuser            ssh-keycat      system-config-kdump          xdm

authconfig-tui  fingerprint-auth-ac  kdm-np        password-auth    runuser-l          su              system-config-keyboard        xserver

chfn            gdm                  kppp          password-auth-ac  screen            sudo            system-config-language

chsh            gdm-autologin        kscreensaver  polkit-1          setup              sudo-i          system-config-lvm

config-util    gdm-fingerprint      ksu          poweroff          smartcard-auth    su-l            system-config-network

crond          gdm-password        liveinst      ppp              smartcard-auth-ac  system-auth    system-config-network-cmd

cups            gnome-screensaver    login        reboot            smtp              system-auth-ac  system-config-users

I posted the one's that I've read about. If there's something else just ask.

What distro are you running?
Is selinux in enforcing mode - check with "sestatus". If it says "enforcing", change with "sudo setenforce 0".

I found some other discussions with rather similar problems, have a look:
https://mail.gnome.org/archives/comm.../msg04657.html
https://bbs.archlinux.org/viewtopic.php?id=144783

> What distro are you running?
Sorry. I cross posted on the CentOS site and guess I omitted this--CentOS 6.5

> Is selinux in enforcing mode?
No. I turned it off for troubleshooting another issue.

I'm going to look at those other links and post back...

Yeah. This problem still persists. Seems circumstance is forcing the issue of system maintenance via sudo.
I'm not using Gnome, but KDE. This bug should not apply.

and you have not reinstalled cent in over 2 months ?

you did something in moving files around

if you royally messed up the SE contexts in /hom/username then se might STOP that user
or
if files in / like /etc are messed up then se might stop a bootup

Cent by default dose NOT use "sudo" you as the admin have to set that up if you understand the security risks
-- that is why it is not set up

use " su " or the VERY different command " su -"
that "-" makes a very big difference
it is the text shortcut for
"su -l root"

Quote:

550 /root <--------- that's right...?

No. It should be owned by root:root and have 710 (or 700 !?).. You probably can't log in because of this..