I accidentally typed password into bash command line

Question

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.

Solution 1

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 [email protected]
352 my_password
$ history -d 352
$ history -w

Solution 2

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

Solution 3

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.

Solution 4

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.

Solution 5

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
hi
$ history|tail -3
 2445* cd
 2446  echo hi
 2447  history|tail -3
$ 

View more solutions

Comments

[gronostaj]

Just change the password :)

[MaDa]

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.

[gronostaj]

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?

[Excellll]

Possible duplicate: superuser.com/questions/173118/…

[Omar Shah]

You can change the passphrase of an ssh key without changing the key: ssh-keygen -f id_rsa -p.

[Nick Matteo]

Make sure that your editor didn't leave an auto-backup (often hidden) or somehow keep it in the editor's command history. Of course, all these places where it could be logged should only be readable by your user anyway.

[Ben Jackson]

This must be a duplicate, because I know I've commented on a question like this in the past admitting that this kind of thing is the #1 cause of me changing my password.

[Jonny]

I often write my password right next to my login id, because Enter didn't work... leaves my staring at the password prompt.

[Carl Witthoft]

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.

[Squeezy]

btw: You should be able to install a new SSH key on your own by using your old one.

[Matt]

@CarlWitthoft's comment, see: security.stackexchange.com/q/14907/9086

[mattdm]

Also: if at all possible, do not put ssh keys on remote hosts. Keep them on your client systems (ideally, one per device), and use agent forwarding as necessary.

[Raystafarian]

Hey look, it's the admin!

[Cruncher]

+1, not just more chance of error, it may even be recoverable depending on if/how many commands were executed after it

[Ben Voigt]

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]

Missing the word "automatically"? Because dotancohen has shown a way to save the history without exiting the shell.

[Bryan C.]

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.

[MaDa]

Pun not intended, sorry :) I wasn't looking at your nick when I was writing my comment.

[Bernd Jendrissek]

Note that this leading-space trick works only if $HISTCONTROL contains ignorespace.

[kojiro]

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?

[Nick Matteo]

The shell can be configured to save history after each command is executed, instead of at exit.

[devnull]

@MaDa No problem. I even added another way in the answer to bring my nick into the picture.

[jris198944]

You can use the space trick however you want. I use it sometimes if I type a password on the command line to test something, like $ mysql -u root -pmypasss mydb . Never thought of that, you could indeed start a password with a space.

[Lekensteyn]

Setting HISTFILE= is enough. From bash(1): If unset, the command history is not saved when a shell exits.

[o0'.]

@kojiro what would be the benefit of shredding, considering he is typing that password in that computer anyway? If the computer was compromised, there would be better ways to grab the password.

[kojiro]

@Lohoris indeed, what would be the benefit of shredding, wouldn't it be better to change the password?

[MaQleod]

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.

[MadTux]

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?

[TNW]

@Lekensteyn so why not just unset it, instead of setting it to any value?

[Lekensteyn]

@TNW I got used to typing HISTFILE= instead of unset HISTFILE (which is also a tiny bit longer). There is no specific reason for doing it this way.

[jamesdlin]

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.

[Mark Jerde]

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

[Tomas]

+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

[odigity]

Great reference: mewbies.com/how_to_disable_bash_history_or_limit_tutorial.ht‌​ml (I chose to use history -c after-the-fact.)

[benrifkah]

Be aware that this doesn't work if you've set "PROMPT_COMMAND=history -a". With this in place the command with your password is immediately written to your .bash_history when the prompt is displayed after the command terminates. You'll have to edit your .bash_history to remove it.

[benrifkah]

Be aware that this doesn't work if you've set "PROMPT_COMMAND=history -a". With this in place the command with your password is immediately written to your .bash_history when the prompt is displayed after the command terminates. You'll have to edit your .bash_history to remove it.

[benrifkah]

Be aware that this doesn't work if you've set "PROMPT_COMMAND=history -a". With this in place the command with your password is immediately written to your .bash_history when the prompt is displayed after the command terminates. You'll have to edit your .bash_history to remove it.

[benrifkah]

Be aware that this doesn't work if you've set "PROMPT_COMMAND=history -a". With this in place the command with your password is immediately written to your .bash_history when the prompt is displayed after the command terminates. You'll have to edit your .bash_history to remove it.

[benrifkah]

Be aware that if you've set "PROMPT_COMMAND=history -a" the command with your password is immediately written to your .bash_history when the prompt is displayed after the command terminates. You'll have to do something to your $HISTFILE directly in order to remove it regardless of what you do within the bash session.

[Samin yeasir]

@benrifkah: Is this a normal thing people do?

[benrifkah]

@R.. People use it to interleave commands from multiple open sessions into their history.

[Kamil Maciorowski]

Could you explain what exactly makes this method work?

[Floris Kruisselbrink]

The PROMPT_COMMAND is only executed before displaying the next command-prompt. The problem with entering the -d and -w commands on seperate lines is that the PROMPT_COMMAND will execute the history -a command in between. If you execute both the -d and -w on one commandline, it only executes afterwards

[anthony]

Also note that if the line was writen in the hostory file, and later multiple shells (terminal windows) had been opened, ALL those shells will have it in there history! You will need to either remove it from all of those shells, OR at least from the history LAST shell you close! Better to get it before the shell that used it exists. History when dealing with multiple shells can become a nightmare.

[anthony]

@benrifkah Doing just history -a is a nice idea, BUT you also need the shell to re-read that history too, that way if you have multiple shell (terminals) running they also will pick up the history. If you have such a system, let me know! history and multiple terminals are a PAIN!

[törzsmókus]

@benrifkah you saved my day. I knew this answer should work and it did not, I had no idea why. after unsetting PROMPT_COMMAND it worked as it should.