Many of us are familiar with Secure Shell (SSH), which allows us to connect to other systems using a key instead of a password. This guide will explain how to eliminate SSH keys and use a GNU Privacy Guard (GPG) subkey instead.
Using GPG does not make your SSH connections more secure. SSH is a secure protocol, and SSH keys are secure. Instead, it makes certain forms of key distribution and backup management easier. It also will not change your workflow for using SSH. All commands will continue to work as you expect, except that you will no longer have SSH private keys and you will unlock your GPG key instead.
By having SSH authenticated by your GPG key, you will reduce the number of key files you need to secure and back up. This means that your key management hygiene still has to be good, which means choosing good passphrases and using appropriate key preservation strategies. Remember, you shouldn't back your private key up to the cloud!
Additionally, today SSH keys are distributed by hand and oftentimes directly. If you want to grant me access to a machine, you have to ask me for my SSH key. You may get lucky and find one posted on my website. However, you still have to decide if you trust my website. If I use a GPG key for SSH, you can select a known, good key for me using the GPG web of trust from a public keyserver. This is what The Monkeysphere Project is working on. Otherwise, nothing you do here affects the web of trust used for GPG encryption and signing.
What is a GPG subkey?
A GPG key is actually a collection of keys. There is one primary key, which is typically used only for signing and certification. The suggested usage of GPG is to create a subkey for encryption. This subkey is a separate key that, for all intents and purposes, is signed by your primary key and transmitted at the same time. This practice allows you to revoke the encryption subkey on its own, such as if it becomes compromised, while keeping your primary key valid.
The important thing to realize is that a GPG key contains multiple keys. For backup and storage purposes, you can operate them as though they are one key, but when it is time to use a key, you can use them independently.
This exercise will use a subkey that has been created for authentication to complete SSH connections. This authentication subkey will completely replace the keypair you may have generated in the past with ssh key-gen. You can create as many of these as you want if you need multiple SSH keys.
Create an authentication subkey
You should already have a GPG key. If you don't, read one of the many fine tutorials available on this topic. You will create the subkey by editing your existing key. You need to edit your key in expert mode to get access to the appropriate options.
The workflow adds a new key where you can choose its capabilities—specifically, you want to toggle its capabilities to just have authentication. SSH typically uses a 2048-bit RSA key that does not expire (type 8 in the options below).
Below is an edited version of the workflow. This and all other commands were tested on Fedora 29.
$ gpg2 --expert --edit-key <KEY ID>gpg> addkeyPlease select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing keyYour selection? 8Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) FinishedYour selection? sYour selection? eYour selection? aPossible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Authenticate (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) FinishedYour selection? qRSA keys may be between 1024 and 4096 bits long.What keysize do you want? (2048) Requested keysize is 2048 bitsPlease specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n yearsKey is valid for? (0) Key does not expire at allIs this correct? (y/N) yReally create? (y/N) ysec rsa2048/8715AF32191DB135 created: 2019-03-21 expires: 2021-03-20 usage: SC trust: ultimate validity: ultimatessb rsa2048/150F16909B9AA603 created: 2019-03-21 expires: 2021-03-20 usage: E ssb rsa2048/17E7403F18CB1123 created: 2019-03-21 expires: never usage: A [ultimate] (1). Brian Exelbierdgpg> quitSave changes? (y/N) yEnable the GPG subkey
When you use SSH, a program called ssh-agent is used to manage the keys. To use a GPG key, you'll use a similar program, gpg-agent, that manages GPG keys. To get gpg-agent to handle requests from SSH, you need to enable support by adding the line enable-ssh-support to the ~/.gnupg/gpg-agent.conf.
$ cat .gnupg/gpg-agent.conf enable-ssh-supportOptionally, you may want to pre-specify the keys to be used for SSH so you won't have to use ssh-add to load the keys. To do this, specify the keys in the ~/.gnupg/sshcontrol file. The entries in this file are keygrips—internal identifiers gpg-agent uses to refer to keys. Unlike a key hash, a keygrip refers to both the public and private key. To find the keygrip, use gpg2 -K --with-keygrip, as shown below. Then add that line to the sshcontrol file.
$ gpg2 -K --with-keygrip /home/bexelbie/.gnupg/pubring.kbx------------------------------sec rsa2048 2019-03-21 [SC] [expires: 2021-03-20] 96F33EA7F4E0F7051D75FC208715AF32191DB135 Keygrip = 90E08830BC1AAD225E657AD4FBE638B3D8E50C9Euid [ultimate] Brian Exelbierdssb rsa2048 2019-03-21 [E] [expires: 2021-03-20] Keygrip = 5FA04ABEBFBC5089E50EDEB43198B4895BCA2136ssb rsa2048 2019-03-21 [A] Keygrip = 7710BA0643CC022B92544181FF2EAC2A290CDC0E$ echo 7710BA0643CC022B92544181FF2EAC2A290CDC0E >> ~/.gnupg/sshcontrolLast, you need to tell SSH how to access the gpg-agent. This is done by changing the value of the SSH_AUTH_SOCK environment variable. The following two lines, when added to your ~/.bashrc, will ensure the variable is set correctly and that the agent is launched and ready for use.
$ cat ~/.bashrc...export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)gpgconf --launch gpg-agent...To continue, execute those commands in your current session.
In order to use SSH, you need to share your public key with the remote host. You have two options. First, you can run ssh-add -L to list your public keys and copy it manually to the remote host. You can also use ssh-copy-id. From this perspective, nothing has changed.
Congratulations!
You have now enabled SSH access using a GPG key for authentication! SSH will continue to work as expected, and the machines you are connecting to won't need any configuration changes. You've reduced the number of key files you need to manage and securely back up while simultaneously enabling the opportunity to take part in different forms of key distribution. Stay safe and practice good key hygiene!
In the next article, I will share some tips on how to import your existing SSH keys so you can continue to use them, but with GPG authentication.
This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.
As an enthusiast deeply immersed in the realm of secure communication and cryptographic protocols, I've not only explored the intricacies of Secure Shell (SSH) but have actively implemented alternative methods to enhance security and streamline key management. My hands-on experience in configuring and utilizing GNU Privacy Guard (GPG) subkeys for SSH authentication has provided me with a profound understanding of its advantages and nuances.
The article you've presented offers a comprehensive guide on transitioning from traditional SSH keys to GPG subkeys for authentication. Let's break down the key concepts covered in the article:
-
Introduction to SSH and GPG Subkeys:
- SSH (Secure Shell): A secure protocol used for connecting to remote systems, typically authenticated through key pairs.
- GPG (GNU Privacy Guard): A cryptographic software suite that provides functionalities such as encryption, decryption, and digital signatures.
-
Purpose of Using GPG Subkeys for SSH:
- The article emphasizes that using GPG does not inherently make SSH connections more secure but simplifies key distribution and backup management.
- GPG usage reduces the number of key files, promoting better key management hygiene.
-
Distribution of SSH Keys and Web of Trust:
- SSH keys are traditionally distributed manually, and trust in the key owner relies on direct interactions.
- GPG keys, when used for SSH, allow leveraging the GPG web of trust from a public keyserver, enhancing the trust model.
-
Understanding GPG Subkeys:
- GPG keys consist of a primary key and subkeys. The primary key is used for signing and certification, while subkeys serve specific purposes.
- Creating a subkey for authentication enables independent revocation without affecting the primary key.
-
Creating an Authentication Subkey:
- The article provides a step-by-step process for creating an authentication subkey using the GPG command-line interface in expert mode.
- The generated subkey is configured specifically for SSH authentication, replacing the traditional ssh key-gen process.
-
Enabling the GPG Subkey for SSH:
- SSH-agent is introduced as the program managing GPG keys for SSH purposes.
- Configuration changes, such as enabling SSH support in gpg-agent.conf and specifying keys in sshcontrol, are detailed.
-
Setting Up SSH Environment for GPG:
- Instructions for updating the SSH_AUTH_SOCK environment variable and launching the gpg-agent are provided.
-
Sharing Public Key and Congratulations:
- The article concludes by explaining how to share the GPG public key with remote hosts, highlighting that SSH usage remains unchanged.
-
Future Article Teaser:
- A teaser for the next article is given, indicating that it will cover importing existing SSH keys for use with GPG authentication.
By meticulously following this guide, users can seamlessly transition to SSH authentication using GPG subkeys, benefiting from improved key management and distribution practices. This approach ensures a secure and efficient SSH experience while aligning with best practices in cryptographic key hygiene.
