Using Password Store
Password Store (aka “pass”) is a very handy wrapper for dealing with pgp encrypted secrets. It greatly simplifies securely working with multiple secrets. This is still true even if you happen to keep your encrypted secrets in non-password-store managed repositories, although that setup isn’t covered in the docs. I’ll show my setup here. (See the Password Store page for usage: “pass show -c <spam>” & “pass search <eggs>” are among my favorites.)
- Short version:
Have gpg installed on your machine.
Install Password Store on your machine. There are OS specific instructions. Be sure to enable tab completion for your shell!
Setup a local password store. Scroll down in the usage section to “Setting it up” for instructions.
Clone your secrets repositories to your normal location. Do not clone inside of ~/.password-store/.
Set up symlinks inside of ~/.password-store/ to directories inside your clone of the secrets repository. I did:
ln -s ~/path/to/secrets-git/passwords rePasswords ln -s ~/path/to/secrets-git/keys reKeys
Enjoy command line search and retrieval of all your secrets. (Use the regular method for your separate secrets repository to add and update secrets.)
Rationale:
- By using symlinks, pass will not allow me to create or update secrets in the other repositories. That prevents mistakes, as the process is different for each of those alternate stores.
- I prefer to have just one tree of secrets to search, rather than the “multiple configuration” approach documented on the Password Store site.
- By using symlinks, I can control the global namespace, and use names that make sense to me.
- I’ve migrated from using KeePassX to using pass for my personal secret management. That is my “main” password-store setup (backed by a git repo).
Notes:
- If you’d prefer a GUI, there’s qtpass which also works with the above setup.
Decoding Hashed known_hosts Files
tl;dr: You might find this gist handy if you enable HashKnownHosts
Modern ssh comes with the option to obfuscate the hosts it can connect to, by enabling the HashKnownHosts option. Modern server installs have that as a default. This is a good thing.
The obfuscation occurs by hashing the first field of the known_hosts file - this field contains the hostname,port and IP address used to connect to a host. Presumably, there is a private ssh key on the host used to make the connection, so this process makes it harder for an attacker to utilize those private keys if the server is ever compromised.
Super! Nifty! Now how do I audit those files? Some services have multiple IP addresses that serve a host, so some updates and changes are legitimate. But which ones? It’s a one way hash, so you can’t decode.
Well, if you had an unhashed copy of the file, you could match host keys and determine the host name & IP. [1] You might just have such a file on your laptop (at least I don’t hash keys locally). [2] (Or build a special file by connecting to the hosts you expect with the options “-o HashKnownHosts=no -o UserKnownHostsFile=/path/to/new_master”.)
I through together a quick python script to do the matching, and it’s at this gist. I hope it’s useful - as I find bugs, I’ll keep it updated.
Bonus Tip: https://github.com/defunkt/gist
Is a very nice way to manage gists from the command line.
Footnotes
| [1] | A lie - you’ll only get the host name and IP’s that you have connected to while building your reference known_hosts file. |
| [2] | I use other measures to keep my local private keys unusable. |