"@" character not accepted by login and password prompt

[anthony natale]

Good Morning All,

Our DBA's had an interesting situation appear yesterday. A couple of passwords expired so they were prompted to change them and enter the old password. Everytime they entered their old password they were welcomed with a "sorry" and disconnected.

System Info:
OS : 11.0, 10.2
SSH 3.2
Trusted Host
Problem also happens on workstations without trusted host or ssh installed.

The DBAs use @ symbols in their passwords so I thought it may be a keyboard mapping problem, it wasn't, as far as I could tell. Sending a hard coded password from the client side worked, because the system allowed them to log in and change their passwords. The problem seems to be happening on the server side when a login or password prompt is used.

Has anyone ever experienced this and if you did, what is the fix? By the way, the # symbol seems to be interpreted as a backspace as well. This always happens at the "login:" prompt (and probably the "password:").

BTW, this problem does not happen on our Sun servers.

Thanks for any help,

Ant.

[Paula J Frazer-Campbell]

Hi

What has changed?
Could they do it in the past?

Paula

[Hai Nguyen_1]

Anthony,

I did have an experience with "#" in a password. I used "\" without quotes to escape it. Then I was able to login or change a password.

Hai

[Pete Randall]

Ant.,

From man passwd:

"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."


Pete

[James R. Ferguson]

Hi:

Than man pages for 'getty' specifically note that "it is not possible to log in by means of
getty and type a #, @, /, !, _, backspace, ^U, ^D, or & as part of your login name or arguments." These characters have special meaning.

Regards!

...JRF...

[Sridhar Bhaskarla]

Hi Ant,

unless the underlying shell from which you are accessing the box has the "stty -kill" set to a different one, this (@) will by default kill the line.


-Sri

[Bill Douglass]

As mentioned, # and @ are not allowed when logging in through the tty driver.

You can use these in a password when connecting via ssh. This raises some interesting problems when I changed a user's password, and they discovered that they could not log in. I was connecting vai openssh, while they were using telnet.

I would prefer to see this fixed in hp-ux, since it does restrict he character set available for buiulding passwords.

[Steven E. Protter]

If you implement LDAP and let a Microsoft server handle logins, you can have these characters in the password.

Hardly worth it for this though, I'd just stop using special characters.

SEP

[Bill Hassell · Accepted solution]

The default behavior for login is different than at a shell prompt. The # sign is a backspace while the @ symbol cancels the line. This has been the classic default for HP-UX (and Unix in general since the days of teletypes). So stty in /etc/profile doesn't have any effect on the login and password strings.

However, you can change every login (serial, modem, telnet, etc) by using a new device file and this construct:

stty erase "^H" < /dev/ttyconf

This will set the driver option for all connections prior to login. It takes effect immediately except for the serial console port which will require a reboot. You can add other stty values such as:

/sbin/stty erase "^H" kill "^U" intr "^C" eof "^D" -parity ixoff < /dev/ttyconf

This works on current versions of HP-UX with appropriate patches.

[anthony natale]

I wanted to thank all of you that have responded so quickly.

I will take note of the solutions and see what is the best implementation.

I agree that the HPUX platform should allow ALL special characters when creating passwords as we are trying to encourage users to be a bit more creative in password choices.

Thanks again for all the help.

[doug mielke]

The different behaviours at different times / locations could be explained by TERM.
Since this problem happens at login, you would be using a different TERM setting than after they log in to change passwd (listed in the system or users profile), since at this point, that hasn't been read.

[Bill Hassell]

Be careful about mixed platforms. No one at Microsoft consults with Unix vendors to see what would be compatible (and vice versa). There will always be differences (especially for user names and passwords) that cannot be made compatible across all platforms and special characters are the most common class of incompatibilities. While the ttyconf solution handles (current patches) HP-UX, there are no guarentees that a special character will not cause problems with other systems. Alpha-numeric is 100% safe and creative passwords like v6dGys32 are excellent but just a bit difficult to remember. Another alternative is to use the first letters of a sentence or motto.