This article helped me evolve my understanding of the impact of the recent openssh vuln, CVE-2023-38408. Gaining RCE on the source system is more valuable if you consider that the vulnerable machine is likely using ssh-agent to connect to other hosts, which makes pivoting potentially much easier.
> So, is this a vulnerability? Well no, not exactly [...]
Connecting to a compromised machine with `ssh -A` (agent forwarding) lets the attacker use your credentials for ssh sessions elsewhere. It's almost explained in the man page.
I'm a big fan of tools like secretive[1] that can help solve this problem by using biometrics to shift the UX/security trade-off and thus make it feasible to always require some kind of authentication to sign a token with a key.
I'm not aware of any tools that do the same for Linux, and a quick Google search doesn't turn up much[2]. It does look like you can at least get a notification[3], though.
This could provide another layer of protection on the user's endpoint device in addition the network monitoring called out in the article. Defense in depth, and all that.
Not using SSH to configure a machine is smart, but saying no SSH at all is not feasible for many things. When something goes wrong, you need to be able to connect to a running machine and poke around, and you don’t know how you will need to poke until you are doing it.
The statement "SSH keys are just long passwords" in your linked post is a huge red flag that you don't understand enough about how they work and are in no position to dispense advice (that anyone sane should heed) on the subject.
To start (but it would be a longer discussion), passwords can be captured as you type them into a compromised host, SSH keys can't. Also SSH keys can reside on a security device (TPM, smartcard, HSM, security token, whatever) and this way they can _never_ be captured, barring exploits on those hardware devices, even if your workstation is compromised. Some hardware security devices have features like touch-to-authorize, or even biometrics, for every single usage. SSH keys can be _used_ while unlocked, but not from a compromised remote site (unless you do agent forwarding, which this article is all about), and never captured from there. Passwords have literally _none_ of the above features.
Forwarding usually bad. SSH Keys otherwise good. Passwords so bad they're not worth comparing to anything.
(and yeah, there's stuff even better than SSH keys)
It works as advertised. It's a bit clunky to use since it applies to the whole ssh agent, so if you only want it to apply to a specific ssh connection you have to spawn a new agent (unless somebody teaches me a better trick).
Example scenario:
I'm on my laptop and I use ssh-agent with my key stored on a HSM device. I use it many many times every hour to interact with my git servers and jumping to other machines. It's kn my laptop so I don't want to fiddle with further restrictions.
I also have to ssh on a remote machine where I would like to restrict agent forwarding to only perform for a selected hosts (mostly so I can git pull from private repos)
Nice article, although the title is slightly off. The private key is not compromised (as described agent forwarding uses a challenge-response method) and the attacker can only initiate connections as long as the agent is being forwarded.
Not mentioned in the article, but if you add the key to your agent with "ssh-add -c <key>", then whenever the key is used to connect to another machine by the agent, the agent will prompt (on the machine where it was initially run) to confirm that the connection is intended, generally via "ssh-askpass".
In my world, I use this routinely, precisely to detect a connection using a hijacked session, as described in the article. It does not detect the agent hijacking itself, it only detects new connections -- it pops up for all connections, both intended and unintended.
I know we're all supposed to do defense in depth, but I confess to having a bit of a jaundiced view of attacks that begin, "first, become root on a machine in the target domain....". Containment is a good idea, but if you're at the point where you're doing containment of compromised root accounts "inside", things have gone pretty far wrong already.
I'm moving towards this for my current workplace. SSH will only be allowed via VPN, only to a bastion, and that bastion will not permit agent forwarding, or really much of anything other than ProxyJump. I'm baffled that agent forwarding is a feature when OpenSSH won't even use a key file if the permissions are wrong.
Yes, your local agent can be accessed on the destination host by any other user with the necessary privileges (including your own account -- a root compromise is not required). This has been known for a very long time and a warning is included in the documentation. No, it does not compromise any private keys.
Your private keys are more likely to be compromised when you store them on untrusted systems. SSH-Agent allows you to avoid that risk.
Another mitigation is to use a dedicated agent per private key (or group of keys) to prevent forwarding keys to destinations that don't need them.
SSH agent restriction (ssh-add -h) looks promising, but support isn't widespread and it doesn't cover all use cases.
The article assumes a remote attacker, but the attacker can more easily be your boss or team. Keep this in mind whenever you forward your agent and plan accordingly.
27 comments
[ 2.6 ms ] story [ 33.5 ms ] threadConnecting to a compromised machine with `ssh -A` (agent forwarding) lets the attacker use your credentials for ssh sessions elsewhere. It's almost explained in the man page.
Avoid the agent forwarding and you are fine.
I'm a big fan of tools like secretive[1] that can help solve this problem by using biometrics to shift the UX/security trade-off and thus make it feasible to always require some kind of authentication to sign a token with a key.
I'm not aware of any tools that do the same for Linux, and a quick Google search doesn't turn up much[2]. It does look like you can at least get a notification[3], though.
This could provide another layer of protection on the user's endpoint device in addition the network monitoring called out in the article. Defense in depth, and all that.
[1] https://github.com/maxgoedjen/secretive
[2] https://unix.stackexchange.com/questions/705144/unlock-an-ss...
[3] https://www.insecure.ws/2013/09/25/ssh-agent-notification.ht...
https://substack.com/@rakkhi/note/c-40163543?r=1afqp
SSH keys are also not “just long passwords” at all.
To start (but it would be a longer discussion), passwords can be captured as you type them into a compromised host, SSH keys can't. Also SSH keys can reside on a security device (TPM, smartcard, HSM, security token, whatever) and this way they can _never_ be captured, barring exploits on those hardware devices, even if your workstation is compromised. Some hardware security devices have features like touch-to-authorize, or even biometrics, for every single usage. SSH keys can be _used_ while unlocked, but not from a compromised remote site (unless you do agent forwarding, which this article is all about), and never captured from there. Passwords have literally _none_ of the above features.
Forwarding usually bad. SSH Keys otherwise good. Passwords so bad they're not worth comparing to anything.
(and yeah, there's stuff even better than SSH keys)
https://www.openssh.com/agent-restrict.html
Example scenario:
I'm on my laptop and I use ssh-agent with my key stored on a HSM device. I use it many many times every hour to interact with my git servers and jumping to other machines. It's kn my laptop so I don't want to fiddle with further restrictions.
I also have to ssh on a remote machine where I would like to restrict agent forwarding to only perform for a selected hosts (mostly so I can git pull from private repos)
Can I do this with one agent?
In my world, I use this routinely, precisely to detect a connection using a hijacked session, as described in the article. It does not detect the agent hijacking itself, it only detects new connections -- it pops up for all connections, both intended and unintended.
I know we're all supposed to do defense in depth, but I confess to having a bit of a jaundiced view of attacks that begin, "first, become root on a machine in the target domain....". Containment is a good idea, but if you're at the point where you're doing containment of compromised root accounts "inside", things have gone pretty far wrong already.
Your private keys are more likely to be compromised when you store them on untrusted systems. SSH-Agent allows you to avoid that risk.
Another mitigation is to use a dedicated agent per private key (or group of keys) to prevent forwarding keys to destinations that don't need them.
SSH agent restriction (ssh-add -h) looks promising, but support isn't widespread and it doesn't cover all use cases.
The article assumes a remote attacker, but the attacker can more easily be your boss or team. Keep this in mind whenever you forward your agent and plan accordingly.
Just no.
And I'll notice when it's blinking but it shouldn't be and just unplug it :)