ssh -i 无法完成链式转发，因为OpenSSH硬编码禁止将磁盘私钥通过代理转发暴露给远端；只有本地ssh-agent加载的内存中密钥镜像才能经SSH_AUTH_SOCK透传，且每跳必须显式配置ForwardAgent yes。
不能靠 ssh -i 实现链式转发，必须用 ssh-agent + ssh-add + 逐跳 ForwardAgent yes 配置，否则私钥根本传不过去。
为什么 ssh -i 无法完成链式转发
OpenSSH 明确禁止将磁盘上的私钥文件通过代理转发暴露给远端——这是硬编码的安全策略，不是配置能绕过的。你执行 ssh -i ~/.ssh/deploy_key -A user@B，B 上的 ssh-add -l 一定为空，echo $SSH_AUTH_SOCK 虽有值，但里面没密钥。
真正起作用的是本地 ssh-agent 进程持有的解密后私钥内存镜像，它通过 SSH_AUTH_SOCK 环境变量被子进程继承，并在每次 SSH 连接时由客户端主动透传 socket 路径。这个机制只对已加载进 agent 的密钥生效。
- 先运行
eval $(ssh-agent)启动 agent（Bash/Zsh 下必须用eval，否则环境变量不进当前 shell） - 再运行
ssh-add ~/.ssh/deploy_key加载——带密码的会提示输一次，之后全程免密 - 验证：运行
ssh-add -l应看到指纹，env | grep SSH_AUTH_SOCK应非空
如何让 A → B → C 的三级转发真正生效
转发不是“设一次全局生效”，而是每跳都需显式声明。B 必须既接受来自 A 的代理，又主动向 C 转发，缺一不可。
- A 连 B：命令行加
-o ForwardAgent=yes，或在~/.ssh/config中写Host B\n ForwardAgent yes - B 连 C：不能只靠 A 的转发“自动延续”，必须在 B 的
~/.ssh/config（注意是 B 上的文件！）里为Host C单独设置ForwardAgent yes - B 的
/etc/ssh/sshd_config必须含AllowAgentForwarding yes（默认开启，但若被禁用则整条链断裂） - 验证链路：登录 B 后执行
ssh -o LogLevel=DEBUG2 C，日志中出现debug2: key: /home/user/.ssh/id_rsa (0x...)才表示密钥已透传到 C
~/.ssh/config 是唯一可控的集中管理点
硬编码 -o 参数易遗漏、难维护；ssh-agent 本身不记路由逻辑，全靠 config 文件驱动行为。多服务器场景下，它就是你的转发控制平面。
- 每个
Host块必须唯一且具体，避免Host *放前面覆盖后续规则 - 用
ProxyJump替代手动跳转：比如Host C\n ProxyJump B\n ForwardAgent yes，此时ForwardAgent会沿跳转链自动生效，比手动连 B 再连 C 更可靠 -
IdentityFile指定私钥路径，仅影响该 Host 的认证发起方，和 agent 加载无关；不要在 config 里混用IdentityFile和ssh-add加载不同密钥，容易错乱 - 生产环境建议禁用密码登录：
Host B C\n PasswordAuthentication no，防止 fallback 到弱认证
转发链路上最容易被忽略的安全边界
整个机制的安全前提是：中间跳板机（如 B）是可信的。一旦攻击者拿到 B 上的 shell 权限，且 SSH_AUTH_SOCK 仍有效，他就能用你的身份向任意目标发起认证请求——这就是 agent hijacking。
这意味着：
- 不要对公网暴露的跳板机启用
ForwardAgent yes，哪怕只开一小时 - 临时转发优先用
ssh -A命令而非 config 全局开启 - 退出终端前运行
ssh-add -D清空 agent，尤其在共享机器上 - 如果 C 是生产 GPU 节点，更推荐用
ProxyJump+certificate-based auth替代纯 agent forwarding
