I’ve touched on this subject previously, but suddenly felt I should repeat myself. The big issue with using passwords from command line is shell history.

Regardless of how careful you are, eventually you’ll enter a password in clear text in your terminal session. It will then end up in your shell history; very likely in the system log; probably on some remote syslog collector; possibly in some log management application like Splunk or Graylog; and, of course, in backups of all of the above.

When this happens and you’re fortunate enough to realize it, the responsible thing to do would be to change the password immediately. Unfortunately, as sysadmins we often work with service accounts. More often than not, such accounts have non-expiring passwords.

These passwords may be changed from time to time, but such a change is usually a scheduled activity involving multiple teams and carrying a possibility of a production outage. I know this may sound archaic, but only to people not familiar with how large corporate IT works.

This password might have been around for years, tucked away in some script or a batch job that everyone forgot about and that powers your company’s entire business. And the guy who wrote it was last seen alive in New Zealand in the nineties (true story).

So the idea is simple: put the important password inside a plain text file. Use GPG to encrypt the file and delete the original. Now to get the real password, you need the GPG password to decrypt this file.

Should the GPG password escape into the wild, no big deal: delete the encrypted file containing the important password and recreate it with a new GPG password. No need to change the atomic password. Probably.

I know, this is not brilliant, but it’s a hell of a lot better than nothing. GPG is probably already installed but, if not, just yum install gpg or apt install gpg. All you need to do now is:

And recalling the password is not difficult either:

Now the important password can be recalled as "${important_password}" in whatever script. Should some dumbass leak the encryption password, all you have to do is srm (secure rm) the encrypted file containing the important password and create a new one. It is unlikely there will be any need to change the important password.

So what else can we do with this? Well, this happens often to me: I log into some server and need to run a command that requires a password, an API key, an account number – something that is both sensitive and cannot be easily memorized. It would be nice to store this data in a file on the server for easy access. And many do just that, hoping that 400 permissions on that file is good enough security.

But there is a better way. Create a file in your home directory called, say, ~/.xconf containing “secret” variables and values. Pick a different field separator if ^ does not work for you:

Now you need to encrypt this file and get rid of the original:

The following lines you can either add to your ~/.bashrc or just put them in a script in your home folder, if you don’t want to set the variables every time you log in:

This will momentarily decrypt the ~/.xconf.pgp and assign values to the corresponding variables:

So now you have all this data handy without ever having to type any of it and risk exposing sensitive information from command line.