[reidacdc]

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.

[upon_drumhead]

Or even better, use ProxyJump and don’t forward your agent at all :)

[aarmenaa]

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.

[lxgr]

Agent forwarding has its uses; not all of them can be replaced by ProxyJump.

[GauntletWizard]

I never need to SSH directly into servers. When I do, I need to be able to clone private git repos. ssh agent forwarding is the right answer.

[sureglymop]

To go further, use a VPN that uses UDP and only allow that connection after port knocking three randomly chosen ports.

[ThePowerOfFuet]

This is way overkill when you could simply use Wireguard instead.

[sureglymop]

Not really, its just a few lines in your nftables/iptables rules. And sure, wireguard is great. It's just an underrated trick from decades ago. :)