I accidentally typed password into bash command line

190

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.

MaDa

Posted 2014-04-02T06:42:06.727

Reputation: 1 843

59Just change the password :) – gronostaj – 2014-04-02T07:18:39.510

96Changing 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 – 2014-04-02T08:39:22.080

71If 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 – 2014-04-02T13:57:04.217

Possible duplicate: http://superuser.com/questions/173118/removing-previously-type-commands-at-a-remote-server

– Excellll – 2014-04-02T14:17:45.240

42You can change the passphrase of an ssh key without changing the key: ssh-keygen -f id_rsa -p. – jwg – 2014-04-02T14:21:20.237

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. – Nick Matteo – 2014-04-02T16:09:49.777

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. – Ben Jackson – 2014-04-02T20:31:22.793

2I often write my password right next to my login id, because Enter didn't work... leaves my staring at the password prompt. – Jonny – 2014-04-03T04:44:30.377

6Just 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 – 2014-04-03T14:31:25.327

btw: You should be able to install a new SSH key on your own by using your old one. – Squeezy – 2014-04-03T20:18:26.687

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

– Matt – 2014-04-04T18:28:09.983

1Also: 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. – mattdm – 2014-04-05T07:05:20.037

Answers

186

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 me@site.com
352 my_password
$ history -d 352
$ history -w

dotancohen

Posted 2014-04-02T06:42:06.727

Reputation: 9 798

1Be 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 – 2017-08-31T17:20:30.947

1Also 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 – 2019-07-02T01:41:19.263

120

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

devnull

Posted 2014-04-02T06:42:06.727

Reputation: 2 987

Great reference: http://mewbies.com/how_to_disable_bash_history_or_limit_tutorial.html (I chose to use history -c after-the-fact.)

– odigity – 2015-01-20T06:38:23.303

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. – benrifkah – 2017-08-31T17:29:28.840

@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! – anthony – 2019-07-02T01:45:36.813

205Hey look, it's the admin! – Raystafarian – 2014-04-02T14:19:36.430

5Pun not intended, sorry :) I wasn't looking at your nick when I was writing my comment. – MaDa – 2014-04-02T23:43:53.733

7To 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 – 2014-04-03T02:02:52.603

1@MaDa No problem. I even added another way in the answer to bring my nick into the picture. – devnull – 2014-04-03T04:14:03.457

5Setting HISTFILE= is enough. From bash(1): If unset, the command history is not saved when a shell exits. – Lekensteyn – 2014-04-03T09:16:03.820

@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. – o0'. – 2014-04-03T13:18:11.253

@Lohoris indeed, what would be the benefit of shredding, wouldn't it be better to change the password? – kojiro – 2014-04-03T13:21:27.963

@Lekensteyn so why not just unset it, instead of setting it to any value? – TNW – 2014-04-06T20:40:22.237

@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. – Lekensteyn – 2014-04-06T20:54:27.383

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.

R.. GitHub STOP HELPING ICE

Posted 2014-04-02T06:42:06.727

Reputation: 1 783

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 – 2017-08-31T17:19:15.140

@benrifkah: Is this a normal thing people do? – R.. GitHub STOP HELPING ICE – 2017-08-31T17:30:33.993

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

– benrifkah – 2017-08-31T17:38:52.370

2+1, not just more chance of error, it may even be recoverable depending on if/how many commands were executed after it – Cruncher – 2014-04-02T17:01:27.737

Missing the word "automatically"? Because dotancohen has shown a way to save the history without exiting the shell. – Ben Voigt – 2014-04-02T18:00:55.950

3The shell can be configured to save history after each command is executed, instead of at exit. – Nick Matteo – 2014-04-03T03:17:59.063

1+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 – 2014-04-08T07:23:24.963

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.

mtak

Posted 2014-04-02T06:42:06.727

Reputation: 11 805

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
$

Mark Jerde

Posted 2014-04-02T06:42:06.727

Reputation: 111

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 – 2014-04-06T08:21:20.573

@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 – 2014-04-07T18:36:24.980

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.

Volker Siegel

Posted 2014-04-02T06:42:06.727

Reputation: 1 188

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

$  history | grep mywierdgrep
$ history | grep mywierdgrep
 2005  history | grep mywierdgrep

jris198944

Posted 2014-04-02T06:42:06.727

Reputation: 167

2While 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 – 2014-04-02T17:59:46.363

1No, 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. – 2014-04-02T18:05:46.877

4Note that this leading-space trick works only if $HISTCONTROL contains ignorespace. – Bernd Jendrissek – 2014-04-03T01:35:25.100

1You 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. – jris198944 – 2014-04-03T08:25:35.083

2@jris198944 Providing a password via a command-line argument could potentially expose it to anybody on the system who runs ps. – jamesdlin – 2014-04-07T03:58:19.330

2And 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 – 2014-04-07T04:00:11.033

Yet another alternative to avoid saving to the history file (before you log out) is simply to

chmod 400 ~/.bash_history

and then logout. Stop history being written to file (since the file is read-only) so that whole bash session is discarded and the previous history retained.

Adam

Posted 2014-04-02T06:42:06.727

Reputation: 141

I see repeatedly mentioned

Be aware that this doesn't work if you've set "PROMPT_COMMAND=history -a" [..] You'll have to edit your .bash_history to remove it.

The first part is definitely true, but you don't have to resort to manually editing .bash_history to fix it. If you combine the two commands on one line it works perfectly fine:

$ history
351 ssh me@site.com
352 my_password
$ history -d 352 ; history -w

Floris Kruisselbrink

Posted 2014-04-02T06:42:06.727

Reputation: 11

Could you explain what exactly makes this method work? – Kamil Maciorowski – 2017-12-07T14:49:53.187

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 – Floris Kruisselbrink – 2017-12-08T10:42:46.273

Many of the answers here attempt to remove the command in question from the curren't bash session's history before it is written to $HISTFILE (~/.bash_history by default). However, if you've set PROMPT_COMMAND=history -a the command with your password is immediately written to your $HISTFILE when the prompt is displayed after the command terminates. You'll have to edit your $HISTFILE to remove it.

This setting is commonly used to interleave commands from multiple open bash sessions.

benrifkah

Posted 2014-04-02T06:42:06.727

Reputation: 163

-3

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.

bcarroll

Posted 2014-04-02T06:42:06.727

Reputation: 101

1The 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 – 2014-04-05T19:33:29.347