[lrvick]

There is already a standard solution for this imo. Get a GPG smartcard like a Yubikey and put an Authentication subkey on it.

Now to ssh to anything, clone from Github, etc you insert your Yubikey, and enter your pin to unlock it. A gpg-agent process is created that acts as a standard ssh agent.

No server modifications required and you get strong hardware backed 2FA. The ssh private key never enters system memory and could not be stolen even by an untrusted machine.

If the smartcard itself is stolen, it will brick itself on 3 incorrect pin attempts.

The same device can also store all your OTP tokens or behave as U2F depending on what a service supports so the end game is secrets no longer live on disk or in memory on your systems.

This also integrates well on Android devices via the Yubikey Neo with apps like Yubico Authenticator and Open Keychain,

[lwf]

Sure, SmartCards are two-factor, unless the token has a hardware/software bug.

This has happened in the past[1]. I'm a huge fan of the CCID/GPG capabilities of the YubiKey, but I'm not sure they should be used in isolation in high-security environments.

[1]: https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory...

[lrvick]

Facebook, Google, and the DOD all rely on yubikeys now to mitigate a lot of remote attack vectors. It is not perfect, but it is well audited by some of the best in the industry and as good as it gets atm. There has never been a situation where a yubikey (or other GPG smartcard) has allowed read access to private keys. The secure elements do their job.

As for this vuln, it was a flaw in pin validation, the secrets were never exposed. An attacker that has physical access to the system using the yubikey could simply wait and intercept the pin without this flaw. Any active agent no matter how it was initiated is subject to hijacking like this.

The pin protects against use when physically stolen, not when in active use by the owner. You get assurances your secrets are never copied, but no assurances they are not being used right in front of you by a third party on a machine you think is trustworthy.

The only way I know to mitigate an attacker hijacking keys like this without significantly inhibiting workflow is configuring automatic ejection and re-enumerate the device on touch. Then ssh talks to gpg agent which blocks and waits on key insertion. You touch it and it completes the ssh handshakes then it auto ejects the moment the operation is over.

[lwf]

> Facebook, Google, and the DOD all rely on yubikeys now to mitigate a lot of remote attack vectors.

Yes, but not as the sole factor. I've overseen a rather large deployment of Yubikeys, and I believe they provide a huge security improvement compared to other second-factor alternatives.

> The only way I know to mitigate an attacker hijacking keys like this without significantly inhibiting workflow is configuring automatic ejection and re-enumerate the device on touch.

Agreed. I was very happy when this was added in the YubiKey IV.