禁用代理转发需服务端配置AllowAgentForwarding no并配合客户端禁用ForwardAgent、密钥时效管控及Jump Host替代方案。单设服务端禁用不足，因客户端若仍启用agent forwarding且连未加固跳板机，私钥仍可被远程调用。
直接禁用代理转发（AllowAgentForwarding no）是阻断“跳板机反向劫持本地私钥”的关键一环，但仅靠这一项配置远远不够——它只是防线中的一环，必须配合客户端行为约束与密钥管理策略才能真正生效。
为什么单设 AllowAgentForwarding no 不够？
黑客常利用已被攻陷的跳板机（如中间 SSH 服务器），在用户启用 agent forwarding 的前提下，通过 ssh -A 连接该跳板后，再从跳板机发起对内网其他主机的连接。此时，远端服务可调用跳板机上运行的 ssh-agent，间接使用你本地未加密加载的私钥完成认证——你的私钥从未离开本机，却实际被远程滥用。
而 AllowAgentForwarding no 仅在服务端拒绝协商该功能，前提是：客户端确实发起了 agent forwarding 请求。如果运维人员在本地习惯性启用 ForwardAgent yes（尤其在 ~/.ssh/config 中全局配置），且跳板机服务端未禁用，攻击者就能得逞。
服务端必须做的硬性关闭
编辑 /etc/ssh/sshd_config，确保以下配置存在且未被注释：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
AllowAgentForwarding no—— 禁止任何用户开启 agent forwarding -
PermitUserEnvironment no—— 防止攻击者通过环境变量注入伪造的 SSH_AUTH_SOCK 路径 -
IgnoreRhosts yes和RhostsRSAAuthentication no—— 关闭过时且易被绕过的信任机制
保存后执行：sudo sshd -t && sudo systemctl restart sshd
验证是否生效：sudo sshd -T | grep -i "agent\|forwarding" → 输出中应含 allowagentforwarding no
客户端必须同步清理与加固
即使服务端已关，若本地仍保留 agent forwarding 习惯，一旦误连未加固的跳板机，风险立即回归：
- 检查并清除全局或 Host 特定的
ForwardAgent yes配置，统一改为：ForwardAgent no（写入~/.ssh/config全局块或对应 Host 块） - 避免在终端中手动执行
ssh -A user@host；如确需临时启用，务必加-o ForwardAgent=no覆盖 - 日常不运行
ssh-agent，或仅在明确需要时按需启动，并用ssh-add -t 300限定密钥加载有效期（5分钟） - 定期运行
ssh-add -l查看当前加载的密钥，异常时立即ssh-add -D清空
替代方案：彻底放弃 agent forwarding，改用更安全的登录链路
对高敏环境，推荐完全规避 agent forwarding 的使用场景：
- 运维人员使用独立、短期有效的 ED25519 密钥对，且私钥始终带密码保护
- 跳板机不存任何私钥，只做连接中转；内网目标主机通过
AllowUsers+ IP 白名单 + 证书 CA 认证严格准入 - 敏感操作走 Jump Host 模式（
ProxyJump），而非ProxyCommand + ssh -A组合 - 所有跳板机强制启用
ForceCommand限制为只允许nc %h %p类隧道命令，杜绝任意 shell 交互
做到服务端拒收、客户端不发、运行时不驻留、链路不依赖，才能真正切断私钥被远程“意念调用”的路径。
