应禁用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三重防护
