"ESC k" historical command retrieval

[Omar Ghalib]

Hi,

I need to turn off executed commands from automatically being logged to the command history buffer for later retrieval using "ESC k" in ksh.

I need to do this for security reasons. As I am writing, I came up with an idea that by redirecting output/input to /dev/null I would do this. But I am sure there is got to be a more elegant way.

Thanks

[Wodisch]

Hello,

since the history must be explictly enabled to work, all your have to do, is to delete the enabling commands in your shell's start scripts:
/etc/profile
$HOME/.dtprofile
$HOME/.profile
$ENV

These commands are:
export HISTFILE=...
export HISTSIZE=...

Or you may point your "HISTFILE" to "/dev/null".

HTH,
Wodisch

[Deepak Extross]

Do a "set +o vi" to disable historical command retrieval.

Alternatively, what I like to do is:
alias exit="> $HOME/sh_history ; exit"
This zero'es out my history file each time I logoff, but as long as my session is valid, I can use history commands issed earlier in my session.

[harry d brown jr]

Omar,

Actually, that's NOT a good security reason, it's exactly the opposite.


If "root"'s commands are not be logged, then that's a greater security risk than worrying about someone looking at those commands that they might have executed.

If that's the case, make the .sh_history file read only by the OWNER.

If you have some applications that expect you to pass PASSWORDS on the command like, then either wrap those applications with a shell script that echo's off and on and then launches the command.

Just thinking about this makes me laugh. If you have a command that has a passwd field on the command line, then "ps -ef" will probably show it - providing the command line isn't too long.



live free or die
harry

[Deepak Extross]

Harry,
My guess is that his problem is related to multiple users sharing the same login id. Probably he doesn't want these users to pull up each other's history when they do an Esc-K.
If this is indeed the case, the ideal solution would be to give each user a distinct login. Instead of having 3 users logged in as "testing", create separate ids "testing1" testing2" and "testing3".

[MANOJ SRIVASTAVA]

Hi Omar

you may like to put ksh +o vi in the .profile to disable what you want.


Manoj Srivastava

[Wodisch · Accepted solution]

Hi again,

guys, be careful here: set +o vi
does NOT disable the history, it merely denies access to it via "ESC+k", but he asked for getting rid of the history, he might still want to have the vi-command-line editing functions, though...

Just my $0.02,
Wodisch

[harry d brown jr]

Omar,

If you are looking to give each user their own HISTFILE (.sh_history), then put this in /etc/profile, or in their local .profiles:


readonly HISTFILE="${HOME}/.sh_history_`date +%y%m%d.%H%M%S`.$$"
readonly HISTSIZE=50000
export HISTFILE HISTSIZE


live free or die
harry

[Omar Ghalib]

Thanks Everyone,

Indeed my dilema is that multiple users are using the same ID. The thing is we have UNIX administration outsourced to another company, I do not want any reference to any password in the history as I was passing a password on the command line.

I am trying to automate a password change process accross 17 HP-UX 10.20, 11.00, 11.11 servers. I am accomplishing this task using EXPECT and part of the process is updating a hidden doc. I was using "awk" and "sub", which exposed the passwords old and new.

I have managed a workaround by letting EXPECT interact with a vi of doc on the target host and issuing :%s followed by :wq!.

Thanks Again.

[Tim Woods_2]

Redirecting your history to /dev/null would do the trick, but as other have pointed out, it's a bad idea. If you've got Unix Administration outsourced, I think it would be a VERY bad idea.

From boxes I've seen that were hacked, hackers will usually redirect the history to /dev/null to hide their tracks. If you redirect it your admin company is sure to see it and this put them in a panic thinking you've been hacked. Once they find out what happened, they may raise hell about it because of the unecessary worry it may have caused them.

I don't think it would be advisable to do this.

[Graham Cameron_1]

The mind boggles.
If your unix admin is outsourced then the company providing the service must have root access in any case.
Thus they can su to any account and hiding passwords is futile.
If you don't trust them then the answer lies in the service and confidentiality agreements between your company and theirs.
There are products like Unix Privilege Manager http://www.passgo.com/products/upm/ which may help but it sounds like your problem is more fundamental.

[Andy Torres]

I've had some success using these entries in the user's .profile:

HOST=`who -u am i|awk '{print $8}'|awk -F : '{print $1}'`;export HOST

HISTFILE=$HOME/.sh_history.${HOST}; export HISTFILE

This ends up putting seperate histories for each user, as long as they log in from a different IP address/host.

... Just another $.02. :-)

[William C. Hermon]

Here is another $.02 worth... I have been in a similar situation several times, and found that setting the history file as follows tends to work pretty well when placed in the ~/.profile, or other auto-sourced file:
export HISTFILE=~/.sh_history-$$
The $$ becomes the process id. Hence, each unique process then maintains its own log file, and you avoid having multiple users accessing the same file. It does tend to result in a proliferation of history files, however, and a cron job may be needed to periodically reduce them to a reasonable number or size.