Securing my personal SSH infrastructure with Yubikeys
dzombak.com
dzombak.com
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!
But yes, maybe yubikey-agent is nicer to use. I've not tried it myself.
But in any case it's not true that you need it.
$ curl -I 'https://www.dzombak.com/blog/2021/02/Securing-my-personal-SSH-infrastructure-with-Yubikeys.html' -H 'Referer: https://example.com'
HTTP/1.1 200 OK
*snip*
$ curl -I 'https://www.dzombak.com/blog/2021/02/Securing-my-personal-SSH-infrastructure-with-Yubikeys.html' -H 'Referer: https://news.ycombinator.com/'
HTTP/1.1 302 Moved Temporarily
*snip*
Location: https://supporters.eff.org/donate/join-eff-today
*snip*It would be better to delete the blog post. Now we have this "fake news" out there to be indexed forever. :-(
It's currently redirecting to HN start page.
https://www.stavros.io/posts/u2f-fido2-with-ssh/
It is much much easier and less error-prone, and compatible with any U2F key (not just Yubikey).
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.
Access your servers only from your administration environment/workstation and it will solve the problem.
Do not use agent forwarding, you are still one vulnerability away from bad surprises.
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.
EDIT: see also Stavrosk's excellent link: https://news.ycombinator.com/item?id=26078305
[0] https://jekhokie.github.io/linux/ssh/security/hijacking/2019...
-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.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.
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...
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 )
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
>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.