Cannot Login as root

Question

At my work we ship our product on pre-installed servers as a software/hardware package. We are using open SUSE 10.3 for the OS and we setup and we always log in with the root user to do maintenance on the box. Recently we just had box returned to us that the customer said the could not longer connect to the box through the network interface. So when I started to work on the box I run into the this problem: At the command prompt to login i type the user name "root" and hit enter. Then even before it asks me for a password I get "Login incorrect".

I have never seen this behavior before and could not find any information about it online. Does anybody know what is going on?

Thanks.

Answer 1

Check your /var/log/auth.log against failed root login. You might find out something similar to these:

Dec 30 07:31:51 vps login[18093]: (pam_securetty) access denied: tty 'hvc0' is not secure ! Dec 30 07:31:51 vps login[18093]: FAILED LOGIN (1) on 'hvc0' FOR `root', Authentication failure

In modern systems there are lots of new technologies used, and for example XenServer virtualized instance might have console as hvc0.

This can be fixed by including that console into /etc/securetty. Just type: echo hvc0 >> /etc/securetty && kill -1 1 Then try login again.

Answer 2

some possibilities that immediately occur to me:

• most likely, someone changed the root password. which could mean that the box has been hacked.
• the passwd or shadow file got corrupted or deleted somehow.
• ditto for /etc/nsswitch.conf or your PAM configuration.

to fix (or, at least get root access again):

reboot the system. at the grub prompt, edit the kernel line and add "init=/bin/bash". when the system boots, you'll get a bash prompt, and the root fs will be mounted read-only. you'll need to remount it RW. then change the root password. then run sync, remount / as RO again, and "reboot -f now" (optionally do some more investigation/fixing before rebooting).

note: however, that the console tty will be in a very strange state. you won't, for example, be able to kill processes by pressing ^C (because ^C isn't mapped to SIGINT yet). so don't make the mistake of pinging anywhere or running anything else that keeps going until it gets an INT. open a few more VTs with the openvt command before doing anything.

(BTW, for more about this topic, see my blog post ^C doesn’t kill processes, SIGINT does)

Answer 3

I would imagine nobody cares at this point, but I just hit this problem.

Scenario: We attempt to boot SuSE Linux 11 with Rescue mode, and replace the /etc/shadow entry with null so that root can log in without a password. The result is what the original poster said: "Login incorrect" without being prompted for a password. Not sure what, but something else is being changed by passwd.

The solution is to use the real passwd command, and the sticky point is the mount --bind below, because without it, passwd fails as the needed block devices aren't there:

• (boot in rescue)
• mount /dev/sda1 /mnt
• mount --bind /dev /mnt/dev
• chroot /mnt
• passwd root

Then the usual umount, umount, sync, halt.

Hope this helps someone.

Answer 4

Is this over SSH? Most distros (SuSE included) disable root from logging in over SSH by default. The relevant setting is "PermitRootLogin" in /etc/ssh/sshd_config; change it to "Yes" and restart SSHD, see if that works.

Answer 5

Sounds like your best bet might be to use a live cd and look at the actual login config on the box.

Answer 6

Some kind of silly question: are your keyboard broken?

Can you boot your server and start in single mode to get root access and then restore your password with "passwd" command.

Here is a link about how to do this in a Red Hat installation:

http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/s1-rescuemode-booting-single.html

Hope this will help you

Answer 7

This may well be a symptom of a larger problem. Even if you fix the login issue there may be other surprises waiting for you or your customer. Perhaps it would be better and safer to perform a fresh install and be done with it.

Answer 8

Some recent Linux OSs don't have a root account that is log-in-able, instead you must login as a normal user and sudo to root. Do you have another account for that machine?

Answer 9

First you need to get into your system. It can be done with an

init=/bin/bash

into your kernel boot parameters. After booting, you get a root shell without authentication, but nothing other.

Second thing to do, is to make your system running (thus debuggable), while you have further your root shell. It can be done in two steps. First, you need to open a char console, with the command

openvt -c 23 -f /bin/bash

It will open a second root shell on your 23rd virtual console, which you can reach pressing an alt/leftarrow on your first virtual console (later, from X, you can get to this first virtual console with an alt/ctrl/f1).

After that, you can start your system with the command

exec /sbin/init

If all went OK, your system now runs, you can't further log in, but you can soon at least try them, while you have a root console at tty23.

Now try to log in, and check the logfiles in /var/log, what it says. If it is not enough to find and eliminate the problem, this site is waiting you with your next question and interesting error log parts.

Answer 10

This have problem with PAM Auth Module:

cd /etc/pam.d

We also must edit "su" in /etc/pam.d directory

sudo nano su

auth required pam_securetty.so - This line must be commented with "#", only root can login as root, can't change for example form other user to root.

Answer 11

Solved:

In /etc/default/shellinabox I changed:

SHELLINABOX_ARGS=--no-beep

to:

SHELLINABOX_ARGS="--no-beep --service=/:SSH"

This boots the shell as an SSH session. It then follows the rules set in /etc/ssh/sshd_config:

PermitRootLogin yes

Answer 12

It is work for me .

sudo su 
sudo apt install xinit

Then log in as root in UI mode

Answer 13

If this is a turnkey product that your customer didn't have root access to, and you're certain there's a root user and your password that only your company knew isn't working, then it sounds like someone else altered it. Without anyone notifying you of changes then I would assume it's hacked.

Disconnect it from your network IMMEDIATELY.

Use a liveboot CD to access the filesystem if there is something you must get off the box, but I'd personally consider it compromised. If the machine wasn't regularly backed up then our policy is to assume that it doesn't have data of any importance on it and just wipe and reinstall and reconfigure, as you can't really trust any data on it at this point not to be trojaned or altered.