The interaction shown in the "Having fun with an agent" section of the article shows the agent providing the public key and name, not the private key.
See the ssh-agent protocol for details: http://api.libssh.org/rfc/PROTOCOL.agent
You still should never forward your SSH agent to a system you don't trust. However, if someone compromises such a system, they have not necessarily compromised your SSH private key, though they may have used your agent to access systems you have access to while you were forwarding the agent.
Public keys are by definition public so they can be spread freely all over.
Forwarding will never compromise your private key. Of course, as you point out, if you forward THROUGH a compromised system, someone could hop on the key forwarding and come along for the ride. And, as another commenter pointed out, they could always hijack your access on the final system to create their own user accounts.
And also why a good SSH key manager like https://Userify.com to distribute your public key can make forwarding easier.
(And of course if the machine you're connecting from has an sshd listening then there's a good chance they could successfully connect back to it using your agent forwarding, then subvert the agent itself)
You need gpg-agent running in ssh-agent emulation to have ssh use the private key on the token.
It requires you to enter a user PIN before it authenticates connections, but the PIN can be cached by gpg-agent for a configurable duration. Enter the wrong user PIN three times in a row and it locks up (can be unlocked via the admin PIN). Basically, everything you know about smartcards applies here - except this is very small and portable.
You can't reveal the private SSH key even if you're very sloppy.
The OTP can be setup with things such as VPN or other places where you need to authenticate with user/pass. There's an open source authentication server that you can deploy wherever, or you could use the manufacturer's cloud auth.
It can also do NFC and FIDO U2F (it's a superset of Google's cheap FIDO U2F Security Key).
In a word - awesome.
I just haven't seen any howto showing how to do it, and I could not find the time to research this option.
Now, are there ways to attack the authentication via tapping as root into the gpg-agent process? I don't think so, but frankly I'm not that familiar with the sausage-making parts of it. I'd like to learn more about this topic.
They should get FIPS 140-2 Level 4 certification, then. Other devices that claimed to be so resistant haven't really fared that well when someone actually bothered to look. It might be out if there range of average software hackers, but perhaps easily handled by someone with hardware capabilities. Even the Chrysalis Luna CA3 (I think that model) was breached by a university team. And a sole researcher breached a popular TPM, finding no special protection.
So I'm not sure it's justified to say it requires an NSA level adversary. The bar is probably much lower. On personal stuff, I use drive level encryption, then Bitlocker with TPM, then Athena SCS smartcard for logon+EFS, and Bitlocker on a vhd for the VM actually running stuff. Only the last layer, the passphrase on the vhd, is something I count on. The rest is just to make it easy to brick the device and prevent a quick handed adversary from quickly installing a rootkit. In particular, I have very little confidence in Crucial's SSD's drive encryption. For all I know, the key is stored unencrypted on the first sector. But it's totally free, as the device runs AES to balance the 1s and 0s anyways.
The popularity of these things seems to be growing pretty fast, so I'd expect someone will take a look pretty soon.
A lot of these tokens, or similar models, are used by large, famous high-tech companies for their employees. That's bound to attract some school-of-hard-knocks probing from 3rd parties (beyond what the googles and the facebooks of the world did before they deployed it to their internal users).
But this list spans 20 years of vendor certifications, and I count only 19 entries out of 2277 which have achieved Level 4.
Edit: Oops, actually only Overall Level 1. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/1...
This makes more sense to me than separating keys by "purpose", since it aligns better with the threat model (machine gets compromised).
Unless you're using a different agent per key, which very few people do, your same agent will give out any of your keys that it has stored, regardless of which key you actually used to hit the remote machine.
If somebody is in a position to get some of your keys off a machine, they're almost certainly in a position to get all of them. As such, having multiple private keys per system doesn't provide much additional security, it only increases confusion.
One of the only threats that separate keys does protect against is if you suspect multiple remotes would be compromised and being able to link your public key to both would be dangerous. But in that case, you also need to be doing so many other things to ensure your single source machine cannot be linked to both remote systems.
However, it tries to keep one agent running forever, which the OP doesn't like.
I am frequently in situations, like using cygwin, where I don't have a nice graphical shell to kill the agent / keyring when I log out.
Though I don't often log out either, unless I need to reboot for an OS upgrade. I don't know, either you're going to rely on the screen lock for security, or you aren't.
As for mixing work with personal stuff, I've created multiple accounts on my laptop for each to more easily keep them separate.
If you type in all your connection details by hand every time you ssh (can't store them anywhere, or the bad guys will see the servers you use), your shell doesn't log your ssh command lines in history, you don't mind having no idea what's actually in your known_hosts file, and you think attackers who care will be unable to dictionary-crack your hashes, then HashKnownHosts will accomplish something for you. Otherwise it's dumb, IMO. Open to hearing about something I've missed, though, or just people whose usecase differs enough that my points don't apply to them.