SSH ProxyCommand 与基于主机的认证：哪个主机签名？

目标能看到来自堡垒机的 TCP 连接，而执行认证的 SSH 客户端仍在工作站上运行。

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

这里，辅助程序登录堡垒机，请求其 SSH 服务器提供一条到目标的转发连接。工作站外侧的 SSH 客户端通过该流转发目标的 SSH 协议。堡垒机只提供传输；它并未启动面向目标的 SSH 客户端。

这一区分对基于主机的认证很重要。OpenSSH 的 ssh-keysign 辅助程序访问本地主机密钥以生成所需签名。源地址属于堡垒机，并不会让工作站用堡垒机的主机密钥签名。

与之对比：

ssh -t bastion ssh target

这会启动堡垒机上的另一个 SSH 程序。它的本地配置和可用主机密钥属于那台机器，因此可以参与堡垒机到目标之间已配置好的基于主机的信任安排。它仍需要目标端相应的授权和名称检查。

第二种形式还改变了会话的工作方式：它执行远程命令并使用终端。它并不能透明替代所有 SSH 文件传输或自动化传输。应根据应由哪台机器向目标认证来选择方案，而不是削弱服务器信任检查，让源地址看起来足够。