1

I have a Yubikey acting as a GPG smartcard. SSH is configured to use the smart card socket for authentication, and authenticating with the GPG key with Authentication capabilities work fine.

ssh-add -l
2048 SHA256:ey5VPl70RKvXSdaon6ugxiO1ZrzqxJwz7VWZM7zvN/c cardno:000607329647 (RSA)

I have some additional SSH keys that are used for SSH authentication to various servers. I can add these to the ssh agent with ssh-add somekey, but then I need to provide a passphrase per key. Is there a way to use the smartcard to protect these keys instead?

The desired end state is that multiple SSH keys are stored encrypted on disk, and the smartcard and gpg-agent is used to unlock and cache them.

  • Why not simply use separate PGP subkeys? – RubberStamp Jan 20 at 14:44
  • The Yubikey can only hold 3 subkeys, that's too few – gogstad Jan 20 at 14:46
0

The easiest solution I was able to come up with this morning uses Key Encryption Key principles for execution. This is fairly common when using multiple SSH keys on servers in the cloud. You can use a cloud based HSM to encrypt/decrypt the keys you need to use without having to store it locally. This was when your encrypted keys are left on the disk, and attacker doesn't have access to the master key.

To implement this within your environment you need the following:

  1. A gpg configured Yubikey (or other GPG key system)
  2. A target file to encrypt/decrypt
  3. A slightly modified configuration file

For the purposes of this article, I'm going to assume the reader has already configured their Yubikey. If you haven't done this (I realize OP has), you can register your key with gpg with these directions:

https://support.yubico.com/support/solutions/articles/15000006420-using-your-yubikey-with-openpgp

The first thing you'll want to do is determine which key you want to perform the local encryption and decryption. Try running:

gpg --list-keys

This will output a few lines. We need the content of the PUB line for the key associated with the yubikey:

pub   2048R/E48EFBC7 2019-01-20

Specifically, we need the 8 characters "E48EFBC7". Once we have the characters, we can copy them to our configuration file to ensure we use the yubikey key by default. To do this, update the following line in the gpg.conf file (~/.gnupg/gpg.conf):

default-key E48EFBC7

By default, this line is commented out, you'll need to uncomment it. As a side note, this is NOT required, but it is helpful. Instead of trying to specify a key for encryption, you can make the application leverage your Yubikey by default.

The next configuration will be altering the recipient. Again, this is optional but definitely helpful. Scroll down and uncomment the following line within the gpg.conf file:

default-recipient-self

Now your gpg agent is set to automatically use your yubikey for encryption/decryption and to make the target recipient your encrypting key.

With this in place, you can now start encrypting and decrypting your certificates. To encrypt simply run the following command:

gpg -o <output.gpg> -e <ssh.key>

To decrypt;

gpg -o <ssh.key> -d <output.gpg>

Decryption will ask for your Yubikey PIN.

Some finer notes:

  • Run a chmod 600 on your ssh keys when they are un-encrypted to make sure only the direct owner has permission to read the key.
  • Remove decrypted keys when they are not longer needed.
  • You can still add a key to your ssh keys to protect them even when they are decrypted.
  • Thanks for the comment. It's possible to shift the encryption from an AES encrypted SSH key with passphrase, to a "GPG encrypted" file. I'm afraid that's a worse solution. True you don't have to remember a passphrase, but now you have a permanently decrypted keyfile on disk that users need to remember to encrypt when they leave the workstation. That will slip some time, and also you don't leverage the default cache eviction policies of ssh-agent or gpg-agent. – gogstad Jan 21 at 8:20
  • If you read the man files on GPG agent, it is the background service for the gpg application. It even states that running gpg-agent is unnecessary if using gpg. My guess would be that you could leverage a configuration policy to meet additional requirements. – Connor Peoples Jan 21 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.