3

I am transferring a key from one machine to another and do the following:

On Machine A:

% gpg --export-secret-key -a [username] > my_private.key

Please enter the passphrase to export the OpenPGP secret key:
"[username and other data like email]"
2048-bit RSA key, ID [removed-ID],
created 2015-11-09.

Passphrase:

Here I get an error when I type the known correct passphrase:

 *** Bad Passphrase (try 2 of 3) ***

Please enter the passphrase to export the OpenPGP secret key:
"[username and other data like email]"
2048-bit RSA key, ID [removed-ID],
created 2015-11-09.

Passphrase:

So I do what I have found to work as a workaround during decryption as well: just press enter

gpg: key [removed-ID]: error receiving key from agent: No passphrase given - skipped
Please enter the passphrase to export the OpenPGP secret subkey:
"[username and other data like email]"
2048-bit RSA key, ID [removed-sub-ID],
created 2015-11-09 (main key ID [removed-ID]).

Passphrase:

And this time it works - both when decrypting and it "works" (doesn't throw an error) to export the key.

Now I have my_private.key on Machine A.

I SFTP the file over to Machine B - I leave out the details as I don't think this is where the problem is...

On Machine B:

$ gpg --import my_private.key
gpg: Total number processed: 0
$

Note: it said "0 processed". Why? to be sure, I can do this:

$ gpg --list-secret-keys
$

What am I doing wrong?

Note

There may be 2 problems here:

  1. Why the correct passphrase works only after getting past the first "main key"?
  2. Why the exported key won't import?

Update:

After a suggestion to try the obsolete option --allow-secret-key-import, I tried it and got the following:

$ gpg --allow-secret-key-import my_private.key
gpg: subkey w/o mainkey
gpg: standalone signature of class 0x18
gpg: Signature made Mon 09 Nov 2015 11:26:17 AM EST using RSA key ID [removed-ID]
gpg: invalid root packet for sigclass 18
gpg: Can't check signature: Invalid signature class
  • Try this answer unix.stackexchange.com/questions/184947/… TL;DR there is a --allow-secret-key-import option – infixed Feb 21 '17 at 18:57
  • @infixed, Well that post says not to use the option you suggested. That being said, I gave it a try and got an interesting error. I will update the post accordingly. – Watki02 Feb 21 '17 at 21:03
1

The attempt in the update I posted clued me in that there are actually 2 (private) keys at play here: a master and a subkey. They are different. This article helped me get that fact even more: https://wiki.debian.org/Subkeys

I still don't know how I got into a state where the master has a different password to access than the subkey, but apparently that is why skipping the master and using the changed password for the subkey works.

Luckily I still had the password for the master that I thought I had changed a while ago. Using that, I was able to export the key, move it, and import successfully.

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.