Tag Archives: Git

Managing passwords using GnuPG, Git and Emacs

Like any other security conscious and/or slightly paranoid computer geek I have lots and lots of unique and nontrivial passwords to keep track of.  My solution to this problem involves having one GnuPG encrypted text file per username/password pair.

andreas@stilgar:~/safe$ gpg < example.gpg

You need a passphrase to unlock the secret key for
user: "Andreas Olsson <andreas@arrakis.se>"
4096-bit RSA key, ID 9A943D4A, created 2010-07-11 (main key ID 13CD4F59)
  Here gnupg-agent calls pinentry-gtk2 to prompt me for the passphrase
gpg: encrypted with 4096-bit RSA key, ID 9A943D4A, created 2010-07-11
      "Andreas Olsson <andreas@arrakis.se>"

https://127.0.0.1/

username: sigge
password: sigge

andreas@stilgar:~/safe$

As I need to have access to those passwords on more than one computer I use Git, and a remote repository, to keep my encrypted files in sync. Other options might be to mount a SFTP folder using SSHFS, or to simply put the files in your Dropbox. Yet, if you too decide to go with Git, here is a .gitignore you might want to use.

andreas@stilgar:~/safe$ cat .gitignore
*
!*.gpg
!.gitignore
andreas@stilgar:~/safe$

Thanks to Emacs and EasyPG it is a breeze to  create new GnuPG encrypted text files, as well as to modify existing ones. Just use the file extension .gpg, and EasyPG will do its thing. The first time, when you actually create the file, you will be prompted for which public keys you want to encrypt against.

andreas@stilgar:~/safe$ emacs yet_another_example.gpg

(EasyPG is included in Emacs 23, and don’t need to be installed separately.)

Do note that this method also works when there are multiple people involved. Just make sure that the intended users have access to the share/repository in question, and that their public keys are included when you create the GnuPG files.

Server configuration and version control

One of the (few?) good habits I managed to pick up during 2010 was that I became serious about keeping server configuration under version control. While it might primarily have been something I was taught at work it is definitely a practice I have adopted privately as well.

The most obvious benefit, and potentially the most valuable one, is the historic record version control provides. Yet, the part I appreciate most is how easy it becomes to compare new configuration against current one; to verify that you only made  just those changes which you  intended to make. There is a certain comfort in being able to run a git diff before restarting a local service or before pushing new cluster configuration.

(Not that I do not appreciate having access to the configuration history. When being asked about something which happend a few months ago, those commit messages and those diffs becomes awful handy.)

For your local /etc this is as a good time as any to take a peak at etckeeper.