For keeping SSH keys, the PIV module seems a bit simpler than GPG. I just went through the process myself.
They should also mention FIDO U2F, which already works well with Google, AWS and Github among others. Implementing it for your own site also seems doable.
I've thought about adding support for remembering devices but using the token is so easy it's just not a priority.
On the flip side, with PIV there’s no way I’ve seen to have it allow access for a short period of time (eg the way gpg can cache the pin for a set number of seconds) instead of per request which can get a bit annoying if you are invoking ssh repeatedly (which I seem to do a fair bit).
Would also reference the excellent yubioath tool for adding TOTP passwords on sites which don’t support FIDO/U2F - it’s very very easy to use and if you have an Android phone and an NFC enabled yubikey you can use there too.
I believe this is no longer the case? At least with current GPGTools on macOS, I leave a Yubikey Nano in one of my USB ports and use it for both GPG and U2F without issue.
If you're only using it for SSH, sure. If you also want commit signing, though, you'll need to set up GPG anyway.
My personal tinfoil headwear has me believing that AES on any of the Big-2 CPU's is compromised, probably via key logging deep in the bowels of the die. And the RNG could have a similar backdoor.
> AES on any of the Big-2 CPU's is compromised
In that case, which CPU could the Yubikey use?
Dedicated AES engines exist. For example, the 3DS shipped with a AES engine inside its SoC, exposed as memory-mapped I/O.
One thing with encryption on a USB-connected security dongle is that your scp / rsync / git pull invocation is going to go through it, and through its crypto engine. To make it not painfully slow, the crypto engine has to be pretty fast. It's likely not very cheap, either using a (fast) general purpose CPU core, or using custom / specialized circuitry.
Paying extra for high security at high speed may make complete sense in some cases. For a cheap mass-market product, it's less likely.
One repeated problem I've run into so far is that Firefox can read the Yubikey when it's inserted but it can't add the Yubikey as a new device yet. I have to pull up Chrome/Chromium to do so. After my most recent laptop reformat I vowed never to install Chromium again, even temporarily, so, out of luck until Mozilla gets that fixed, I suppose.
Although Google's site says "Your current browser doesn't support adding security keys" what they mean is "We don't care about any browsers except Chrome, it works in Chrome, just get Chrome". They don't implement the actual standard, even though they helped write it, because after all it works in Chrome™ as it is.
On sites that are built by somebody who actually cares about more than one browser, Firefox works just fine.
My GitHub has two Security Keys registered via Firefox this way.
Web site support that uses the feature on any browser has been slow also. Robinhood is the only financial app that I’ve found that even supports TOTP. My E-trade account still requires a hardware token with a little lcd screen on it - paging Captain Marvel.
Maybe the issue is just that it's so easy to attack password-protected systems that nobody even needs to attack keys.
Services that support them either have them locked down so hard that if you lose a single Yubikey (there's often no backup second key option), you're very screwed. Others go the other option, and have too easy to reset systems, SMS fallbacks, or other total bypasses of the security tokens.
For SSH and GPG, authentication keys are generally the least of your concern. The content you're controlling are much more valuable than the authentication itself. Can an attacker just wait until you SSH somewhere, and leverage that access? Can they wait until you'd press the button for another benign purpose and use that authentication in a malicious way? The answer is almost always yes, which reduces the value of these sort of devices substantially. They don't protect against local compromise, in which case a keyfile sitting on your local host is just as secure and a lot more convenient.
So I think in general private keys aren't improved with a token, since a compromised private key is supposed to be a local compromise.
In addition, these places tend to have less technical users and "plug it in and press during login" isn't terribly difficult
If an attacker can exfiltrate your private key they can probably keylog your passphrase & your VPN details
PIV/GPG smartcard solves he former and 2FA solves the latter so something like a yubikey/nitrokey gives you both in one device
Anecdotally I do have a friend who had his private key & passwords pilfered which was noticed when someone tried logging in from some other country.
There's a 2008 Fedora incident of this sort, a Fedora Administrator's private key was "stolen" by bad guys and used to upload replacement packages which is well documented e.g. https://lwn.net/Articles/326170/.
I think we should assume that this has also happened plenty of times to organisations which have a default posture of not telling you about incidents at all unless required by law.
I like the idea of SSH'ing with it, ill give that a shot.
Also on Android (but again not on iOS), Chrome (but sadly not Firefox as far as I know yet) can use the google authenticator app (again sadly I think no alternatives to this yet) to speak FIDO with an NFC yubikey.
I've even enabled U2F 2FA on my work desktop for log in, and use it as 1FA to unlock the screenlock, and it automatically locks when I unplug it. Very slick. You could do similar with YubiKey.
I tolerated that because a work account administrator can let me back in if I lose the key, but this is very much a second class implementation and I think AWS ought to do better.