asked on Cannot log in as root but can login as user and then "su root" succeeds.
I have been using the Redhat 2.4 Linux kernel for about 3 years. Same kernel, many different machines.
We have always ghosted the hard disk to bring up another machine to be sure the install is identical.
I have had the following strange occurrence several times (perhaps once every 6 months) and the only remedy has been to junk the disk and go get one of the backup clones.
The symptom is that when I try to login immediately after boot, the root password fails.
If I log in as myself and the change to superuser, the same password that failed on the initial attempt works, but I can't really do anything else (like startx) because my user account hasn't got the same PATH settings, so the resultant desktop is sort of crippled.
There seem to be other issues, like not being able to start sshd.
Samba, on the other hand, does work, so I can use Ultraedit to compare and/or modify files between this disk and one of the others that doesn't have this "disease", I just don't know where to start.
Some of the files (like passwd and the shadow files) are accessible and I can't see any significant differences between them. Others are locked out due to permissions.
We are ditching the 2.4 kernel soon, and moving to a FC5 2.6 kernel, but I really would like to learn how to salvage the 2.4 system.
I read some procedures having to do with the passwd and shadow files and have tried to do them in the past with no success.
Thanks - Frank
We have always ghosted the hard disk to bring up another machine to be sure the install is identical.
I have had the following strange occurrence several times (perhaps once every 6 months) and the only remedy has been to junk the disk and go get one of the backup clones.
The symptom is that when I try to login immediately after boot, the root password fails.
If I log in as myself and the change to superuser, the same password that failed on the initial attempt works, but I can't really do anything else (like startx) because my user account hasn't got the same PATH settings, so the resultant desktop is sort of crippled.
There seem to be other issues, like not being able to start sshd.
Samba, on the other hand, does work, so I can use Ultraedit to compare and/or modify files between this disk and one of the others that doesn't have this "disease", I just don't know where to start.
Some of the files (like passwd and the shadow files) are accessible and I can't see any significant differences between them. Others are locked out due to permissions.
We are ditching the 2.4 kernel soon, and moving to a FC5 2.6 kernel, but I really would like to learn how to salvage the 2.4 system.
I read some procedures having to do with the passwd and shadow files and have tried to do them in the past with no success.
Thanks - Frank
Linux
Last Comment
fklein23
Try `passwd` under su
reset the root password, it could be that the account is disabled, this should re-enable it.
reset the root password, it could be that the account is disabled, this should re-enable it.
Also, check your /etc/passwd and see what your login shell is. It should be set to /bin/bash or whatever shell you use for the rest of your accounts.
ASKER
To both droyden and MentorJay:
Sorry for the delay in responding, but the grid went down here and I couldn't get to any Internet sites for several hours.
Those are both approaches I have tried.
No good.
Many months ago when I had this same problem, I did an extensive investigation before I decided to just turn the affected drives into data disks, and I found your suggestions together with some more esoteric ones like manipulating the passwd and shadow files. I can't find my notes on the latter, but your suggestions were both in my notes.
If I could get my environment set up so that this login sequence:
login as: rudolph
rudolph@192.168.101.112's password:
Last login: Fri Apr 11 16:51:41 2008
[rudolph@localhost rudolph]$
[rudolph@localhost rudolph]$ su
Password:
[root@localhost rudolph]# cd
[root@localhost root]#
would give me the save environment as
login as: root
root@192.168.101.112's password:
Last login: Fri Apr 11 16:55:16 2008 from 192.168.101.110
[root@localhost root]#
But it doesn't. I can't start XWindows. startx drops me in a completely dysfunctional desktop where all the windows that show up have big red stopsigns with Xs in them and no icons allow me to open a window, shutdown or do anything other than just type "reboot" from an external ssh terminal and start over.
I created a variant of .bashrc that I could source from my console session that set up the path exactly the same as the root path should be set, and that doesn't help at all.
What perplexes me is why the root password fails on console login, but succeeds when I switch to root using su.
In the past I have tried just copying the password files from a different computer to the one with problems and that doesn't work either, although the two drives in question are clones of one another.
Fortunately, the sshd daemon works fine as does smbd, so I can move files around and change protection as needed to get to them, without actually removing the drive and mounting it as a second drive on another system.
In the past, I have tried manipulating the password files more surgically by just squeezing out the password field for root, so the system would boot without a password, in hopes that I could boot and then use passwd to reassign the password. None of these methods have worked.
Perhaps I am not copying the correct files. I can't recall if the password encryption between two systems cloned from the same drive are or are not compatible? I think not, and as I recall, I had to jump through some hoops to do this before. But it just didn't work anyway.
As I said, the problem will probably go away when we upgrade all the computers to the 2.6 kernel, but it REALLY bugs me that I don't know why this happened in the first place or how to correct it. Meanwhile, we just try to keep several cloned drives on ice to swap out when it happens.
This will become an increasingly frightening scenario as our systems make their way out into remote, unattended locations where I can't just get under the hood and swap a drive out.
Thanks again for your help.
- Frank
Sorry for the delay in responding, but the grid went down here and I couldn't get to any Internet sites for several hours.
Those are both approaches I have tried.
No good.
Many months ago when I had this same problem, I did an extensive investigation before I decided to just turn the affected drives into data disks, and I found your suggestions together with some more esoteric ones like manipulating the passwd and shadow files. I can't find my notes on the latter, but your suggestions were both in my notes.
If I could get my environment set up so that this login sequence:
login as: rudolph
rudolph@192.168.101.112's password:
Last login: Fri Apr 11 16:51:41 2008
[rudolph@localhost rudolph]$
[rudolph@localhost rudolph]$ su
Password:
[root@localhost rudolph]# cd
[root@localhost root]#
would give me the save environment as
login as: root
root@192.168.101.112's password:
Last login: Fri Apr 11 16:55:16 2008 from 192.168.101.110
[root@localhost root]#
But it doesn't. I can't start XWindows. startx drops me in a completely dysfunctional desktop where all the windows that show up have big red stopsigns with Xs in them and no icons allow me to open a window, shutdown or do anything other than just type "reboot" from an external ssh terminal and start over.
I created a variant of .bashrc that I could source from my console session that set up the path exactly the same as the root path should be set, and that doesn't help at all.
What perplexes me is why the root password fails on console login, but succeeds when I switch to root using su.
In the past I have tried just copying the password files from a different computer to the one with problems and that doesn't work either, although the two drives in question are clones of one another.
Fortunately, the sshd daemon works fine as does smbd, so I can move files around and change protection as needed to get to them, without actually removing the drive and mounting it as a second drive on another system.
In the past, I have tried manipulating the password files more surgically by just squeezing out the password field for root, so the system would boot without a password, in hopes that I could boot and then use passwd to reassign the password. None of these methods have worked.
Perhaps I am not copying the correct files. I can't recall if the password encryption between two systems cloned from the same drive are or are not compatible? I think not, and as I recall, I had to jump through some hoops to do this before. But it just didn't work anyway.
As I said, the problem will probably go away when we upgrade all the computers to the 2.6 kernel, but it REALLY bugs me that I don't know why this happened in the first place or how to correct it. Meanwhile, we just try to keep several cloned drives on ice to swap out when it happens.
This will become an increasingly frightening scenario as our systems make their way out into remote, unattended locations where I can't just get under the hood and swap a drive out.
Thanks again for your help.
- Frank
check your /etc/securetty file
what are the contents there? That will list the ttys that root is allowed to log in from.
It's also possible that root logins are disabled through PAM, but I don't recall where that's set off the top of my head, perhaps someone else does?
what are the contents there? That will list the ttys that root is allowed to log in from.
It's also possible that root logins are disabled through PAM, but I don't recall where that's set off the top of my head, perhaps someone else does?
ASKER
A copy of securetty is attached (renamed securetty.txt for attachment purposes)
It specifies the console as one of the legal login nodes.
securetty.txt
It specifies the console as one of the legal login nodes.
securetty.txt
well, it was a bit of a stretch.
I'd suggest reading up on PAM, because I know root can be disabled through there, but I've never done it.
I'd suggest reading up on PAM, because I know root can be disabled through there, but I've never done it.
ASKER
But how can this happen by accident with PAM? I didn't do anything but shut down, set the hard disk aside for a few days and then reinstall it and try to boot.
Most likely can't.
Have you run a hard drive diagnostic? Try the Ultimate Boot CD, it has several hardware diagnostics.
Have you run a hard drive diagnostic? Try the Ultimate Boot CD, it has several hardware diagnostics.
ASKER
MentorJay:
I think your suggestion about checking disk integrity is a good one.
So far I've used the Salvation Scan from the UBCD and found no defects on the hard disk.
Haven't done a file system check, though. Interestingly when I boot, the Linux boot sequence doesn't ask me if I want to do a file system integrity check, even if I purposely kill the power while Linux is booted, which should have left the fs in a potentially compromised state.
If I don't get the prompt to check the file system at boot time (as I have often gotten at boot time) I am stuck:
How do I go about running a file system check on an unmounted disk? fsck issues pretty strong warnings about running it on a mounted volume.
So I'm not really sure what one does to get the equivalent of the boot time file system integrity check.
I think your suggestion about checking disk integrity is a good one.
So far I've used the Salvation Scan from the UBCD and found no defects on the hard disk.
Haven't done a file system check, though. Interestingly when I boot, the Linux boot sequence doesn't ask me if I want to do a file system integrity check, even if I purposely kill the power while Linux is booted, which should have left the fs in a potentially compromised state.
If I don't get the prompt to check the file system at boot time (as I have often gotten at boot time) I am stuck:
How do I go about running a file system check on an unmounted disk? fsck issues pretty strong warnings about running it on a mounted volume.
So I'm not really sure what one does to get the equivalent of the boot time file system integrity check.
fsck /dev/sdxX
where sdxX is the partition number of the device.
If it's your root partition, you can run this from a liveCD
where sdxX is the partition number of the device.
If it's your root partition, you can run this from a liveCD
ASKER
MentorJay:
Thanks for the pointer... I just ended up taking the hard disk over to another system and connecting it as /dev/hdb
I then used fsck on it while it was unmounted and found that there were (as I suspected) no errors.
Hmmmm... so just to recap:
1. no fs errors
2. root can't login at the console
3. other privileged users CAN login and become superuser via "su root", which pretty much proves that the root password is OK
4. root can't be locked out by PAM because the password files are all OK: /bin/bash is specified as root's login shell and no other root lockouts are in place, at least no that I can find.
5. ALSO, root can login just fine via ssh, which seems to indicate that the root password is fine.
So we seemed to be stumped as a community... I don't feel so bad that I've had this problem off and on for 2 years and not been able to figure it out.
Thanks for the pointer... I just ended up taking the hard disk over to another system and connecting it as /dev/hdb
I then used fsck on it while it was unmounted and found that there were (as I suspected) no errors.
Hmmmm... so just to recap:
1. no fs errors
2. root can't login at the console
3. other privileged users CAN login and become superuser via "su root", which pretty much proves that the root password is OK
4. root can't be locked out by PAM because the password files are all OK: /bin/bash is specified as root's login shell and no other root lockouts are in place, at least no that I can find.
5. ALSO, root can login just fine via ssh, which seems to indicate that the root password is fine.
So we seemed to be stumped as a community... I don't feel so bad that I've had this problem off and on for 2 years and not been able to figure it out.
Have you checked the logs for any clues? I'll try something like /var/log/messages
R.
R.
ASKER
I think I did. The drive is offline now after the upgrade to 2.6 kernel. I will mount is as a second drive someday and try this out. No time for it now.
This will have to simmer on the back burner for a little while.
This will have to simmer on the back burner for a little while.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
It happened again. Linux 9 2.4.20-8 kernel. Most annoying.
If you want to login to it, you could try to boot into single user mode and reset the root password.
no doubt its using lilo so at the lilo: prompt
linux init=/bin/sh
will drop you at a bash#
then: mount -o remount,rw /
passwd root
enter passwd
and reboot, see if that works