SourceHut and GPG keys with SSH Subkeys
SourceHut?
I recently got an account at sr.ht so I had a place to stick my blog projects and because I needed to make a new decision about where to host now that GitHub is a corporate hellscape. GitLab was never really an option because it was already very corporate (not to mention quite heavy). In the end I picked this provider because it’s supposed to have cool build pipelines (which I still haven’t used) and because it’s fast and really low on javascript (which I generally don’t like on websites). So far I’ve made a single starting repository, which will at some point contain my ldapsearch to vcard contact repository (I’ll get around to writing it just as soon as I get distracted from something else and end up doing that instead). When I made that repository I realised I needed another SSH key. Because I’d like my identity for this website and sourcehut to be more or less separate from my regular life identity, I made a new GPG key as well. Then I realised I might be able to combine them.
GPG with SSH
Creating a GPG key is easy:
gpg --full-generate-key
Problem solved (after filling out all the paperwork). Creating a subkey under that main key that you can use to Authenticate is also easy:
gpg
followed by using addkey, requesting your own capability set and making sure only authentication is on. That yields you a new subkey, which is cool!
Existing SSH keys
The problem
That’s all well and good, but I have a large directory full of ssh keys that I use for various places. If I’m going to replace my ssh-agent with gpg-agent and use subkeys to authenticate, what about my existing keys? I could just use pem2openpgp and import the SSH keys as master keys into my existing keyring. That’s a reasonable solution, but I also frequently move laptops or reinstall my OS. To make this less painful, I have some setup stuff synced (essentially a dotfiles repo, but full of secrets like my private keys) to a number of encrypted spots. This allows me to easily set up a new environment and still be able to use emacs and identify myself to strangers. The key import process for openpgp is not something I enjoy (and exporting isn’t either).
The solution
So, in order to keep a clean keys directory and have a set of export/import scripts that are simple (so I can still read them a year from now) I figured it would be cool to add my existing keys to my existing gpg key (as subkeys). I found a ton of guides on how to do this online that were invariably a byzantine forest of instructions, invoking a mental image of me being arms-deep inside the cow innards of my master key so it can give birth to my subkeys. That’s not my objective, I like simple things.
StackOverflow to the rescue. This was a pretty simple set of instructions, all I needed was
pem2openpgp temp < "${keydir}/ssh_key.id_rsa" | gpg --import
Then you can get the keygrip with
gpg -K --with-keygrip temp
and you can edit your master key with
gpg --expert --edit-key $gpgmasterkey
Option 13 will allow you to add a subkey that’s actually an existing key, with the keygrip you got earlier. Done! You can export your ssh key using “–export-ssh-key”. Awesome.
Why isn’t it working?
I’ve never managed to get a gpg-agent as an ssh-agent working properly, so I didn’t actually know you had a ~/.gnupg/sshcontrol file that needs to contain the fingerprints of keys that are legal for use when talking to other servers.
If you have ssh configs like this
IdentitiesOnly yes
IdentityFile <keyfile>
PubkeyAuthentication yes
Then you can just put a keyfile that contains the public component of your ssh key here. That will help ssh select the correct subkey to connect with.
What now?
Now I have to actually write an ldapsearch to vcard converter. I will definitely do this at some point.