SSH ProxyCommand and Host-Based Authentication: Which Host Signs?

A target can see a TCP connection coming from the bastion while the SSH client performing authentication still runs on the workstation.

Host behind-bastion
    ProxyCommand ssh -W %h:%p bastion

Here the helper logs into bastion and asks its SSH server for a forwarded connection to the target. The workstation’s outer SSH client exchanges the target’s SSH protocol through that stream. The bastion supplies transport; it has not started the target-facing SSH client.

That distinction matters for host-based authentication. OpenSSH’s ssh-keysign helper accesses local host keys to generate the required signature. A network source address belonging to bastion does not make the workstation sign with bastion’s host key.

Compare that with:

ssh -t bastion ssh target

This starts another SSH program on bastion. Its local configuration and available host keys belong to that machine, so it can participate in an already configured bastion-to-target host-based trust arrangement. It still needs the target’s corresponding authorization and name checks.

The second form also changes how the session works: it runs a remote command and uses a terminal. It is not a transparent replacement for every SSH file-transfer or automation transport. Choose the arrangement according to which machine should authenticate to the target, rather than weakening server trust checks to make the source address appear sufficient.