SSH代理转发不直接劫持凭证，但启用-A参数会使远程服务器获得调用本地ssh-agent权限，一旦跳板机等被攻陷，攻击者即可冒用所有已加载密钥访问私有仓库、API及内网资源；应禁用ForwardAgent yes，服务端配置AllowAgentForwarding no，并采用部署密钥替代用户密钥。
SSH代理转发本身不直接“劫持”凭证，但启用 ssh -A（Agent Forwarding）会让远程服务器获得对你本地 ssh-agent 的实时调用权限——这意味着只要攻击者控制了你连接的那台服务器（比如跳板机、CI构建机或不可信开发环境），就能以你的身份反复签名、访问所有已加载密钥能到达的系统，包括私有Git仓库、内部API、甚至其他跳转目标。
禁用无必要代理转发
默认关闭代理转发是最直接的防线。检查客户端配置文件 ~/.ssh/config，确保没有全局或主机级设置：ForwardAgent yes
若必须临时启用，改用显式、单次、带超时的命令：ssh -o ForwardAgent=yes -o ConnectTimeout=10 user@host
避免在自动化脚本、CI/CD流水线或IDE远程连接中静默开启（如 VSCode Remote-SSH 默认开启，需手动关掉）。
用部署密钥替代用户密钥
对 Git 拉取等场景，不要让远程机器调用你的个人 agent，而是为每个服务单独生成最小权限密钥：
• 为 GitHub/GitLab 项目添加 deploy key，并限制为只读、仅限该仓库
• 避免将个人私钥（id_ed25519）加入 ssh-agent 后再转发
• 密钥命名清晰，例如 git-deploy-prod-db，便于审计和轮换
验证远程端是否已暴露 agent
登录目标服务器后立即执行两步检查：
• echo $SSH_AUTH_SOCK —— 若输出非空路径（如 /tmp/ssh-Abc123/agent.4567），说明已转发
• ssh-add -l —— 若列出你的本地密钥指纹，证明远程端真能调用你的 agent
发现异常时，立刻退出并排查本地 SSH 命令或 IDE 插件是否误启用了 -A
服务端加固与最小权限策略
仅靠客户端控制不够，服务端也需设防：
• 在 /etc/ssh/sshd_config 中明确禁止：
AllowAgentForwarding no
PermitTunnel no
GatewayPorts no
• 对必须开放转发的跳板机，配合 RBAC 限制可访问的目标地址与端口（如只允许连 10.10.20.0/24:22,3306）
• 定期扫描暴露的 SSH_AUTH_SOCK 路径（Shodan 曾发现超 4.6 万台服务器存在此风险）
