root login at console not working (is allowed in /etc/securetty and root password is correct)

[Greg Taylor]

I cannot login as root when accessing the console via the MP (management processor).

I can su to root after logging in as me. So I know I have the correct root password, etc.

As you can see, there is an entry for console in /etc/securetty...

[root@myhost /root] # cat /etc/securetty
console
[root@myhost /root] #

And this is the result of trying to login as root on the console (via MP) with the correct password.

Console Login: root
Password:
Login incorrect
login:

Any ideas???

FYI: This is an rx6600 running HPUX 11.31. 

[Bill Hassell]

Just to make sure it is related to the securetty file, remove it and try logging in again. If that works, there may be some junk characters in the word console. To put the console back again:

echo "console" > /etc/securetty

 If it doesn't work, are you logging into the console with telnet? Are you using an iLO2 terminal window?

[Greg Taylor]

@Bill,  Thanks for trying to help!

I am using PuTTY to connect to the MP with SSH and then accessing the console.  Though I also tried using a web browser to access the iLO console/terminal window too.  Both yield the same results.  I cannot login as root  either way.  However I can login as me and then su to root without any problem (so I have the correct password for root, etc). 

I cleared out the /etc/securetty file and put console back in there via the echo command as you suggested.  Unfortunately that did not make a difference.

we have four HPUX systems, three 11.31 and one 11.11 and I can't login as root (via the console) on any of them.  I'm beginnig to wonder if a past co-worker did something on all of them to prevent this.  Though I know I have logged in as root on via the consoles in the past.  

I thought you could login at the console as root no matter what; even if the account is locked (as long as you have the correct password and "console" is in the /etc/securetty file).  

Any more ideas?

[Dennis Handly]

>I cleared out the /etc/securetty file and put console back

Did you try logging in after you removed the file and before you put it back?

[Greg Taylor]

@ Dennis

I opened the /etc/securetty file with vi and cleared it out and then saved it, and then ran the echo command to put console back in there.  I did not actually remove and recreate the file.  On that note the file looks like this.

-rwx------ 1 root sys 8 Feb 7 13:56 securetty

I asume ownership and permisisons are good...

And yes I tried logging in before and after doing that but no luck.  Since I am getting the same result on four servers I didn't think the file was corrupted, etc so that is why I only cleared it out and did not remove and replace it.  I guess I can try that too since I am grasping at straws now.

Thanks for your help!

[Greg Taylor]

So I just removed the /etc/security file and tried to login as root at the console (before recreating the file) and still could not, so I recreated the file and tried again and still could not login...   :(

[Dennis Handly]

Ok, it looks like you already tried to remove it and login.

[Greg Taylor]

Yes, I was a little slow and did not understand the suggestion completely the first time, but did try that...  

I sent an email to the person who no longer works here to see if he did anything unique to the servers that would cause this but I really doubt he did (and it may be a day or so before I hear back from him).  It just would not make sense to disallow root login at the console (at least for our environment), and like I mentioned previously, I have logged in at the console as root in the past.  So I am really baffled as to what has changed. 

Besides /etc/security, is there anything else that would effect root login at the console?

[Patrick Wallek · Accepted solution]

Does your password contain any special characters like @ ! # etc?

[Greg Taylor]

Yes it does have a special character "@".  Do you think that is it, and if so, what is the reasoning?  

I can test and see if that is the cause/solution...  

If it is, are there any special characters that are okay to use?  (Our password standards require a special character.)

[Greg Taylor]

@ Patrick

Yessssss!  That was it.  I changed the password and was able to login at the console.  Thanks so much!

Now I need to negotiate with security for a root password that doesn't contain a special character or find a special character that does not cause problems.

[Dennis Handly]

> Now I need to negotiate with security for a root password that doesn't contain a special character or find a special character that does not cause problems.

No need.  You just need to change your fingers.  :-)

The only special chars with problems are "#" and "@".  Under stty, these are backspace and kill.

So you can either not use these two as mentioned under passwd(1), WARNINGS.

Or you must escape those chars with "\".

[Bill Hassell]

Every sysadmin needs to raise a flag when security requires special characters. Every operating system will have some quirk due to special characters. I simply demand that they never be allowed so that the same rule will work on all systems -- alphanumeric characters, upper and lowercase.

However, you can get the HP-UX system to remove the special meaning for @ and #.  Put this line in /etc/inittab:

ttco::bootwait:/sbin/stty intr ^C erase ^H kill ^U < /dev/ttyconf 

 What this does is to configure the tty driver to redefine the archaic definitions for erase and backspace. This is done in /etc/profile but that is too late for login. By setting the value at boot time for the driver, all terminal I/O such as logins will be processed correctly. Put the above line in inittab on all your HP-UX systems. You can then run the command by hand:

/sbin/stty intr ^C erase ^H kill ^U < /dev/ttyconf 

 to set the current tty driver defaults. Now your password can contain @ or # and it will work OK. BUT, as I said, special characters will not work the same on every OS so don't use them..

[vz7r1x]

Great analysis.

This solved my problem too.  I had @ in my password and caused my MP to fail connection to the HP-UX server.  I removed @ character from the passwordand started working.

Thanks

[John Dvorchak]

What a lot of folks don't know, and this goes back to the days of a "teletype" type mechanical console. I'm talking back in the 70's, is that the @ sign meant "delete to end of line".  So in effect anything after the @ sign is not considered and erased. That is why the @ sysmbol should never be used in a password on an HPUX system.

[Dennis Handly]

>is that the @ sign meant "delete to end of line".

That's delete from the beginning of the line.

Bill has told the TTY history much better in one of his other posts.

[MIke_Kapsak]

My issue is a little different with the root login. I am connected serially via a console switch to the serial console port on my rx6600. WHen I telnet to that console port I am able to bring up the MP Main Menu by using <ctrl> b. But when I enter CO for console mode I press return but no console prompt. I get a carriage return each time I press enter. I can go back to the MP menu anytime.

In other words I do not get a login prompt.

Thanks,

Mike Kapsak

[Torsten.]

Maybe another process is running and block the console? I would try to use ps and grep console.

It could help to review the console log from MP too.

[Bill Hassell]

Something has the console open. The connection from the MP (a separate managment computer inside the rx2660) to HP-UX is through a special port. Whether you use a serial cable or the built-in LAN connection to the console, the CO command takes you directly to the console. With no response (prompt, etc), some process is holding the console connection. 

Start by typing ctrl-c to kill the process. If that doesn't work, type ctrl-\ (ctrl and the backslash or vertical bar). These are the two signal characters that can terminate a process in the current session.

If that doesn't work, from the regular HP-UX LAN connection, login and run this command:

# ps -f -t console

This will show all processes that are using the console. You can then kill the process ID (or multiple IDs). If the process cannot be killed, you use the kill -9 option, but if that doesn't work, the connection is hung on I/O (typically networking) and cannot be killed.

One other possibility: if you used the MP to login to the console, then used an HP-UX command like telnet or ssh to other systems (a very bad idea), you'll need to untangle the leap-frog connections back to your rs2660. Always use the MP -> CO connection for local commands that do not involve other systems.

Rebooting the rx2660 will clear and leap-frog connections and if that faills to clear the CO coonection, you can reset the MP from the MP -> CM menu.