telnet login failure - related to .sh_history file

[Jeff Smith_15]

Dear HPUX users,

I have a rather funny situation that I can't seem to figure out. When I try to telnet in as a particular user, I get a "connection closed" error. There are no core files created from this event in the users home directory. My workaround is I have to log in as root, cd to the user's home directory that has the login issues, move the .sh_history file to be a backup file, touch a new .sh_history file under the users directory, chown to that user:group and then make the .sh_history file have the correct permissions. This happens very sporatically. What's wierd is I can telnet in as root and su to that user as long as I don't use the "-" option (su dwsuser, instead of su - dwsuser). If I use the "-" option, I get the same connection closed error. Also, I'm not sure if this is related, but the only core file that appears close to the same time is from the dced daemon. I'm not sure what that does or if it somehow impacts the .sh_history file. About the system, we are running HP-UX 11.0, base version (no quality packs). The bad .sh_history files have been ranging from 3K to 10K. I'm wondering if anyone has come across this issue? I know that the .sh_history file should be trimmed at 4K, but it doesn't seem like it's a file size that's the issue because the file size is so inconsistent when the failed telnet occurs. As a side note, it's only happening for one user. All other users can telnet into the box. The infected user performs a lot of operations with the system and oracle. And, last but not least, if, after I do my workaround from above, I put the old, "corrupted" .sh_history file back and telnet into the box again....it works fine.

Anywho, if anyone needs additional information, please let me know.

Thanks,
Jef

[Jean-Luc Oudart]

Not sure this is the same pb. It was on 10.20. We moved to 11.o since.
I think this was more with the connection hanging.

We introduced the folowing change in /etc/profile.
You can customise for your specific needs (and/or user !) :

# -- clear history file
if [ -w ~/.sh_history ]
then
> ~/.sh_history
fi

Rgds,
Jean-Luc

[RAC_1]

This is a workaround to your problem and not the solution.

You can null out .sh_history file in users's profile. Post the results.

[Jeff Smith_15]

Jean-Luc,

Yeah, I looked into zeroing out the .sh_history file as an optional workaround, but it's just sooooooo frustrating not being able to track down why this is doing this. Thanks for the idea. I'm actually going to implement that workaround while I try to figure out what is really going on with this thing.

[Myles McManus]

Hi Jef,

From the su man page:

If the - option is specified, the new shell starts up as if the new
user had initiated a new login session. Exceptions are as follows:

+ The HOME variable is reset to the new user's home directory.

+ If the new user name is root, the path and prompt variables are
reset:

PATH=/usr/bin:/usr/sbin:/sbin
PS1=#

For other user names:

PATH=/usr/bin
PS1=$

+ The TERM variable is retained.

+ The rest of the environment is deleted and reset to the login
state. However, the login files are normally executed anyway,
usually restoring the expected value of PATH and other variables.



Check the .profile and the .kshrc etc. in your user's home directory. Is there anything else weird going on in there? If you create a test user and copy over the contents of your user's home directory do you get the same error? Because it doesn't happen when you omit the '-' option, the answer MUST lie somewhere in the users config files.
Something else you could try is to set the history file to something else and see if that has any impact.


Regards,

Myles

[Todd McDaniel_1]

I am inclined to remove the user and readd them.

I rarely have problems with users, but I sometimes remove them and recreate them.

mv any data to /tmp and cp it back when you recreate them.

I would look at what env variables they have set and I would look at replacing their .profile and other .files to clear out any corruption.



--------------------------------------------
I also agree that if you, as root, su - to the user will overwrite their variables and set them to yours as root, BUT as they login it should re-read the /etc/profile and reset their env variables.