02-07-2012 11:22 AM
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
[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
FYI: This is an rx6600 running HPUX 11.31.
Solved! Go to Solution.
02-07-2012 11:41 AM
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?
02-07-2012 01:12 PM
@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?
02-07-2012 01:24 PM
>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?
02-07-2012 01:32 PM
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!
02-07-2012 01:39 PM
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... :(
02-07-2012 02:05 PM
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?
02-07-2012 03:08 PM
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.)
02-07-2012 03:13 PM
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.
02-07-2012 06:34 PM
> 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 "\".
02-08-2012 11:42 AM
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..
09-20-2012 07:34 AM
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.
11-23-2012 06:33 AM
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.
11-23-2012 10:07 AM
>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.