Bypassing Authentication on SSH Bastion Hosts

Characterizing this software feature as an "attack" or "backdoor" is pretty hyperbolic. In order to abuse multiplexing, the adversary needs local code execution ability, by which point you've already lost.

Why not a patch to openssh to disable multiplexing on the server? At least as an option.

In our team, we always use an ssh-agent, and require it to confirm, via popup, each use:<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ssh-agent#Security_issues" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ssh-agent#Security_issues</a><p>&gt; There is a procedure that may prevent malware from using the ssh-agent socket. If the ssh-add -c option is set when the keys are imported into the ssh-agent, then the agent requests a confirmation from the user using the program specified by the SSH_ASKPASS environment variable, whenever ssh tries to connect.

dont people authenticate indiviually using their own credentials on a common bastion host? that seems quite odd to me and like the actual issue here. if you got root already on the bastion host there are quite a few ways to obtain credentials i would guess...

Are there really ssh bastions which allow arbitrary command execution? This seems dangerous.<p>Limiting remote commands to port forwarding only will severely hamper this kind of attack, and will prevent ForwardAgent hacks as well.

Seems similar to SSH Agent Hijacking - mostly useful for red teaming only - because you need to compromise the Engineer&#x2F;SRE&#x2F;DevOps person first.

Any way to read this article without Javascript?