1752444 Members
6169 Online
108788 Solutions
New Discussion юеВ

Re: Console Login Issue

 
SOLVED
Go to solution
HPUX-newbie
Occasional Advisor

Console Login Issue

I'm new to HP-UX.  I have a couple of versions setup (11i v1 and 11i V2) for testing purposes.  I didn't realize that I couldn't use "@" in my password and login via the Console.  I was able to change my password on my V2 system as I already had SSH installed, but I am not able to on my V1 system.  I've tried to Telnet in, but can't login that way either.

 

Any ideas how to get in and change the password?  Talk about learning pain!


Thanks!  Cheers...

9 REPLIES 9
Bill Hassell
Honored Contributor

Re: Console Login Issue

This is a very old restriction based on the teletype console heritage. The @ character is the line cancel, and the # character is used to erase characters. Coupled with the default baud rate (300 baud for serial ports except the console), these archaic settings still continue to be the defaults. You'll need to add this line to inittab:

 

ttco::bootwait:/sbin/stty intr ^C erase ^H kill ^U < /dev/ttyconf  # set backspace and @ correctly

 

Now when the system reboots, the special meaning for # and @ will be removed. But this is also an important lesson in interoperability between operating systems, especially passwords and filenames. Special characters are very bad choices for passwords and filenames. There's no industry standard for these characters (including spaces) so it is always prudent to avoid special characters if you have to manage multiple systems (any flavor of Unix, any version of Windows, MPE, OpenVMS, etc).

 

If the password problem is with aq normal user, just change the password after you login as root. But if the root login has the problem, you have limited choices. There are some convoluted methods using su or sudo but the easiest way is to reboot into single user mode. Then you can edit the passwd file and remove the password for root. If your system is trusted, you'll need to edit the root entry in  /tcb/files/auth/r/root and remove the password.




Bill Hassell, sysadmin
Steven Schweda
Honored Contributor

Re: Console Login Issue

 
Dennis Handly
Acclaimed Contributor

