31

I'm using the pass for quite a long time; but after exporting my key storage and gpg keys to another machine I see following output:

$ gpg --list-key
/home/shved/.gnupg/pubring.gpg
------------------------------
pub   2048R/FA829B53 2015-04-28
uid       [ultimate] Yury Shvedov (shved) <[email protected]>
sub   2048R/74270D4A 2015-04-28

My key imported and trusted, but not usable:

pass insert test
Enter password for test: 
Retype password for test: 
gpg: 2048R/FA829B53: skipped: No public key
gpg: [stdin]: encryption failed: No public key
fatal: pathspec '/home/shved/.password-store/test.gpg' did not match any files

What can I do to use my key again?

Improve this question

5 Answers 5

Reset to default
18

pass uses gnupg2, which does not share it's keyring with gnupg 1.x.

Import your keys again using gnupg2 instead of gnupg. If you already have your keys in gnupg on the target machine run:

$ gpg --export-secret-keys > keyfile
$ gpg2 --import keyfile

After importing, you may need to update the trust on your key. You should see a Secret key is available. message if the import was successful:

$ gpg2 --edit-key FA829B53
[...]
Secret key is available.

sec  rsa4096/FA829B53
     created: 2015-03-14  expires: 2017-03-13  usage: SC  
     trust: unknown      validity: ultimate
ssb  rsa4096/74270D4A
     created: 2015-03-14  expires: 2017-03-13  usage: E   
[ultimate] (1). Yury Shvedov (shved) <[email protected]>

Now update the trust on your key:

gpg> trust
[...]
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
[...]
gpg> save
Improve this answer
4
  • pass (at least version 1.6.3) uses gpg not gpg2. And gpg2 is just a redesign. Only with version 2.1 did some changes come (combining public and private keys in the public keyring.
    – Anthon
    Sep 27, 2015 at 13:10
  • That is not true for my version (1.6.5). From the source code: 10 GPG="gpg" 11 export GPG_TTY="${GPG_TTY:-$(tty 2>/dev/null)}" 12 which gpg2 &>/dev/null && GPG="gpg2" 13 [[ -n $GPG_AGENT_INFO || $GPG == "gpg2" ]] && GPG_OPTS+=( "--batch" "--use-agent" ) This implies that 'pass' uses gpg unless gpg2 is present on the same system.
    – Łukasz Lis
    Sep 27, 2015 at 20:46
  • 1
    so it uses gpg unless gpg2 is installed and for the purposes of pass these are compatible, otherwise you would get horrible problems if you happen to install gpg2 some time after you started to use pass (which you shouldn't in the first place as it sometimes leaves unencrypted data in your "storage" directory).
    – Anthon
    Sep 27, 2015 at 21:36
  • First, this is not what you argued in your first reply. Second, you've not replied to my point about them not sharing a keyring. Third, they are only compatible in that both can decrypt messages if given a proper secret key.
    – Łukasz Lis
    Sep 28, 2015 at 6:25
9

Output line 

gpg: 2048R/FA829B53: skipped: No public key

shows a wrong pass initialization. You initialized pass with the command pass init 2048R/FA829B53 whereas you should do it with the command pass init FA829B53. To solve the problem you should change the content of the file ~/.password-store/.gpg-id from 2048R/FA829B53 to FA829B53 and commit changes.

PS

All @Łukasz Lis advises are correct and you should complete them too. In other case you won't be able to decrypt the pass:

$ pass -c test

will give you an error: gpg: decryption failed: No secret key

Improve this answer
1
  • Useful. It can happen to (mis-)type pass init SomethigElseThanFirstStore.
    – Nikos Alexandris
    Jan 5, 2018 at 12:37
0

I noticed this when creating a new store and initialized it with a key id like "2048R/FA829B53" which I thought was how it was done in the past, and looking at an old backup the .gpg_id is different.

However, now it seems just the FA829B53 is used, and in the current man pages the author uses his email address.

I'd check the gpg_id file, for me in a fresh store it's just the FA829B53 and no other lines

Improve this answer
0

Verify if your trusted key is the same in the file ~/.password-store/.gpg-id

Improve this answer
3
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
    – Kevdog777
    Jan 9, 2020 at 12:09
  • indeed I had the same problem, I resolve it with this
    – m3asmi
    Jan 9, 2020 at 13:48
  • It just so happens that this is EXACTLY what is needed. ~/.password-store/.gpg-id is the key name that is used for the pass application. In my situation, I had the default .gpg-id which included the following contents: "my local password storage". Once I changed to the name/account of the keys I had imported, it worked.
    – VMcPherron
    Nov 8, 2021 at 22:12
0

In some cases it's a question of access rights to the file you want to encrypt.

Specially when you have imported the public key and it's visible, when you

gpg --list-keys

sudo does not help in this case on Kali Linux. You need to be root!

Improve this answer
2
  • '/home/shved/.password-store/test.gpg' is not in root. It is in /home so you don't need to be root to encrypt it.
    – karel
    Feb 2 at 11:12
  • Well, if the encrypted file is stored on a filesystem to which you need elevation for... You need sudo, but in my case even sudo didn't help, because the owner was root of a different system. In this case, the error message was the same.
    – Sasa
    Feb 3 at 12:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .