5

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
Improve this question
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

Reset to default
3

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.

Improve this answer
1
  • 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

You must log in to answer this question.

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