[vngzs]

From a defense standpoint, one should consider "shell on a box" to usually mean attackers can get root on a box. If they can get persistence, they can wait for a kernel CVE to abuse.

Now, if you're just using a bastion as a jump host, you don't need to offer shells on it. Just allow people to proxy a port to behind the bastion and be done with it.

    PermitTTY no
    ForceCommand /usr/sbin/nologin
    AllowTcpForwarding yes
    AllowAgentForwarding no

[mlyle]

I suggest:

   AllowAgentForwarding no
   AllowTcpForwarding yes
   X11Forwarding no
   PermitTunnel no
   GatewayPorts no
   PermitOpen *:22
   ForceCommand echo 'Nope'

Then:

    ssh -J finaluser@finalhost user@bastion

You can nicely use your local agent, etc. Bastion is relatively hardened. Etc.

[staticassertion]

I think it's probably reasonable when performing your incident response or even threat modeling to assume the attacker has or could escalate privileges. The linked article doesn't discuss anything that would make that harder, although perhaps practices like staying patched and minimizing attack surface are somewhat assumed (they do bring up choosing your OS based on minimizing attack surface for example).

There's also a lot you can do to harden that boundary. You can harden your kernel, you can execute user's shells in constrained environments like docker containers or restricted shells, leverage sandboxing technologies like apparmor or selinux, etc.

The user/root boundary can be a lot thinner than people expect, so I get why you'd want to point out that reliance on the attacker not escalating should be met with an evaluation of that boundary, but I think it may be understating the boundary to unconditionally not trust a host based firewall, or to say that getting onto the bastion itself is enough to disable the firewall when it does indeed require escalation.

[sigjuice]

Is finer grained control over TCP forwarding possible? e.g. allow forwarding only to certain TCP ports?

[mlyle]

"PermitOpen *:22"