Re: Console Login Issue (#/@ in password)

 >I didn't realize that I couldn't use "@" in my password and login via the Console.

 

It's right there under passwd(1):

WARNINGS
Avoid password characters which have special meaning to the tty driver, such as # (erase) and @ (kill).
You may not be able to login with these characters.

 

>Any ideas how to get in and change the password?

 

Simple, you just need to quote the "@" or "#", like "\@".  You'll need to remember you can only use "\" for the cases where "@" is treated special.

 

Of course my problem is the opposite.  When I know I made a mistake typing in my password to my screen locker, I type a "@".  But I don't know what to type for other forms of password input: ftp, rlogin, telnet, ssh

I'm not sure whether kill or erase works or not and what they are at that time.

 

>There are some convoluted methods

 

Quoting isn't convoluted.  ;-)

Matti_Kurkela
Honored Contributor

Re: Console Login Issue

For brevity, I'll call anything that treats '@' and the other HP-UX default TTY control characters specially "@-sensitive", and anything that does not treat them specially "@-insensitive".

 

To cover all the bases, there are four possible situations:

 

  • password is set using an @-insensitive method (e.g. a regular passwd command), and login is attempted using an @-insensitive method (OpenSSH and its derivatives, FTP... both assuming that the client-side does not use a unix-style TTY driver with HP-style ancient defaults): no problem.
  • password is set using an @-sensitive method (some custom password-setting tool?), and login is attempted using an @-sensitive method: no problem, although your stored password is not what you think it is. (Anything up to and including the last '@' character is omitted from the stored password.)
  • password is set using an @-insensitive method, and you're logging in using an @-sensitive method (HP-UX console or telnet login): A tricky problem. You'll need to escape that '@' somehow, or find an @-insensitive method that allows you to either change your password or overwrite the appropriate password file.
  • password is set using an @-sensitive method, and you're logging in using an @-insensitive method: A small problem. Just use a shorter version of your password, omitting anything up to and including the last @ character. For example, if your password was 'aaa@x0', try logging in with just 'x0'.

> Simple, you just need to quote the "@" or "#", like "\@".  You'll need to remember you can only use "\" for

> the cases where "@" is treated special.

 

Dennis, have you tested this? A backslash is the standard shell-level escape character, but in the console password prompt, there is no shell involved. When the login process is prompting for a password, it tells the tty driver to disable the echo feature (so the password will not be displayed on the terminal) but I don't think it changes anything else: the tty driver will still be in "cooked mode".

 

If my theory is correct, the password input comes from the console port hardware to the tty driver, which passes it to the process only after the Enter key is pressed. (This is what allows the special meaning of the @ character take effect in the first place.) The backslash escape processing built into the login binary cannot help here, as the process never receives the '@' character and any characters preceding it at all.

 

The solution would be the tty-driver-level escape character, known as lnext.

 

Unfortunately, man 7 termio has some bad news about the lnext character (emphasis mine):

"The special characters are assigned their default character values when the terminal port is opened. The default values used are those specified by the System V Interface Definition, Third Edition (SVID3), except for the WERASE (Ctrl-W) and LNEXT (Ctrl-V) characters which are set to _POSIX_VDISABLE to maintain binary compatibility with previous releases of HP-UX."

 

In other words: no lnext for you unless someone or something (e.g. a version of Bill's /etc/inittab addition) changes the tty default settings to enable it!

 

Gee, I know HP-UX is dedicated to maintaining backwards compatibility, but I think this might be going a little too far.

 

My suggestions to solve the problem:

Can you log in as some other user, fix the stty settings for that session (stty intr ^C erase ^H kill ^U), then use "su -" to gain root access?

 

If that is not possible... the original poster indicated the problem is in a 11.11 test system. 11.11 should have FTP enabled by default for all users, including root. A FTP server does not need a TTY driver to process its inputs: any command-line editing happens strictly client-side. This means it should be @-insensitive. If the target system has not been secured to disallow root FTP access, you could make a FTP connection as root from another host (if it's a HP-UX host, make sure *it* has sane, @-insensitive stty settings in the current session before making the attempt).

 

If you can log in with FTP, download the appropriate password file (/etc/passwd for standard mode; /tcb/files/auth/r/root for Trusted System Mode), edit it to remove the root password hash or to replace it with the hash of a known @-free password, then upload the modified password file back to the target system.

 

If FTP root logins have been blocked, it might be time to test the "lost root password" procedure. If the "booting to single-user mode requires authentication" feature has not been enabled (it's disabled by default), this is as simple as crashing the system and booting it to the single-user mode. 11.11 means PA-RISC, so the process on most server models is:

  1. interrupt the firmware boot process
  2. type "boot pri" to the PDC firmware boot prompt
  3. answer Y to the "interact with IPL/ISL?" question
  4. type "hpux -is" to the ISL> boot prompt
  5. wait for the system to boot
  6. once you reach the root shell, type "mountall" before doing anything else.

Workstation models may have some differences in step 2, but the general idea should be the same.

MK
HPUX-newbie
Occasional Advisor

Re: Console Login Issue

Actually, I received no alert when I used the passwd command from the console window. I also tried encapsulating the password with quotes and this didn't work either. Thanks for the reply though!
HPUX-newbie
Occasional Advisor

Re: Console Login Issue

@Matti,

 

So far your "final" option seems to be the one that I had to use. I was able to edit the passwd file, but not able to get logged in afterwards. So, I crashed the system and I am at the command prompt. One quick question - how to set the password now? I've tried executing passwd, but can't get it to take the command.

Sorry if this is a kindergarten question - but this is a bit new for me.

 

Thanks much!

Dennis Handly
Acclaimed Contributor
Solution

Re: Console Login Issue (#/@ in password)

>Dennis, have you tested this? A backslash is the standard shell-level escape character, but in the console password prompt, there is no shell involved. When the login process is prompting for a password, it tells the tty driver to disable the echo feature (so the password will not be displayed on the terminal) but I don't think it changes anything else: the tty driver will still be in "cooked mode".
.
I must have years ago.  It would be simple if HPUX-newbie confirmed it.

But right now, I cloned a user and logged in and set the stty values to mutual ones.  Used passwd(1) to change the password to "aaaaaa##".  This worked and I was able to login from my shell.
Then I changed erase back to "#".  I then used login(1) and typed "aaaaaa\#\#" and again I was able to login.
Leaving out the "\" failed.

 

>the password input comes from the console port hardware to the tty driver, which passes it to the process only after the Enter key is pressed. (This is what allows the special meaning of the @ character take effect in the first place.) The backslash escape processing built into the login binary cannot help here, as the process never receives the '@' character and any characters preceding it at all.

 

I'm in a rlogin session and so I'm using /dev/pts/10 and it works.  Not sure if getty and the console are different?

The only backslash processing code directly in login(1) is for the username.  Not sure if it may be in the PAM routines too?

 

>I know HP-UX is dedicated to maintaining backwards compatibility, but I think this might be going a little too far.
.
Many people have said that in the forums.
.
>I received no alert when I used the passwd command from the console window.
.
Alert for what?
.
>I also tried encapsulating the password with quotes and this didn't work either.
.
Of course not.  Did you try using a backslash?  (So I can find out whether login(1) only works from a shell and not the console?)
HPUX-newbie
Occasional Advisor

Re: Console Login Issue


@Dennis Handly wrote:
>Dennis, have you tested this? A backslash is the standard shell-level escape character, but in the console password prompt, there is no shell involved. When the login process is prompting for a password, it tells the tty driver to disable the echo feature (so the password will not be displayed on the terminal) but I don't think it changes anything else: the tty driver will still be in "cooked mode".
.
>I must have years ago.  It would be simple if HPUX-newbie confirmed it.

@I replaced the modified passwd file with the original and rebooted to test Dennis' theory.  Drum roll please...  It worked!  I logged in via FTP first to ensure that the password file was correct and using the malformed password.  Then from the login prompt of the CO connection, I was able to put \'s in front of the @'s and was able to successfully login.
Appreciate ALL the advice/suggestions!!!  Having spent very little time in HP-UX years and years ago, I am glad these forums are here or I'd be reloading an OS.
Thanks much!  Cheers...
Dennis Handly
Acclaimed Contributor

Re: Console Login Issue (#/@ in password)

>Drum roll please...  It worked!

 

I'm glad my memory isn't shot.  :-)

 

If you are happy with your answers, please click on the Kudos stars for each helpful answer.