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
2
  • Try this answer unix.stackexchange.com/questions/184947/… TL;DR there is a --allow-secret-key-import option
    – infixed
    Feb 21, 2017 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, 2017 at 21:03

1 Answer 1

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.

1
  • Thanks! You helped clue me in to the fact that it prompted me for a password twice, not because the first time failed, and it was asking a second (of 3) times, but because the first time was for the primary key, and the second time was for the secret key. I ran my export a second time and it worked this time, since I put the password in correctly the first time.
    – isaaclw
    Apr 21, 2020 at 21:59

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.