You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Enable 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-support
Optionally, 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.
Last, 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.
To continue, execute those commands in your current session.
Share your SSH Key
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.
Our primary mechanism for generating our security keys will be Gnu Privacy Guard (GnuPG). GnuPG is complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as PGP). With support for S/MIME and Secure Shell (ssh), it provides a single place to generate and manage all our keys.
Master Key
Invoke gpg2 frontend with --expert and --full-gen-key option.
$ gpg2 --expert --full-gen-key
For the key selection we will use ECC for both the primary and subkey. The advantages of ECC-based certificates are two-sided: ECC-based signatures on a certificate are smaller and faster to create; and the public key that the certificate holds is smaller and more agile as well. Verification is also faster using ECC-based certificates, especially at higher key strengths.
Please selectwhat kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(9) ECC and ECC
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(13) Existing key
(14) Existing key from card
Your selection? 9
To reduce attack vectors we should use Curve 25519. Curve25519 is constructed such that it avoids many potential implementation pitfalls. By design, Curve25519 is immune to timing attacks, and it accepts any 32-byte string as a valid public key and does not require validating that a given point belongs to the curve, or is generated by the base point.
To ensure comprised keys do not live forever, we should set a reason expiration period. This can always be extended in the future assuming all is ok (see below for more details).
Please 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 years
Key is valid for? (0) 1y
Is this correct? (y/N) y
The identifying information that is supplied next can be used by other entities to confirm the certiifcate issuer.
GnuPG needs to construct a user ID to identify your key.
Real name: Stephen Cox
Email address: [email protected]
Comment: Master
You selected this USER-ID:
"Stephen Cox (Master) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
Using the GUI prompted, enter and re-enter you select password.. This should be at least 12 characters long with a mixture of upper and lowercase, numbers, symbols etc... the harder to guess the better.
Please enter the passphrase to protect you new key
Upon entering the password (at which point gpg2 will exit) you should see something similar to:
pub ed25519 1901-01-01 [SC] [expires: 1902-01-01]
0123456789ABCDEF0123456789ABCDEF01234567
uid Stephen Cox (Master) <[email protected]>
sub cv25519 1901-01-01 [E] [expires: 1902-01-01]
You can confirm a second way that you created the key by running the command: gpg2 --list-secret-keys. You should see the same key in this output:
pub ed25519 1901-01-01 [SC] [expires: 1902-01-01]
0123456789ABCDEF0123456789ABCDEF01234567
uid [ultimate] Stephen Cox (Master) <[email protected]>
sub cv25519 1901-01-01 [E] [expires: 1902-01-01]
Congratulations, you have an active signing and encryption key on your machine! However, if you are truly into security, we are not quite done yet.
GPG Key Permissions
For the attentive reader, you may have noticed that the master key is labelled as [SC] and the subkey is labelled as [E]. These labels indicate the permitted usage of the GPG key.
There are four permissions/uses of a GPG key:
E = encryption
S = signing
C = certification
A = authentication
Encryption and signing capabilities are the two that you are most likely to use in your every day life, and the names are pretty self-explanatory.
The certification permission allows you to create more (sub)keys with E, S, or A permissions. The permission exists on the master key, so subkeys can't create infinite number of subkeys themselves.
The authentication permission is not used in practice, but there are obscure implementations of SSH and other protocols that can use GPG keys for extra security.
Increasing security through subkeys
What you have right now is considered your "master key." GPG supports subkeys, which are additional key pairs associated with your master key.
For increased security, it is recommended that you use only subkeys on your regular laptop or desktop computer and store your master key on an offline device such as a portable hard drive.
If you lose your device, you can revoke the subkeys on your laptop, keep your master key alive, and generate new subkeys without losing the reputation you have built.
You only need to create one new subkey for signing since the original key creation step automatically created an encryption subkey.
Signing Key
In the terminal, enter the following command, replacing the key ID for your own:
At the gpg> prompt type addkey and hit enter. You will get a list of key types that you can create:
Please selectwhat 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 key
(14) Existing key from card
Your selection? 10
Again create a key, as before, except this time use (10) ECC (sign only). You will also get a prompt to enter a password to unlock the key. This is the same password as previously used during the inital creation process.
Once created, you will see that you have a second subkey:
At the gpg> prompt, type save then hit enter. You should now see the new subkey when listing keys.
/home/andronics/.gnupg/pubring.kbx
----------------------------------
pub ed25519 1901-01-01 [SC] [expires: 1902-01-01]
0123456789ABCDEF0123456789ABCDEF01234567
uid [ultimate] Stephen Cox (Master) <[email protected]>
sub cv25519 1901-01-01 [E] [expires: 1902-01-01]
sub ed25519 1901-01-01 [S] [expires: 1902-01-01]
Now, you should back up three files: your public key, your secret (master) key, and your secret subkeys. Adjust the output path/name and the key ID for your system. You will be prompted to provide your password while export each secret
Copy the files to a secure, offline storage medium, such as a hard drive or USB memory stick. We want to save these as a backup but not have them on our local machine.
Now, remove the secret keys on our local GPG instance by running the following command:
Next, we want to re-import just the secret subkeys for use on our local machine. The subkeys will allow us to sign and encrypt on our local device, but we will not be able to generate new subkeys without re-importing the master key.
$ gpg2 --import andronics.secsub.gpg
After re-importing the secret subkeys and running the list-keys command, you can see that the secret keys are back, but notice the sec# in the output. The # means only secret subkeys exist, not the master secret key.
/home/andronics/.gnupg/pubring.kbx
----------------------------------
sec# ed25519/0x89ABCDEF01234567 1901-01-01 [SC]
0123456789ABCDEF0123456789ABCDEF01234567
uid [ultimate] Stephen Cox <[email protected]>
sub cv25519/0x6789ABCDEF012345 1901-01-01 [S] [expires: 1902-01-01]
sub ed25519/0x456789ABCDEF0123 1901-01-01 [S] [expires: 1902-01-01]
As the last step, delete the three exported keys from your local machine. The only place they should reside now is on your offline backup hard drive.
Congratulations! You've successfully created your GPG key pair, backed up the master key to a safe storage location, and set up your local machine to use subkeys for encryption and signing.
