4 ms·

> 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 agen

> 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 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 https://news.ycombinator.com/item?id=26078305 [0] https://jekhokie.github.io/linux/ssh/security/hijacking/2019/09/07/ssh-agent-hijacking.html https://jekhokie.github.io/linux/ssh/security/hijacking/2019... [1] https://userify.com/docs/jumpbox https://userify.com/docs/jumpbox [2] https://userify.com https://userify.com

TimWolla 6y ago
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.
- jamiesonbecker 6y ago
  This slightly reduces risk, but it's inconvenient and probably better to just use agent forwarding as little as possible.
- yencabulator 6y ago
  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.
inetknght 6y ago
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.
- jamiesonbecker 6y ago
  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.

TimWolla 6y ago

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.

jamiesonbecker 6y ago
This slightly reduces risk, but it's inconvenient and probably better to just use agent forwarding as little as possible.
yencabulator 6y ago
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.

inetknght 6y ago

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.

jamiesonbecker 6y ago
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.