Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I accidentally typed my password into bash command line, mistaking the Last login: ... line for Wrong password (I was in a hurry). What do I do to cover my trace?

What I did was editing .bash_history and deleting the offending line (had to relogin once to see the password appear in the file so I could delete it, and relogin again to see it disappear from the history available under UPARROW key).

Is there any other place where the command history could be saved? The system is CentOS 6.5.

share|improve this question
Just change the password :) – gronostaj Apr 2 '14 at 7:18
Changing the password is not so simple... I'd need to ask the admin to reinstall my new public key on 15 different servers - and the guy is like /dev/null. – MaDa Apr 2 '14 at 8:39
If you can't change your password easily at any time, then you may have a serious security loophole. What will you do when someone actually gets your password? Do you have any means to immediately revoke system access? – gronostaj Apr 2 '14 at 13:57
You can change the passphrase of an ssh key without changing the key: ssh-keygen -f id_rsa -p. – jwg Apr 2 '14 at 14:21
Just dropping in to mention that, at least under networked Windows logins, you're hosed. The admin (in some lofty server tower) default is to record all login attempts, and of course the usernames are cleartext. All some enterprising person has to do is search for non-username-ish strings and correlate them with the next valid username (or next login attempt on the same machine). And there's no simple way to delete that admin log file. So ya really gotta change your password. – Carl Witthoft Apr 3 '14 at 14:31
up vote 151 down vote accepted

You can remove just the offending line from bash's history, instead of clearing the entire history. Simply remove the line with the -d flag, then save (write) the new history with the -w flag:

$ history
351 ssh
352 my_password
$ history -d 352
$ history -w
share|improve this answer

There are two parts to this:

  • bash stores the history in a file ~/.bash_history which is, by default, written to at the end of the session
  • the history that is kept in memory

To be safe, you need to clear it from the session:

history -c

and truncate the history file as needed:

> ~/.bash_history

If your session in which you typed the password is still open, then another way to cover your trace is to set the HISTFILE variable to the null device so that the history would not be written to ~/.bash_history when the session exits:

export HISTFILE=/dev/null
share|improve this answer
Hey look, it's the admin! – Raystafarian Apr 2 '14 at 14:19
Pun not intended, sorry :) I wasn't looking at your nick when I was writing my comment. – MaDa Apr 2 '14 at 23:43
To be paranoid (and yet for some reason still not change your password) shouldn't you shred the file or otherwise overwrite it many times? – kojiro Apr 3 '14 at 2:02
@MaDa No problem. I even added another way in the answer to bring my nick into the picture. – devnull Apr 3 '14 at 4:14
Setting HISTFILE= is enough. From bash(1): If unset, the command history is not saved when a shell exits. – Lekensteyn Apr 3 '14 at 9:16

Since bash (at least all historic and current versions I'm aware of) does not automatically save history until you exit, a generally applicable strategy when you have typed a command that you want to ensure never gets saved is to immediately type:

kill -9 $$

This kills the shell with SIGKILL, which can't be caught, so the shell has no way to save anything on exit.

Most other approaches involve scrubbing after the fact (i.e. after the data has already hit the disk), which has a lot more chance for error (missing a copy), especially if the system might be using btrfs or similar.

share|improve this answer
+1, not just more chance of error, it may even be recoverable depending on if/how many commands were executed after it – Cruncher Apr 2 '14 at 17:01
Missing the word "automatically"? Because dotancohen has shown a way to save the history without exiting the shell. – Ben Voigt Apr 2 '14 at 18:00
The shell can be configured to save history after each command is executed, instead of at exit. – Kundor Apr 3 '14 at 3:17
+1 This is exactly what I wanted to recommend! Besides rm ~/.bash_history~ to remove the backup file in the OP's case when it has been already saved – Tomas Apr 8 '14 at 7:23

After you accidentally typed something that you didn't want stored in the history, you can type: unset HISTFILE

Bash will not know where to store the history when you're logging off, so effectively this will disable history logging for the entire session.

share|improve this answer

My favorite trick for this is to hit the up arrow, backspace over the command, type something (might not be necessary), hit the down arrow, type "ls", and hit enter. Feels really hokey, but it actually works. Found this out when I got annoyed after editing the wrong command in my history and then ruining it by not hitting ctrl-c to abort the edit. I guess bash supports revisionist history. ;-)

$ passw0rd
$ <up arrow><backspace x8>cd<down arrow>echo hi
$ history|tail -3

Looks like:

$ passw0rd
passw0rd: command not found
$ echo hi
$ history|tail -3
 2445* cd
 2446  echo hi
 2447  history|tail -3
share|improve this answer
That's weird. One disadvantage is that it seems to know you edited history, so there might be some way to restore the old version? – MadTux Apr 6 '14 at 8:21
@MadTux - Totally, but the .bash_history is just a plain text file. So you can do the example above, exit, and reconnect. When you view the full contents of the .bash_history file, there's nothing there that differentiates it from if you had just run "cd", so the trail is clean. – Mark Jerde Apr 7 '14 at 18:36

Additional to the other answers, it may be relevant that the password is also found in the terminal scroll buffer - the history of displayed text - now, and, more of a problem, possibly on the hard disk, if the terminal emulator did save the history to the disk. This happens in KDE konsole it the history size is set to "unlimited scrollback", to never discard any output.

share|improve this answer

With $<space> command, a command is not added to the history, sometimes usefull

$  history | grep mywierdgrep
$ history | grep mywierdgrep
 2005  history | grep mywierdgrep
share|improve this answer
While interesting, it's not clear how this is useful in the scenario described. Are you suggesting that every password should start with a space? – Ben Voigt Apr 2 '14 at 17:59
No, what he's suggesting is that with this in place, any line you type that you don't want committed to the history, should be typed out with a leading space. eg: "ls" becomes " ls" and that line never shows in the history or in your sessions up-arrow list. – Bryan C. Apr 2 '14 at 18:05
Note that this leading-space trick works only if $HISTCONTROL contains ignorespace. – Bernd Jendrissek Apr 3 '14 at 1:35
@jris198944 Providing a password via a command-line argument could potentially expose it to anybody on the system who runs ps. – jamesdlin Apr 7 '14 at 3:58
And anyway, while this trick is useful if you're planning ahead, this doesn't help the original scenario where someone accidentally entered a password on a command-line. – jamesdlin Apr 7 '14 at 4:00

Yet another alternative to avoid saving to the history file (before you log out) is simply to chmod 444 ~/.bash_history and then logout. Login again and reset the permissions (or not, depending on how paranoid you are!).

share|improve this answer

You will want to check the syslog logs also. Invalid logins will generally be logged to syslog.

/var/log/messages or the equivalent for your OS.

share|improve this answer
The issue isn't that he entered a password in wrong, he was already logged in and entered his password into the prompt and hit enter. This will not show up in the messages file. – MaQleod Apr 5 '14 at 19:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .