Old is not always bad. PKCS#11 is a standard. In fact it's the reason why that method also works on Windows, something the author hasn't looked into yet.
But yes, maybe yubikey-agent is nicer to use. I've not tried it myself.
Any idea why the author would do that? It will simply reduce exposure, which is contrary to the intent of writing a blog article. Besides, I doubt anyone would want to donate based on an unexpected redirect with no path forward to the intended destination.
I think maybe he doesn't like the reception he got in the comments. It can pretty much be summarized as "this is bad advice for these multiple reasons".
It would be better to delete the blog post. Now we have this "fake news" out there to be indexed forever. :-(
It's great if you're happy having (effectively) one SSH keypair to log into _every_ service you might potentially log into.
The minute you "wrongly" "ssh -A" into a pwned box, forwarding the agent - it's game over and they've now access to _all_ your infrastructure.
Using different SSH keypairs "per environment" might be more fiddly (but "ssh-ident" helps) but ensures a wrong "ssh -A" to a pwned box can only potentially cause a _part_ of your infra to be pwned.
Yubikey 5 series have some 20 extra slots you could use to store more keys. I'm not sure if yubikey-agent would have out-of-the-box support for that, but choosing a slot is just a single integer in the code, and you can enumerate them all too.
> I wanted to ensure that, should an attacker gain access to one of my servers, they can’t use that access to move onto any other computer I control... SSH agent forwarding is used to allow me to SSH from one server
Unfortunately, that is exactly what SSH agent forwarding allows: using that access to move onto other computers you control, because agent forwarding allows an attacker to hijack your connection[0]
Ironically, it would be almost certainly safer to use no Yubikey at all (which only protects the keys that are stored on your workstation) rather than using Agent Forwarding. At least without agent forwarding, the attacker would at least have to gain access to your laptop.
SSH agent forwarding is a tool that should only be used in very limited situations.
Use proxyjump instead: https://userify.com/docs/jumpbox [1] (disclaimer, co-founder of Userify, which essentially keeps your authorized_keys in sync across all of your servers[2])
It's not a bad idea to use one private key per device; for example one for your desktop, one for your laptop. Label them with which is which (whether you use Userify to manage your SSH logins or not). Then, if you lose your laptop, you can remove your laptop's key from all servers without needing to also revoke your desktop's key.
There's no need to use a separate private key for each client or each business function. The definition of the public key is such that your clients cannot derive the private key from the public key. (Of course, if you have to share the private key with someone else, like on a work computer that your IT team has access to, then you should still generate a separate key for them.)
Yubikeys are still an excellent choice to protect your keys; just not as described in this article.
SSH agents are generally insecure by default and they don't present any useful information for auditing. Not only that but there's probably a half dozen different SSH agents installed and running on your Linux desktop right now. GNOME starts its own, GPG agent (oh god...) can act as one, openssh starts one, and if you try to disable one or any of them sometimes there's a fallback CLI agent that tries to start and run.
All of them have insanely insecure defaults: aggressively cache every unlocked key and present every unlocked key to anyone who asks (which is anyone who can connect to the agent) without even so much as asking the user if some rogue process should be permitted to access the key.
You can't uninstall the agents either. It's a non-optional part of each of those packages. You won't find all of them, anyone can start one, and any client will try to connect to it by default. If you mark it as non-executable then it will be re-marked as executable on the next package update. You can't put it as a symlink to /dev/null. Even truncating it and using SELinux to mark it as a file isn't guaranteed to keep the damn thing off after a system update.
It's a f!@#$ing virus symptom.
All because some users are too lazy to type their SSH passphrase more than once.
Agreed. But the reason why might be because agent caching was a lot more difficult 20 years ago. It was a pain, especially for new users; you had to start the agent and then launch a new bash session, until Daniel Robbins wrote GNU keychain as part of Gentoo. Now, however, it's turned into a crazy mess of insecurity.
It is possible to require confirmation before `ssh-add` allows to use a key. From `man ssh-add`:
-c Indicates that added identities should be subject to confirmation
before being used for authentication. Confirmation is performed
by ssh-askpass(1). Successful confirmation is signaled by a zero
exit status from ssh-askpass(1), rather than text entered into
the requester.
The stupidest thing is that `-c` gives you no information about what you're approving. All an attacker needs to do is race an actual ssh call, and you'll happily okay it.
Yubikeys are awesome for ssh...
The problems come from yubico’s multiple apps and different places you have to configure them. On top of that, the gpg agent commands are so verbose and very annoying, especially if you just want to duplicate your key across multiple yubikeys!
Shameless plug, I also wrote an article last year that goes into this, and included setting up commit signing, and even how to duplicate your ssh key across multiple yubikeys.
I also went over how to handle using multiple keys on the same computer since the gpg agent really doesn’t like that for some reason...
I am thoroughly confused. When I click on the link above, it takes me to an Electronic Frontier Foundation donation page. If I go to dzombak.com I get to the home page of Chris Dzombak. Then going to the blog, there is a blog post titled "Securing my personal SSH infrastructure with Yubikeys" which takes me to the article which I believe is the one posted, which appears to be identical to the link above. What the hell is going on???
When you click a link, your browser sends the URL of the site where you clicked the link to the server that hosts the link you're clicking. This is called 'Referer' (sic)[0] and can be disabled in your browser [1].
Now, the owner of that blog set it up in a way that people coming fon HN (who send a Referer) are redirected. (Another user figured that out a few minutes ago: https://news.ycombinator.com/item?id=26078619 )
Yubikeys make me nervous, what happens when it breaks? or your house burns down. You need a backup password or similar which kinda defeats the point of having the key.
>You need a backup password or similar which kinda defeats the point of having the key.
So the main threat models HSMs address are 1) using keys with online systems without remote attackers being able to compromise those keys (and also potentially increasing the difficulty of performing remote hot attacks too), and 2) making it much harder to attackers in unsecure physical locations to get at original keys as well purely from theft.
Having a backup password that is kept in a safe or the like, or an airgapped system(s) in a secure room/building that all HSMs are loaded from, in no way defeats the point. The point of the token is to be able to then go out into the world and make use of those keys in places which aren't secure and on systems that are online and multiple use and thus vastly easier to compromise. The Yubikey (or any of a range of smartcards or heavier duty HSMs) ideally should mean that obtaining the original private keys at least requires physically finding and breaching the generation location (assuming the keys aren't generated on device and simply manually switched upon device breakage), and that even blackbox usage requires both physically obtaining the token and the PIN or other second factor (more sophisticated HSMs may require multiple person involvement as well). This radically shifts the economic costs for attackers.
>Yubikeys make me nervous, what happens when it breaks? or your house burns down.
If using it for on-key generation, presumably with systems that you have at least intermittent physical access to, then breakage merely means doing a manual shuffle of going around and updating certs with a new key. If that's a fairly infrequent and low probability event, there may be no further need to think about it than that. You had to setup the systems in the first place after all. Alternatively if you have keys stored offline in some manner, it's trivial to setup a new token, or to buy multiple tokens and have them all be the same (with a few kept around in a safe maybe) so that having one get destroyed involves no downtime at all, just scheduling to bring it back up to n+whatever at a future time.
No it doesn't. Even before OpenSSH added support for U2F there were multiple ways to use yubikeys to store RSA keys.
You can use PIV: https://blog.habets.se/2016/01/Yubikey-4-for-SSH-with-physic...
Or gpg-agent: https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-NEO....
I use the PIV way, and it "just works" on Windows clients too: https://blog.habets.se/2018/03/Yubikey-for-SSH-on-Windows.ht...
Also: you use agent forwarding with no touch-to-use? Yikes!