1

I was doing some maintenance on my web server (via root account over ssh) after several months of disuse. I shut it down yesterday and today, after startup I can't log in to root account at tty or via ssh. Only thing standing out in my mind is the root account was logged in at the system and I shut down remotely.

I found a link here suggested a fix to reset the root password from rescue mode. I followed the advise to bind the /dev directory with LVM before chroot and changed the password and restarted,

Root will still not login.

The only log file to show any real sign of the problem was /var/log/secure. Right at the top you can see the attempt to connect via SSH and then at the term tty1. // UPDATE I've updated the errors from /var/log/secure to just reflect the suggestions:

First attempt to login with root today:

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 -

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:

Jul 26 09:59:22 mrwizard sudo:    xtian : TTY=tty1 ; PWD=/etc ; USER=root ; COMMAND=/usr/bin/passwd
Jul 26 09:59:32 mrwizard passwd: pam_unix(passwd:chauthtok): password changed for root
Jul 26 09:59:32 mrwizard passwd: gkr-pam: couldn't update the 'login' keyring password: no old password was entered

$ authconfig --test works

Jul 26 12:38:04 mrwizard userhelper[31089]: running '/usr/share/authconfig/authconfig.py --test' with root privileges on behalf of 'xtian'

// END UPDATE

Where else can I look? Did I bork the root access shutting it down remotely while still logged in at the box?

1
  • I'd say kill it. Vovor caught a failed login but I realized later that was a legit failed login because the box is headless. When I do connect a keyboard, its always awkwardly in my hands and I frequently mistype something. Volvor and I sorted out some things in comments, but nothing panned out. This is a real pain in the arse problem. prolly has a simple fix, but I've not found it yet. I'd rather try again with fresh logs and fresh eyes.
    – xtian
    Aug 18, 2014 at 21:01

2 Answers 2

1

Your error is :

Jul 25 17:35:25 mrwizard login: FAILED LOGIN 1 FROM (null) FOR `root, User not known to the underlying authentication module

Which means your system can't find the user root user while authenticating, yet sudo still works which means both authentication of normal user and user listing works. What's the status of the /etc/nsswitch file ? It should have either compat or files on the shadow line + whatever means of central authentication you use.

Since sudo is still working, you don't need to reboot in "rescue mode" to reset the password, just use sudo passwd, does that output any errors ?

If nsswitch is normal, what happens if you sudo su - ?

10
  • Good eyes picking out that error. sudo passwd does not produce any errors. sudo su - is a clever trick, but continues as before. I typed in an incorrect password and su reports successfully it was a bad password. nsswitch.conf appears ok on opening. Checking a few other things...
    – xtian
    Jul 26, 2014 at 13:47
  • /etc/shadow line for root is present and appears ok. And I would guess the fact the wrong password gets rejected would support this. As another post at unix & linux suggests, its difficult to conclude a file is 'corrupt'.
    – xtian
    Jul 26, 2014 at 15:07
  • Here's something interesting. I was looking for something called an auth.log and accidentally triggered authconfig; authconfig --test command (an interface for configuring system authentication resources) authenticates root password. Suggesting... something with root's directory ..?
    – xtian
    Jul 26, 2014 at 16:21
  • Can you check the permissions on the /root directory and the content of both the .bashrc and .profile file of the /root directory ?
    – Vovor
    Jul 27, 2014 at 15:19
  • I updated the secure output above to include this line. The results of the authconfig are not important. Unlike other commands which complain the user does not have sufficient privileges, authconfig prompts the non root user for the root password. So...I changed sudo passwd. Used authconfig with a do nothing argument --test and the new password was in effect. Therefore, some component of root authentication is working. Now the question is why can't I login as root...
    – xtian
    Jul 27, 2014 at 15:27
0

Have you checked if in SSHD config file (ussally /etc/ssh/sshd_config) the directive PermitRootLogin is set to yes?

5
  • You think that file was damaged? Maybe I wasn't clear--I was connecting via root account over ssh yesterday. Today I can't use root at all.
    – xtian
    Jul 26, 2014 at 0:37
  • Or maybe a problem with PAM. Can check if any file is damaged at /etc/pam.d/?
    – mvillar
    Jul 26, 2014 at 0:42
  • I'm not sure I'd know what to look for exactly, but a quick ls -alt doesn't show any recent changes... permissions and owner appears normal. Reading a few files with cat doesn't find, er, one that doesn't read...
    – xtian
    Jul 26, 2014 at 0:54
  • I'm not sure if corruption of files will be reflected in the date of last change. Might be great if you can compare existing files at /etc/pam.d/ or /etc/ssh/, or if you can make a fsck of the filesystem that contains /etc
    – mvillar
    Jul 26, 2014 at 1:02
  • Yes. Of course, fsck...
    – xtian
    Jul 26, 2014 at 13:47

Not the answer you're looking for? Browse other questions tagged .