OpenPGP Part 7: SSH

In this post we will cover how to use your authentication key for SSH.

Why

So you need to use SSH for Github access or log into that jump box for work. Maybe you just want to SSH from your main machine to a Raspberry Pi. But you don’t want to have to remember a password every time. There has to be a better way. Luckily there is.

If you’re anything like my past self this flow may sound familiar. You need to use SSH. The instructions have some SSH key generation commands to run. You run them and use the generated key and then never use it again. You get a new computer, rinse and repeat.

When I learned about how to do this with my GPG keys it all made sense. I’m never going back to the old way. The identity we created in previous posts allows us to reuse our subkeys in a variety of situations. SSH is one of those. Unless your key is compromised you should never have to run those obscure SSH key generation commands again and all you need to remember is the single key passphrase regardless of what system you are SSHing into.

Yes, you can use your GPG authentication key for SSH! Let’s cover how.

How

On Linux, by default, SSH uses keys found in the home .ssh folder. However, you can tell the SSH agent to talk to the GPG agent for keys instead. With this simple “wiring” change we can use our OpenPGP flow of having a single passphrase or even use a Yubikey for SSH authentication.

Before we get started you will need an authentication subkey.

The rest of this is pretty simple to set up. On your main machine all we have to do is rewire things so the SSH agent knows to ask the GPG agent for key information. But first we need to let the GPG agent know that it will be asked to handle requests from the SSH agent. We do that by making a single line addition to the ~/.gnupg/gpg-agent.conf file. If this file doesn’t exist in your .gnupg folder you can create it.

enable-ssh-support

Next we let the GPG agent know which GPG key to use for SSH. We need the keygrip of our authentication key for this step. To get it, simply run the following command:

gpg -K --with-keygrip

This will print out your keys with the Keygrip information.

sec   rsa4096 2024-02-15 [SC]
      DF74A15DE3B03EFD3ED200ABE0D76D68AEA7E185
      Keygrip = 829994416B95C0C99B92CFBF23C745DF008D0D4E
uid           [ultimate] Test McTester <test@test.com>
ssb   rsa4096 2024-02-15 [E]
      Keygrip = 42B1F60C364A16D02616ADD075F983FDB97008C1
ssb   rsa4096 2024-02-15 [A]
      Keygrip = 399F66DF8FE16A1085297E473C2FB99058C10EDF

Copy the Keygrip of your authentication subkey. Append the key to the file ~/.gnupg/sshcontrol.

399F66DF8FE16A1085297E473C2FB99058C10EDF

Finally, in your .bashrc file or equivalent add the following:

export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

This is the “rewiring” part and tells SSH to talk to the GPG agent when it needs keys.

Restart the GPG Agent for the changes to take effect (it should restart automatically when needed).

gpgconf --kill gpg-agent

To verify that everything is wired up correctly and that the SSH agent is looking to GPG for keys you can run the following command.

ssh-add -l

This will list the keys SSH knows about. It should show your authentication subkey.

4096 SHA256:RtSMT6UcWLtP3iKBttBqu7HptQa+7Bbgu1wORzgyqXw (none) (RSA)

Docker Notes

If you are following along in a Docker container you may find it necessary to run a few commands to get things to work. I did not have to run these on my main PopOS machine but did have to run them in Docker.

export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye

Let the Remotes Know

Now that your main machine is set up to use GPG keys for SSH all you have to do is let the remote machine know about your public key. To get your public key run the following:

ssh-add -L

Notice the “L” is capital this time, not lowercase as before.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDL7ro24Gpi0dwGOlDxQuZP/0JqupX2/ogUx/2pn3D2e5ckRwtXtwLL45K5ainlHFjT/4fNtRFvoVmWHIjMwFFZqF5mcS2Nj83/RG63Tlvo+Fbbybv+himiWQHMUuGGZFXEsd/QmHcFaKRKCbUoi5MutmFASBbYGbn4OyXY3KPYUEijs2CowsTjQaeuRVe7ArDbHeS9YGBe+Y+rYmldYeC6+aqgasm09/RPoE/2+lDqD8cEJN4kZAGQCmQ7Dte302uOaPhnGzhnLsMS9vCtEeNwurjJqAuySAqZ1JbduzzIzTlmFuFZNv9ZHt/lSR+p/OC7tZfsn8Xhi8UMRuORAF3sH/4A+Ag0jIYjvmwhjWC1pPT5YP8BNRCpcmZakLosjG4WizOtyaIuWKRlLqbbeF0qagd2LaSgEbF1+tzg7adrNAxhAJyqx8EqB+VJaOXZe+xI+IxCcTnMlMd/q21qzic4YDCfyvGWvwltKTUtYDNjvb1wQwquzj9rUY/KScXsE8PItuFENZKjLjHtvtwBUL6HfxeAxkxDwQV5tz5ad5ER36NL0MM/WOaJ1hJUtP+35Rp530evpkYwRezEZW+gnF+99Xls2GIJX0mjiYkF0lGVZECgtVK4LrR7LNWyNFX7PGec2yCxLHKwXxIISoK7vvb/4WLF1wWv6Z0cbbBjwoy06w== (none)

Copy the output of this command and paste it into the ~/.ssh/authorized_keys file of the remote machine. You can also use this key for SSH access to Github by adding the key to your account. Anytime, anyone needs to give you SSH access you can simply give them that key. They will drop it into the authorized list and you’re good to go.

Video Walkthrough

Conclusion

Using your GPG keys for SSH has several benefits but I love it just because I can reuse my existing keys and don’t have to keep track of anything else. I only have to keep track of a single set of keys. Enabling it from a remote machine perspective is dead simple and requires no special handling. Just drop in the public key.