SSH Start to Finish Architecture – very broad overview discussion of gpg-agent

Thank you to everyone who sent get well notes.  I appreciate it.  I’m doing slightly better.  Since I’m still not 100%, I haven’t gotten the deeper details of how the Yubikey 4 will work (as in, compiling software to use it, configuring it to be used, and then explaining the step by steps of using it.)

I have, however, learned enough to give a broad overview of the expected behavior, so we’ll start with that.

Earlier in this series, we talked about loading our private ssh key using ssh-add.  This required another service to also be running: ssh-agent.  The same is still true of ssh-add, but we need to use a different agent when dealing with using OpenPGP keys as an authentication mechanism.  For GnuPG, the tool is gpg-agent.

The general gist is that GnuPG needs to be configured to support SSH keys in its configuration file.  Once this is done, we can switch to using gpg-agent instead of ssh-agent.  This agent is capable of loading standard SSH private keys as normal, but it also allows for presenting an OpenPGP key as an authentication mechanism for SSH private key logins.

One thing we need to remember about OpenPGP is that it handles multiple keys that have multiple uses.  One use is “signing” which we might use for say… email.  One use is “encrypting” which we again might use for say… email.  When we load a key with gpg-agent, we want to make sure that the signing and encrypting capabilities of the key being presented are turned OFF.  Instead, we want only the “authentication” capability to be turned ON.  We are, after all, using this to authenticate to a server, not using it to encrypt or sign static files.

There are also two ways to handle the private key in general.  It can be generated “on the device” or loaded “to the device” after being created “off the device.”  The desired solution is to generate this “on the device” so that the private key never touches a hard drive where it can be retrieved via forensic tools.  This does, however, tie the key to that specific device, so if the physical key is lost, the keyring is lost, and the web of trust for that would be difficult to re-build.  Except we’re talking about using this device for nothing more than authentication.  We should not ever actually use the OpenPGP keys on this device for signing or encrypting emails.  It has no reason to be in the OpenPGP concept of web of trust.  It should ONLY be used for authenticating ssh connections.

The other argument is that you can generate a sub-key from your primary OpenPGP key that everyone knows you buy in the web of trust, and assign this sub-key authentication roles, then upload that to the Yubikey device.  If the device is lost, the subkey can be revoked, and a new key generated to go onto the new device that would surely be purchased to replace it.

My thoughts are… go with whatever you are more comfortable with.  I personally feel that it is better to generate the private key on the device and just don’t include it in the web of trust, since it’s sole purpose is authentication.  However, if you handle the key ring like a pro because you use OpenPGP for email correspondence on the regular, and you’re more comfortable using your single OpenPGP keyring for everything, by all means, go ahead and generate the sub-key and upload it to the device.  You’ve already got a feel for handling your keys in a sanitary environment, if you’ve been doing that a while, right?

While the OpenPGP keys for authentication was my primary reason for purchasing  and testing the Yubikey 4, there are other capabilities that may also tie in for a more robust secure login regime.

The server can be configured to take Yubikey One Time Pad (OTP) passwords, if there is a PAM module (or BSD Auth module) available for your OS.  Linux and I believe FreeBSD both have PAM modules.  OpenBSD has a BSD Auth function, but it’s local authentication, only.  This means it doesn’t report to a centralized server when the OTP is used, and therefore it doesn’t keep things synchronized across multiple environments.

The device also can be configured to send a static password much like a simple two line USB Rubber Ducky payload.  You can configure this to be a “password” or you can put a pass-phrase on it.  If you do this, Yubico recommends that you only store part of the password or passphrase on the device.  Type part of it manually, and then press the button for the correct duration to trigger the rest of the passphrase to be sent via the Yubikey.

There is also reference to a PIV SmartCard capability, which seems be an OpenSC implementation that potentially may also work for SSH authentication using PKCS11 instead of OpenPGP standards.  I will make an attempt to configure each of these and demonstrate both before this series is finished.  Of course, I retain the right to state I may be confused, and the PIV SmartCard and OpenPGP SmartCard functions may be the same thing on this device.  I’ll know for sure when I dig deeper and try both.