I am trying to setup a, business internal, password storage to be used by various scripts (and people). I have looked at many alternatives but the easiest to modify to achieve my goal seems to be the pass utility.

I am not that good with security and a real noob when it comes to GPG. I have managed to make things working for a single user by:

  • Generating a new GPG key
  • using pass init <key_hex>

I also know I can use -p option (or an env variable) to initialize the pass storage in a "data" folder rather than a home directory (defaults to ~/.password-store).

However, I am in a situation that I would like all users of a (Linux) host/box (or users of a specific group later) to be able to access the same password-store. To my understanding, I need to somehow create a shared GPG key for all these users so each one can use the pass utility to access the same store and retrieve passwords. I have no clue how to do such a setup and I am kinda stuck...

Any help would be appreciated

  • Password storage to be used by scripts? Sounds like the XY problem. meta.stackexchange.com/a/66378/307622 Why do you want multiple users to access the same password store? – Wildcard Oct 19 '15 at 8:20
  • Hi @Wildcard, this is a common problem (I think) in a NOC. Lots of scripts around for various jobs but there are the rules: (1) No hard-coding passes, (2) Never, ever clear-text passes (anywhere other than memory - no files, no cmd line, not on the wire). Therefore a mechanism is required to be able to say "give me cisco ro community". Some times a user runs the script/tool... so we can ask... but other times it is a CRON based thing. I mention internal cause it does not need to be bullet-proof - it is a heavily fire-walled network. Any directions/ideas will be good – urban Oct 19 '15 at 10:58
  • Another thing to clarify is that I will have to modify the utility to do group-based access, syslog, pass roll-outs, etc to much the business needs. So pass seems to me the most flexible tool (might be wrong) – urban Oct 19 '15 at 11:01
  • 2
    I am sure the answer is in subkeys ... but I have used different software for this here which is based on python and keepassdb – urban Mar 9 '16 at 13:32

Multiple gpg-ids can be added to the .gpg-id file to encrypt each password in the directory. Doing so would allow a shared password store among various members without needing to hand the private key to everyone.

It is also possible to create sub-directories with differing sets of gpg-ids if it makes sense to do so.

See man pass under the init section for more details.

Here is an excellent article that outlines the process: https://medium.com/@davidpiegza/using-pass-in-a-team-1aa7adf36592

Hope this helps.


In order to avoid sharing a private key, which are not really their purpose, you may want to take a look at the relatively new gopass alternative to pass, which is compatible with passand allows you to support multiple recipients natively, while enforcing a git-based work-flow.

It is open-source, go based, and available on Github.

It sports the following features you may currently lack when using pass in a multiple users environment:

  • git auto-push & auto-pull, to never miss a change.
  • multi-stores that can be mounted over each other like file-systems on Linux/UNIX systems
  • list, add and remove recipients from the command line
  • store the public gpg keys in a key folder in the password store
  • fully compatible with git pgp signed commits

This is really interesting when working in a team to share passwords.

It's just like pass, which means it's using gpg, it's storing the passwords in the same format as pass, on the first line of the .gpg files, etc.

The normal workflow with gopass would be as follows:

  1. a user setup the password-store (or take a pass one) and add each recipients to it.
  2. the user share the password-store on a commonly accessible git repository (if possible on an internal git server, but since everything is encrypted you may store it on external server as well, just keep in mind that the structures and names of your entries are exposed.)
  3. everybody works with his very own private key to decrypt the data, which are then rencrypted with everybody's public keys on changes.

What's nice is that every commit to your password-store can be signed through git, it's compatible with PGP smartcards, like pass, and if you've already used Go in your life, it's easy to tweak it the way you want. The code comes with extensive unit tests and good enough documentation.

In your specific case, it should work fairly well. You may even avoid completely remote git servers and simply store it in a common folder.


Each user will have access to pass, and will do a pass init to that directory, with a GPG key present in their keychain ( A second one rather that their own )

First, make sure your pass store is initilized with git.

Add the passwords you need. Commit and push to a repo accessible by all users.

Then each user will clone this git repo containing yours encrypted password (but not the GPG key )

You can spread your GPG key with:

gpg --export-secret-key -a "User Name" > private.key

And then importing it for each user

gpg --allow-secret-key-import --import private.key

Finally each users will init is own pass repo with the shared GPG key-id

init [ --path=sub-folder, -p sub-folder ] gpg-id...

You can get the key-id with

gpg --list-keys 

NB: You have to think about the logistic of sharing private keys.

I'm quoting scout3801@gmail.com on this good cheat sheet about GPG

Use Case *.2 : Mentioned above were the commands for exporting and importing secret keys, and I want to explain one reason of why maybe you'd want to do this. Basically, if you belonged to a group, and wanted to create a single key-pair for that group, one person would create the key-pair, then export the public and private keys, give them to the other members of the group, and they would all import that key-pair. Then a member of the group or someone outside could use the group public key, encrypt the message and/or data, and send it to members of the group, and all of them would be able to access the message and/or data. Basically you could create a simplified system where only one public key was needed to send encrypted stuffs to muliple recipients.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.