As a seasoned Linux system administrator, one of the security basics you learn early on is controlling what goes into your shell history. Bash, the default shell on most Linux distributions, by design records every command you execute in a history file. Unfortunately, this often includes sensitive data such as passwords, API tokens, or secret keys typed directly in the command line. This can lead to serious security risks, especially on shared or production servers where multiple administrators have access. In this detailed tutorial, I’ll walk you through practical and reliable methods to keep passwords and other sensitive information out of your Bash history. By adopting these techniques, you’ll reduce your attack surface and avoid unintentional data leaks through command logs.

Understanding How Bash History Works and Why It Matters

Before diving into solutions, it’s crucial to grasp when and how Bash writes commands to the history file. Every command you execute is first stored in an in-memory list during your shell session. Normally, when you cleanly log out or close the terminal, Bash appends these commands to your history file, typically ~/.bash_history. If your session crashes, commands from that session are lost in history because they weren’t flushed to disk.

echo $HISTFILE $HISTSIZE $HISTFILESIZE

/home/username/.bash_history 1000 2000

This command shows three important environment variables: HISTFILE points to the file where Bash stores history, HISTSIZE controls how many commands Bash keeps in memory per session, and HISTFILESIZE determines the max number of commands saved on disk. Defaults in many distros are 1000 in-memory and 2000 stored commands on disk. Knowing that history is first built in memory helps understand why some commands might not appear if the session is killed abruptly, but also why changes to in-memory history can be made and saved or discarded.

In real production environments, overlooking this memory-to-disk behavior might cause surprise when trying to remove sensitive commands post-facto. It explains why you should also control what gets added in real-time and how to edit history safely.

Simple Trick: Using Leading Space to Avoid History Logging

Bash has a neat built-in feature controlled by the HISTCONTROL variable. If it’s set to ignorespace or ignoreboth (which combines it with ignoring duplicates), any command you type with a leading space won’t get saved in the history. This is by far the easiest way to avoid logging sensitive commands on-the-fly.

echo $HISTCONTROL

ignoreboth

If you don’t see ignorespace or ignoreboth, add this line to your ~/.bashrc file:

export HISTCONTROL=ignoreboth

After editing ~/.bashrc, remember to reload it with:

source ~/.bashrc

From now on, prefix your sensitive commands with a space: for example, curl -u user:password https://api.example.com typed as curl -u user:password https://api.example.com (with a space in front) will not be logged. This method is practical because it requires no complex configuration and is easily remembered once you get into the habit.

How to Remove Sensitive Commands You Already Ran From History

Sometimes, you notice after the fact that you accidentally ran a command with sensitive info saved into history. Bash allows you to delete individual entries from the in-memory history list by using the history command with the -d flag and the line number of the command to remove.

history | tail -20

498  ls -la /var/log
499  echo "password=supersecret"

To delete the sensitive command at line 499, run:

history -d 499

This removes the entry from your current session’s memory list, but you must write the updated list back to the ~/.bash_history file to permanently remove it from the disk. To do so immediately, use:

history -w

This writes the current in-memory history to your history file, overwriting it. Without doing this, when your session exits normally, the file will be overwritten anyway, but any manual interventions like history -a before exit can cause your deleted commands to reappear. This two-step approach is handy when you urgently need to scrub sensitive entries without waiting for logout.

Advanced: Ignore Patterns Using HISTIGNORE for Sensitive Command Types

For administrators who frequently run commands involving sensitive data, manually using leading spaces can be error-prone. That’s where HISTIGNORE shines. It lets you specify patterns of commands that should never be recorded in history. It supports colon-separated glob patterns, so you can exclude commands like export * to avoid saving environment variable exports that may contain credentials or tokens.

export HISTIGNORE='export *:curl *:sudo *'

Adding this line to your ~/.bashrc will persist these exclusions across sessions. Use this judiciously because ignoring sudo * will omit privileged command history, which is often useful for audits. Instead, consider excluding only specific commands that are known risks.

In real-world setups, many admins incorporate common secret-managing commands here — particularly those involving AWS CLI, kubectl, or curl with headers.

Disable History Logging for Entire Sessions When Necessary

There are cases when you want zero trace of any commands in a session — for example, during incident response or when setting credentials on a sensitive server. The simplest way to achieve this is by pointing HISTFILE to /dev/null:

export HISTFILE=/dev/null

This effectively discards all commands on logout because Bash tries to write history to a black hole. The in-memory list still accumulates as usual, so you can navigate command history during that session but no permanent record is saved. Alternatively, you can use:

unset HISTFILE

However, exporting HISTFILE=/dev/null is preferred for portability and predictability. I’ve seen this approach used in restricted shells or temporary recovery sessions.

Best Practices for Managing Bash History in Multi-Admin Environments

Managing command history isn’t just about hiding passwords; it’s part of maintaining operational hygiene. Here are a few practical tips based on years of managing production Linux systems:

  • Set HISTCONTROL=ignoreboth globally: This avoids clutter from duplicates and accidental leading-space mistakes.
  • Define meaningful patterns in HISTIGNORE: Exclude commands known to carry secrets while preserving audit trails for critical administrative actions.
  • Encourage using environment variables or config files: Instead of embedding secrets directly in commands, use exported environment variables or dedicated config files with restrictive permissions.
  • Clear history or rotate it periodically: Use history -c and history -w or cron jobs to scrub old history files if sensitive commands were logged.
  • Educate your team: Make the leading space habit or other history-sanitizing habits standard practice in your teams.

Troubleshooting Scenario: Removing a Compromising Password From Shared Server History

In one incident I handled, a junior sysadmin accidentally ran a mysql login command with the root password visible on a shared production server. This password was stored in the global .bash_history file accessible by all admins. Immediate damage control involved:

  1. Asking the junior admin to log out without exiting the session prematurely.
  2. Using history with -d to delete the unsafe command from the current session.
  3. Writing the cleaned history back with history -w to ensure the password was removed from the file.
  4. Resetting the compromised MySQL root password urgently to mitigate unauthorized access risks.
  5. Implementing HISTCONTROL=ignoreboth across all user shells and adding the common mysql login pattern to HISTIGNORE.

This incident reinforced the importance of proactive history management and the risks of storing plaintext secrets in shell commands.

Conclusion

Keeping passwords and sensitive data out of Bash history is an essential security practice every Linux system administrator should master. From the simple leading-space trick governed by HISTCONTROL, to selective command pattern exclusions with HISTIGNORE, plus manual history cleanup using history -d and writing back changes with history -w, you have multiple tools at your disposal. For ephemeral sessions requiring zero traces, point HISTFILE to /dev/null. In day-to-day operations, standardizing these practices minimizes inadvertent information exposure and keeps your server environments safe and clean.

Start by adding export HISTCONTROL=ignoreboth and thoughtful HISTIGNORE patterns in your ~/.bashrc today. Your future self—and your team—will thank you for the improved security hygiene.