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".<p>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.<p>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.
> So, is this a vulnerability? Well no, not exactly [...]<p>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.<p>Avoid the agent forwarding and you are fine.
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.
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.<p>Your private keys are more likely to be compromised when you store them on untrusted systems. SSH-Agent allows you to avoid that risk.<p>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.<p>SSH agent restriction (ssh-add -h) looks promising, but support isn't widespread and it doesn't cover all use cases.<p>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.
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.
Good find! I was always curious how this worked.<p>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.<p>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.<p>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.<p>[1] <a href="https://github.com/maxgoedjen/secretive">https://github.com/maxgoedjen/secretive</a><p>[2] <a href="https://unix.stackexchange.com/questions/705144/unlock-an-ssh-private-key-with-a-biometric-token-instead-of-a-passphrase" rel="nofollow noreferrer">https://unix.stackexchange.com/questions/705144/unlock-an-ss...</a><p>[3] <a href="https://www.insecure.ws/2013/09/25/ssh-agent-notification.html" rel="nofollow noreferrer">https://www.insecure.ws/2013/09/25/ssh-agent-notification.ht...</a>
Hijack my ssh-agent but you're not using my ssh key for lateral movement unless I touch my Yubikey for you.<p>And I'll notice when it's blinking but it shouldn't be and just unplug it :)