ssh代理转发需逐跳显式启用forwardagent yes且跳板机sshd_config中allowagentforwarding必须为yes，否则链路中断；ssh -i直接连接不触发转发因未设置ssh_auth_sock。
SSH代理转发（Agent Forwarding）不是把私钥文件发到远端，而是让本地 ssh-agent 的签名能力逐跳透传；只要中间任何一跳没配对或被禁用，链路就在那断掉——这不是连不上，而是远端压根拿不到你的密钥指纹。
为什么 ssh -i ~/.ssh/id_rsa 无法触发 Agent Forwarding
OpenSSH 明确禁止磁盘私钥通过 ForwardAgent yes 暴露，这是硬性安全策略，不是配置遗漏。直接 ssh -i 启动的连接不会设置 SSH_AUTH_SOCK，子进程自然继承不到认证上下文。
-
ssh-add -l在跳板机或目标机上为空 → 说明 agent 没透传过去 - 即使
echo $SSH_AUTH_SOCK有输出，也不代表密钥可用；必须运行ssh-add -l看指纹是否匹配本地 - 正确做法：先
eval $(ssh-agent)启动 agent，再ssh-add ~/.ssh/deploy_key加载密钥（带密码的只输一次）
~/.ssh/config 必须逐跳显式声明 ForwardAgent yes
转发不是“开一次全局生效”，而是每跳都得明确告诉 SSH 客户端：“请把 agent socket 往下传”。ProxyJump 能自动继承 ForwardAgent yes，但仅限它直连的目标；若你在跳板机上手动再连第三台，那第三台的 Host 块也得单独写 ForwardAgent yes。
- 第一跳（跳板机）：
Host bastion块里必须含ForwardAgent yes - 第二跳（如 app-server）：
Host app-server块中用ProxyJump bastion+ForwardAgent yes（自动继承，但显式写上更稳妥） - 避免
Host *放在 config 开头——它会覆盖后面所有具体 Host 的设置 - 不要混用
IdentityFile和ssh-add加载不同密钥，否则远端可能选错 key
跳板机必须允许代理继续往下传（sshd_config 关键项）
跳板机不持有私钥，但它得当“中转站”；如果它的 /etc/ssh/sshd_config 里 AllowAgentForwarding 是 no 或被注释掉，默认值虽为 yes，但很多加固模板会关掉它——链路就卡在这儿。
- 检查命令：
grep AllowAgentForwarding /etc/ssh/sshd_config，确认输出是AllowAgentForwarding yes - 改完不用重启
sshd，保存即生效 - 跳板机上完全不需要放私钥、不需要运行
ssh-add、也不该有~/.ssh/config干扰转发逻辑 - 顺手检查：
PasswordAuthentication no必须启用，防止攻击者降级到密码登录
验证是否真正在最末端拿到签名能力
只看 $SSH_AUTH_SOCK 有值，是最低限度；真正关键的是远端能否调用你本地加载的密钥完成签名。很多故障发生在“看起来连上了，但 git clone 或 rsync 失败”，原因就是这一步没过。
- 登录最后一跳后，运行
ssh-add -l，输出应与本地完全一致（指纹相同） - 从倒数第二跳执行：
ssh -o LogLevel=DEBUG2 target-host，日志中出现debug2: key: /home/user/.ssh/id_rsa (0x...)才算成功 - 如果失败，优先查跳板机的
AllowAgentForwarding，其次查本地 config 中对应Host块是否漏了ForwardAgent yes
最容易被忽略的是：跳板机的 sshd_config 默认可能被加固脚本设为 AllowAgentForwarding no，而你根本没意识到它需要改——它不像客户端配置那样能一眼看到，得 ssh 进去查，且很多人以为“只要我本地配对了就行”。
