SSH 代理转发安全风险：如何避免 SSH Agent 劫持攻击

应禁用SSH代理转发，因ssh -A会将本地ssh-agent控制权交予远程服务器，导致私钥签名能力被劫持；需客户端和服务端双端禁用ForwardAgent no与AllowAgentForwarding no，并配合部署密钥、LocalForward端口映射及升级至OpenSSH 9.3p2+。

SSH 代理转发（ssh -A）本身不传输私钥，但会把本地 ssh-agent 的控制权交给远程服务器——只要那台机器被攻陷，攻击者就能用你的身份反复签名、登录其他系统，且全程无声无息。防范重点不是“怎么安全地转发”，而是“不让它转发”。

立刻检查是否已暴露 agent

登录目标服务器后，马上执行两行命令：

• echo $SSH_AUTH_SOCK —— 若输出类似 /tmp/ssh-Abc123/agent.4567 的路径，说明 agent 已被转发
• ssh-add -l —— 若列出你的本地密钥指纹，证明远程端真能调用你的私钥签名

只要任一结果非空，风险就已存在。别等出事再查，每次连接后都应养成这个习惯。

禁用转发：从客户端和服务端双锁死

单靠一端控制容易失效，必须两端同时设防：

• 客户端：在 ~/.ssh/config 中为跳板机、CI 主机等高危目标显式关闭：

  Host bastion.example.com<br>  ForwardAgent no

• 服务端：编辑 /etc/ssh/sshd_config，确保有：

  AllowAgentForwarding no<br>PermitTunnel no<br>GatewayPorts no

• 临时连接时也别依赖 -A，改用：
  ssh -o ForwardAgent=no user@host

用部署密钥替代个人密钥

Git 拉取、服务部署等常规操作，完全不需要你本人的密钥。应该为每个用途单独生成最小权限密钥：

• 生成专用密钥：ssh-keygen -t ed25519 -f ~/.ssh/deploy-web-prod -C "web deploy key"
• 只添加到 GitHub/GitLab 对应仓库的 Deploy keys，并设为只读
• 服务端配合限制：在 authorized_keys 中加 command="git-shell",no-pty，禁止交互式登录

改用 LocalForward 实现内网访问

很多运维误以为“连内网就得开 -A”，其实只是混淆了网络通道和身份认证：

• 先普通登录跳板机（ForwardAgent no）
• 再用端口映射连内网服务：ssh -L 8080:192.168.10.50:80 user@bastion
• 本地访问 http://localhost:8080 即可，全程不涉及密钥代理，也不暴露 SSH_AUTH_SOCK

升级 OpenSSH 并验证防护状态

CVE-2023-38408 漏洞允许攻击者通过转发套接字远程加载恶意模块执行代码。旧版 OpenSSH 风险极高：

• 检查版本：ssh -V，确认 ≥ OpenSSH_9.3p2
• 登录跳板机后运行 ssh-add -l，若报错 "Could not open a connection to your authentication agent"，说明未转发或已被隔离
• 对无法升级的旧系统，必须叠加 ForwardAgent no + 部署密钥 + LocalForward 三重防护