gnupg
First, to see if you already have a key:
gpg --list-keys
Generating a key can be rather some work, especially to generate random data.
gpg --gen-key
This command will ask for you to provide entropy which can be a real nuisance, consider installing rng-tools to help
Commands with rng-tools :
gpg-agent
gpg-agent is a daemon that runs as under use privileges and so can be configured with the file :
| conf | |
|---|---|
You can check if it reads this file by putting "error" inside it and:
| test correct file | |
|---|---|
This agent is run when you issue pass commands, and also devspace/docker commands if you use the pass-helper for it. It keeps on running after that so you could 'kill' it to get the password dialog popup again.
So the main setting i want to change is the timeout for the passwords. gpg-agent will put up a password dialog and then remember the password in-memory like ssh-agent would do. If you run it after 1 minute it won't ask for a password, if you do it after an hour (guess) it will !.
I want a longer timeout. But first let's test it with a shorter one :
| shorter cache | |
|---|---|
Now this does timeout after 40 seconds. But it seems it refreshes to 40 seconds again if you call pass again within that time
| try it | |
|---|---|
But if you run :
| output | |
|---|---|
So it stretches (probably by 40 seconds) every time you run pass. Now I just want a longer time, probably logging in once a day suffices. So make it 40000 (11+ hours)
You need to restart the agent because it only reads the config file at startup, killing it seems the only working way:
| kill and restart | |
|---|---|
vim plugin
Gnu privacy guard. This is an implementation of PGP but without the use of proprietary algorithms. GPG/PGP is normally used to communicate encrypted messages to a group of trusted people. In fact you build a database of public keys of those people, and encrypt messages with those keys, the recipients can then decrypt them using their own private key. password file
We use it mainly to have an encrypted password file that cannot be decrypted that easily. Admittedly if someone can get his hands on the password file, he is already on the system, and can also get the secret key. The only protection left is than the password with which the key is generated. Still it is better then plain text.
We use the vim plugin for gnupg that decrypts the file at opening and encrypts it again when saving it. This introduces a problem when the write permissions are not OK. The vim plugin does (correctly) not use a swap file but keeps the decrypted file in memory. If the person opening the file does not have the write permissions, the write fails and you are left with an empty file (although i'm still puzzled why you cannot write the file but you can empty it ??!). The last time we had this problem we got a sort of 'warning' : When saving the file you get this message:
| error | |
|---|---|
At this point you can still save the file in another shell. Don't bother to try ctrl-c or entering the id if you know it, all result in loss of the file !! alternative
We might think about a better alternative, preferably using gnupg because of the VIM plugin. That is because an intruder will probably take the effort of searching for interesting stuff and files with "gpg", (passwords.gpg might qualify as interesting;) extension are definitely worth the effort. One solution might be to name the password file something inconspicuous, like "/usr/miraculix/share/these_are_not_passwords" . Than every time you want to alter them copy this file back to your home directory as temp.gpg (which enables the vim plugin because of the extension), alter it and move it back again. This would also solve the problem mentioned above (the truncated password file) because the original file is still there and you only move a successful update back there.