DEV Community

Edvinas Pranka
Edvinas Pranka

Posted on

Hide the exported ENV variables from the history

Hi, happy to join your community. This is my first post, so I start from the simple one, but useful. Maybe you don't know about it yet.

When you work with the Linux server, sometimes you export some environment variables. Some envs can be neutral like NODE_ENV=production or something else, but sometimes it must be safe like GITHUB_API_KEY or MYSQL_PASSWORD.

The problem is if anyone accesses the server bash and enters the history command it will see the secrets:

...
1989  export MYSQL_PASSWORD=my_secret_mysql_password
...
2000  history
Enter fullscreen mode Exit fullscreen mode

To be safe, before working with the bash, export Linux history control environment variable which is called HISTCONTROL.

$ export HISTCONTROL=ignorespace
Enter fullscreen mode Exit fullscreen mode

ignorespace means that if you leave the space before any bash command, it will be ignored in history.

So while exporting the secret environment variable, enter the space before export

$ export HISTCONTROL=ignorespace
# keep in mind space before export
$  export MYSQL_PASSWORD=my_secret_mysql_password
$ history
Enter fullscreen mode Exit fullscreen mode

So now, the Mysql password will be ignored in history

...
1999  export HISTCONTROL=ignorespace
2000  history
Enter fullscreen mode Exit fullscreen mode

This method is not only for environment variables, but it can also hide any bash command, even export HISTCONTROL=ignorespace itself.

Good luck and be safe! :)

Top comments (9)

Collapse
 
franky47 profile image
François Best • Edited

You can also use the clipboard, via pbpaste on macOS and xclip on Linux (not sure how to do that on Windows).

Example:

# Copy your NPM deploy token to clipboard, then:
$ travis encrypt $(pbpaste) --add deploy.api_key --com
Enter fullscreen mode Exit fullscreen mode

Then if you call history, you only get

$ history
travis encrypt $(pbpaste) --add deploy.api_key --com
Enter fullscreen mode Exit fullscreen mode

It works wonders for injecting secrets copied from a web browser (tokens, API keys, obtained from an admin panel) in the environment without revealing anything.

Collapse
 
epranka profile image
Edvinas Pranka

Intresting, thanks!

Collapse
 
jmvallejo profile image
Juan Manuel Vallejo

Thanks for this! It’s what I was looking for

Collapse
 
ferricoxide profile image
Thomas H Jones II
alias logout="history -c && exit"
Enter fullscreen mode Exit fullscreen mode

?

Kidding aside, you're on the right track with histignore, you just want to expand on it. You can specify multiple patterns to histignore by colon-separating each pattern. Thus, you could do:

histignore=" :export *"
Enter fullscreen mode Exit fullscreen mode
Collapse
 
epranka profile image
Edvinas Pranka

Clear the history before the logout, is geniuous, thanks :D

Collapse
 
ferricoxide profile image
Thomas H Jones II • Edited

Yeah, but might piss off your IA guys. Some security-orgs see that a sign of nefarious motives (sinçe you're "trying to hide history").

That said, in addition to configuring filtered recording of history with a multi-pattern histignore definition, a couple other tricks I've used over the year have been:

Set up your ${HOME}/.<SHELL_INIT> file to try to store its history in either /dev/null, or something like /tmp/.$( tty | sed 's#/.*/##' ).${LOGNAME}:

  • Former means no history gets recorded
  • Latter means that each user gets a discreet history file (useful if you might have multiple, concurrent account-users creating history) ...and that their history goes *poof!* if your OS is configured to either regularly expire files from /tmp or /tmp is on tmpfs.

Another useful thing (when you want to keep history), is to set HISTTIMEFORMAT='%F@%T '. Doing so means that your history is time-stamped so that you know when an action was executed (useful for correlating with logs in case you need to figure out who screwed something up)".

Collapse
 
sebbdk profile image
Sebastian Vargr

You have to put those somewhere, a system users env variables should be a good safe place afaik.

But in case they aren’t, maybe there’s some key managers out there, or you could keep them outside env variables and instead input the keys via terminal commands in your CI/deployment-system?

Collapse
 
epranka profile image
Edvinas Pranka

I often face the situation than I just need to login via SSH to the client server and do some quick Mysql queries or something similar, so I have to disappear without any clues :D

Collapse
 
sebbdk profile image
Sebastian Vargr

It might be me being drunk on a Thursday, but those kinda practices has gotten me in trouble before :D