I just found the command 'history' which gives the last 1000 command I enter in a shell. Let's say I'm not the admin and I don't want him to see what I try to do, how do I delete the history? I deleted the file /home/yanik/.bash_history but when I run the command history after that, the first command is rm .bash_history!!!! dammit! lol . I though I could do a little script that would execute something like ls a thousand time, which seems to work, but is there a cleaner way? Because it is still suspicious to ls the same dir 1000 time lol.

Anyway to have some privacy?

Yanik

zero-byte it then change it's permissions I guess? There's probably a neater setting for it somewhere.

history -c clears the history
I set my .bash_logout to do this every time I logout. I have mine to clear, rm -rf .bash_history, and then history -c
keep it last so nothing's really seen

lol, that's just great, thanks guys

Just to add a little to the history discussion. The environment variable HISTSIZE will allow you to adjust the number of commands kept in history.

Bill

Let's say the admin want's to see what you're doing, and you want to stop him. You think you can actually do that?! You would probably only succeed in raising a big 'ol red flag for your efforts, if you have a sharp sysadm. People who try to hide what they're doing (should) raise suspicions. You might end up having yourself watched keystroke by keystroke via ttysnoop or some other such tool.

seems like this is his own system he's messing with, but I agree entirely if it's not his system.
You will definitely just raise a red flag on yourself, there are many other ways that admins can watch you keystroke for keystroke. clearing the history would only do any good to someone connecting to your machine and using it for malicious purposes. then it wouldn't do a *lot*

Why would you ever need to clear your history? Its so useful...

no it's not on my system, and I guess you are all right. I'll mess at home on my system instead of trying to be a smart ass at work

How about instead of removing it, you simply alter it?

A good way to alter it w/o the altering itself being recorded, is setting up a crontab entry.

Pick commands you don't want them to know you're doing, and have them sub'd for basic commands like "ls" or "cd"

You may want to use perlpie for this:

*/5 * * * * /usr/bin/perl -pi -e "s/command1/command2/g" ~/.bash_history

There are other ways to make this less obvious as to what you are doing, like writting a c program using system() calls to the shell, or a perl script compiled with perlcc

-Corey

Best solution IMHO (and the easyest) is to symlink .bash_history with /dev/null .

Or how about the crontab checks to see if .bash_history is a symlink, and if not, removes it and makes it a symlink to /dev/null

That way if the admin find out about the symlink, you can really piss em off

-Corey

Good idea. But what about admin EDITING YOUR CRONTAB? Nothing is impossible tough.

Then you've got an admin who has atleast half-a-brain. I've seen plenty of server "admins" who don't know jack about what they are doing, and the crontab trick usually stumps them.

Anyway, another trick to get around this is to have a background process running that sits there and checks your crontab. If it changes, it puts it back. And have the process ignore all signals to make it hard to kill.

Of course there is a way for the admin to get rid of that, but there comes a point where it is he who knows more, being the one who comes out on top.

And the final question is: is having your .bash_history file not recording your history really THAT important?

I guess we'll never know.

-Corey

I guess if you have a sysadm as green as the ones cormander has been blessed(?) with, it doesn't really matter if you hide your shell history or not. They'd be too inexperienced to locate even those files! acctcom, /var/cron/log, PAM, and all kinds of other places can turn up tons of detail on your activities. Tracking down an experienced cracker who has already gained root access can be tough. But routine users ... not really much of a problem. Excepting the flailing efforts of a totally inexperienced sysadmin as cormander points out, but that's a different issue.