How to transfer pgp private key to another computer? [closed]

Question

I read this article (archived link) which explained very well how to setup PGP on macOS. But I'm planning to use the keys generated for signing Git commits, so I figure I need to transfer the keys to other computers. Is this correct? And, if so, what's the best way to transfer those keys between devices?

Hinckley

Which other computer? Why do you need two computers for this? – Monongahela

I actually have 3 comps, one win/mac/ubuntu, and I programm on all of them, and thus need sign refs in git with the same signature, so I assume I need to transfer the pgp keys, do I not? – Hinckley

Answer 1

Yes, you will need to transfer the keys. Mac and Linux work the same, storing the keys in ~/.gnupg. The safest way to transfer the files is using scp (part of ssh):

scp -rp ~/.gnupg othermachine:

However, you will need to have ssh working first.

Transferring them with, say, a USB flash drive isn't such a great idea because your private key will be left behind on that drive even after you've deleted the file. Although it's protected by a passphrase, if someone got hold of a copy of the key file they could mount a long-running brute-force attack on it at their lesiure.

I don't know about the location of the directory on Windows. The gpg documentation will say, and the contents will almost certainly be the same.

Copying the entire keyring is quick and easy, but sometimes you want to be able to move individual keys between machines without overwriting the entire keyring and losing the keys that are already there. Copying individual keys selectively can be done with gpg --export-secret-key and gpg --import. If you have ssh access to the destination machine you can do this with a pipe and don't need to store an intermediate key anywhere:

If you're on the machine that already has the key:

gpg --export-secret-key SOMEKEYID | ssh othermachine gpg --import

If you're on the machine that needs the key:

ssh othermachine gpg --export-secret-key SOMEKEYID | gpg --import

If gpg isn't in one of the default places on the remote machine (eg it's in /opt/local/bin on a Mac) you'll have to give its full path to ssh, or symlink it into one of the standard places such as /usr/local/bin.

Note that the data that's transferred is still protected by the passphrase, and the key will have the same passphrase at the destination as it did at the source. If you want to have different passphrases in each place, you'll need to change the passphrase at the destination, or change it temporarily at the source before exporting it. I needed to share a secret key with a colleague, in order to give him the ability to update a Debian package repo we both manage, but I didn't want to share my passphrase with him. So I changed the passphrase to something temporary, sent him the exported key (by gpg-encrypted email!), told him the temporary passphrase orally, and asked him to set a new passphrase immediately after importing the key. I then changed the passphrase on my copy of the key back to what it was originally.

---

Update on 2021-03-03

With GnuPG 2.0, if you're exporting the key from a remote machine and you don't have X11 connection forwarding, you may have problems entering a passphrase. For example, gpg says “cannot open '/dev/tty'”. If you force pseudo-terminal allocation with ssh -t the key becomes mixed up with the terminal activity such as the passphrase prompt and \rs. One way to work around this is:

ssh othermachine gpg --passphrase-fd 0 --pinentry-mode loopback ...

You will then need to enter the passphrase and press Enter. There will not be a prompt, and echo will not be suppressed (so the passphrase will be visible on your terminal). If you feel strongly about the echoing, you can turn it off temporarily with stty -echo and back on again with stty echo. This can all be rolled into a single command like this:

stty -echo; \
  ssh othermachine gpg --passphrase-fd 0 --pinentry-mode loopback \
    --export-secret-key SOMEKEYID | gpg --import; \
stty echo

However, it's rare that you'll need to do this since by far the most common case is when you're exporting from the machine you're sitting at and importing onto a remote machine that you ssh to.

Shamus

"Transferring them with, say, a USB flash drive isn't such a great idea because your private key will be left behind on that drive even after you've deleted the file." Well, if you are so paranoid, you can always encrypt the keys with some symmetric cipher for transfer. – Lympho

They private key is already encrypted with the passphrase you provided when you encrypted it. Encrypting it again doesn't make it more secure. – Phil

When I gpg --list-keys, it says from which file it's reading. When I copy the new file into that directory, gpg doesn't read from that file. If I overwrite the destination file, I lose all the original keys. How do I maintain both? (I thought this is part of the original question: don't destroy the keys that are already there...) – Homage

@LimitedAtonement, although this wasn't part of the original question, it's an important point. I'll update my answer with some info on how to do this. – Shamus

@RomanCheplyaka I updated my answer with some further thoughts about storing private keys on USB drives – Shamus

I have gpg --export-secret-key working for the key in question. I have ssh access functional for the remote machine in question. But gpg --export-secret-key SOMEKEYID | ssh othermachine gpg --import returns a Passord: prompt and then says bash: gpg: command not found. I have also tried this with just gpg --export which works locally but not in the compound command. Can you help? – Sheepshanks

@KindOfGuy, your problem seems to be that you can't execute gpg at the remote end over ssh. Since bash is saying that gpg can't be found, maybe it's a PATH problem? When executing a single command over ssh (rather than logging in interactively) your .profile isn't executed, so if gpg isn't in one of the standard places (eg in /opt/local/bin on a Mac) it won't be found. You can overcome this by giving the full path to gpg on the remote machine. – Shamus

I edited the answer to include a note about this possibility. – Shamus

@Ry4anBrase private key is already encrypted [...] Encrypting it again doesn't make it more secure I'm not an expert, but I guess it would if you encrypted it with stronger pass-phrase than before (say, just for the sake of transfer). – Fact

Sure, that's fair @AloisMahdal. Since the usual advice on a gpg private key is to use the most secure password you can stand to work with another layer wouldn't usually help, but if you picked a bad private key pass then by all means use a better one in flight. – Phil

With gpg 2.1.17 on the remote, I was unable to add the key remotely because (as it turned out) I needed to enter a password to add the key. Instead, I piped the output to file, copied the file, then executed the command on the file remotely where I was able to enter the password when prompted. This may seem obvious to some of us, but some readers might just execute the command and encounter gpg: key .../...: error sending to agent: Inappropriate ioctl for device followed by gpg: error building skey array: Inappropriate ioctl for device – Indelicate

@Indelicate Did you try the second version of the command above, ie "If you're on the machine that needs the key"? Because you're executing the gpg --import command in an interactive session that has a tty, I assume it would be able to prompt you for the password. However, I realize you may not have ssh access in both directions, ie from the destination machine back to the source. – Shamus

@neil I have to use a variant of the first version because the system that is providing the key is not accessible by ssh from the broader web (it is sitting inside a private network). Only the system that is receiving the key is accessible by ssh (from the providing system). – Indelicate

I had to use the --armor option; I was getting an error when importing my private key without it. – Finegrained

@Finegrained As long as the armor setting is the same at both ends it should work as-is. However, the non-armored (binary) form isn't terminal-friendly so if you have tty-allocation turned on by default on the remote system (eg in ~/.ssh/config) then you would need to turn on armor at both ends. Normally, non-interactive logins (ones that provide a command) don't use a tty. – Shamus

Does it actually add any additional security if every machine uses a different passphrase for the same private key? – Shushubert

@Toreno96, I'm not sure, but I don't see any reason it would improve security. Note that in the case I described in my answer the reason for changing the passphrase wasn't to increase security. – Shamus