
Using GnuPG can be hard, we’ve been there before. You generate your keys and then somehow you loose them, and then you realize you should get to learn how to correctly use GnuPG, but reality hits and there are no complete tutorials. So you go around the interent and try different articles and sources with no luck. Although I don’t promise a complete and comprehensive guide to GnuPG, in this article I would go over setting up GnuPG keys, subkeys, using GnuPG for SSH, transferring keys to other computers and using online services like Github and Codeberg.
Generating GnuPG Master-keys
GnuPG uses asymmetric encryption, which means that you would use 2 keys. Private keys for decrypting data. Public keys for encrypting data. By default, the implementation of GnuPG generates 2 pairs of keys, the master-key and a signed sub-key. It also generates your primary user identity.
The types of keys GnuPG can generate are:
- pub - public primary-key
- sub - public sub-key
- sec - secret primary-key
- ssb - secret sub-key
By default, running gpg --gen-key
creates pub, sec, and sub, ssb. The latter
pair is for encryption.
Generate your new secret keys either with the quick command gpg --gen-key
, or,
if you would like to specify the bit-size (recommended 4096), with the command
gpg --full-generate-key
.
|
|
After creating your initial keys, you should have one master key (the first one)
that is signing and certification only ‘[SC]
’, and one encryption key ‘[E]
’.
Generating Sub-keys
Sub-keys are separate pair of keys generated by GnuPG, with the slight difference being that those keys are signed by your master key. Since the Web-of-trust is built upon the master key, you must keep your master key secret, and as I will show later, not on actively operating computers. Sub-keys allow you to sign and encrypt with your master’s key identity without the actual master key.
Sign-only keys can be used to sign Git commits. To generate a signing key:
|
|
Choose an expiry date which is far enough to not be a hassle. You can always
change the key expiry date, with the ‘expire
’ command. If you have multiple
devices (or installs) on which you would like to use your GnuPG keys, you can
create as many keys as you need and then distribute them appropriately. However,
this only works for sign keys and NOT encryption keys. GnuPG will just use the
latest encryption key. This configuration of subkeys would allow you to
selectively revoke compromised keys, with no need to revoke your master key.
Using GnuPG for SSH
You can generate an authorization key for SSH:
|
|
To setup GnuPG to act as an SSH agent:
|
|
Your location of the configuration file may vary.
Add to your pre-desktop files (e.x. .bash_profile, .zprofile):
|
|
Tell the GnuPG agent about your key. First find your auth. public key:
|
|
Append the keygrip to sshcontrol
:
echo {41FE9D7D43999B0A0344E4F4900E1E1A3E142065} >> ~/.local/share/gnupg/sshcontrol
Re-login or end any SSH agents, then run ssh-add -l
to check if the agent does
detect the key.
Transferring Your Keys
Back-up your keys:
|
|
Keep all those files safe somewhere external. Move the public key files to the destination installion you would like to have your keys.
You will need to get your subkey’s public key id which you would want to use on the destination installation:
|
|
Export your subkey private key:
|
|
Now to import your exported files, run these on the destination system:
|
|
Do not to forget to shred -U
your *.asc
files.
If you chose GnuPG as your SSH agent, and if you run ssh-add -l
on the
destination system and it does not show a user id, you would have to update the
sshcontrol
file with the new keygrip (use same method as above). You would
also need to update server SSH public key, by adding a new one. I didn’t find
a simpler solution to this.
Using Codeberg & Github
You can use your newly generated subkey for signing code commits. And by generating a subkey for every system you would like to sign your code on, you can ensure that in case you loose the private key for the subkey, it is just a matter of revocation and updating of your master public key to reflect that. A disadvantage of this method is that you do need to update the master key for any important modifications, like adding or deleting subkeys.
To start using your keys, export your public key and paste the extracted data on Codeberg and Github. I hope I can safely assume that if you followed along this article, you would be able to do that by yourself.
Export your SSH public key like so:
|
|
Add the output to Codeberg and Github.
Check if your SSH authentication works (I use dropbear client, it works smoothly with GnuPG):
|
|
Don’t forget to configure git to always sign your commits:
|
|
The exclamation mark is not a typo!
Side note: I recommend generating your master key on a different installation
than your main install, and then importing your needed subkeys to your main
install. Either that or delete your ~/.local/share/gnupg/
after you have
backed up your keys to another storage, then reimport them again without the
master private key. This is so you do not store your master private key on an
active machine connected to the internet.
Further Reading
- Developers Guide to GnuPG and Yubikey🔗
- Debian’s guide for subkeys🔗
- Why does gnupg create 4 separate keys and what does sub and ssb mean?🔗
- Why am I encrypting with subkey instead of primary key?🔗
- GNU Privacy Handbook - Key Management🔗
- Anatomy of a GnuPG Key🔗
- Does creating new subkeys change an existing master key?🔗
- How to delete a subkey on Linux in GnuPG?🔗
- Jente’s Hidskes’ article on using subkeys to sign commits🔗
- Git uses wrong subkey for signing commits🔗
- Of course, ArchWiki’s article on GnuPG🔗