ChatGPT 转发本机 SSH：防远程 Agent 越权

为了让远程开发机或容器里常驻的 codex app-server 在断线重连后保有认证状态，ChatGPT Desktop 与 OpenAI Codex CLI 引入了动态刷新 ~/.codex/app-server-control/forwarded-ssh-agent.sock 软链并默认挂载 SSH_AUTH_SOCK 的机制。这种消除重连摩擦的设计，直接把本机全局 SSH 身份透传给了远程编程 Agent：一旦远端遭遇恶意仓库提示词注入，或远程机器存在多进程共享，Agent 就能借用你的本机私钥签名向名下任何私有 GitHub 仓库强推代码，甚至横向登录其他服务器。

该机制源于 OpenAI 工程师 abhinav-oai 在 openai/codex PR #28131（修复 Issue #22567）提交的 codex app-server proxy --forward-ssh-agent 实现，以及其在审查评论 discussion_r3410013180 中确认的桌面端启动命令，随后在 Hacker News（#50422628）获超 206 分与 71 条评论热议（注：公开 PR #28131 因超 14 天无更新被 github-actions[bot] 自动关闭，ChatGPT Desktop 正式版内置二进制是否已通过其他内部提交实装该启动链路，公开仓库未披露，待核实 [待验证]）。

本文面向使用 ChatGPT Desktop、Codex CLI、远程开发机（SSH / DevContainer）的软件工程师、DevSecOps 与研发基础设施负责人，拆解 forwarded-ssh-agent.sock 刷新逻辑与三类越权攻击面，并给出通过「SSH 配置隔离 + 硬件密钥/Secure Enclave 逐次确认 + 单仓最小凭证 + 受控 push 通道」替代全局转发的可复现步骤。

问题：为什么远程常驻 Agent 一断连就会丢掉 Git 权限

当开发者通过 SSH 连接远程 Linux 开发机，并以常驻守护进程（如 nohup codex app-server --listen unix://）运行编程 Agent 时，最常遇到的问题是「断线重连后 Git 与 SSH 认证失效」。

在标准 OpenSSH 下，开启 Agent Forwarding 后，每次建立 SSH 会话，sshd 都会在远端创建临时 Unix 域套接字（如 /tmp/ssh-XXXX/agent.12345），并将环境变量 SSH_AUTH_SOCK 指向该路径。首次连接拉起的常驻 codex app-server 及其通过 create_env 重建环境的子进程，会一直持有这个初始路径。

一旦笔记本休眠或网络抖动导致首次会话退出，远端临时套接字即被销毁。即便客户端随后重连并启动带新 SSH_AUTH_SOCK 的代理会话（codex app-server proxy），常驻 app-server 仍指向已删除的旧路径，导致后续 git fetch 或 git push 全部报错。

为抹平这一摩擦，OpenAI 在每次 proxy 重连时将新会话的 SSH_AUTH_SOCK 动态续接给远端常驻进程。但这也把原本仅在单次人工终端会话期间短暂有效的签名通道，变成了远端自治 Agent 随时可调用的常驻凭证。

机制：PR #28131 的软链刷新原理与三类越权攻击面

在 openai/codex PR #28131 修改的 codex-rs/cli/src/main.rs（新增 121 行、删除 2 行）中，软链刷新与桌面端挂载分四步完成：

1. 隐藏代理参数：在 AppServerProxyCommand 中新增 #[arg(long = "forward-ssh-agent", hide = true)]，对应 codex app-server proxy --forward-ssh-agent。
2. 校验存活套接字：代理启动时读取当前 SSH_AUTH_SOCK，在 refresh_forwarded_ssh_agent() 中用 file_type().is_socket() 验证目标确系存活套接字；若当前连接无可用 Agent，则保留原软链不动，避免冲掉其他活跃连接。
3. 原子替换固定软链：在控制套接字同级目录先建临时软链 forwarded-ssh-agent.sock.tmp.<pid>，再通过 std::fs::rename 原子替换为稳定路径 ~/.codex/app-server-control/forwarded-ssh-agent.sock。
4. 桌面端固定挂载：按作者 abhinav-oai 在 discussion_r3410013180 披露的命令，桌面端拉起远端服务时直接挂载该路径：

SSH_AUTH_SOCK=~/.codex/app-server-control/forwarded-ssh-agent.sock \
  nohup codex app-server --listen unix://

需要明确：SSH Agent 转发并不是把本机 ~/.ssh/id_ed25519 私钥文件明文拷贝到远程硬盘上，私钥始终留在本机内存中；它暴露的是通往本机 ssh-agent 的签名代理套接字。但只要远端进程能向该套接字发送摘要并拿到签名，就会打开三类攻击面：

怎么做：四步切断全局转发并收敛远程 Agent 凭证边界

要在远程服务器或 DevContainer 中安全运行编程 Agent，可按以下四步替换全局 SSH Agent 转发：

第一步：在 ~/.ssh/config 中默认禁转并隔离专用实例

部分远程工具（如 HN 评论区 eosis 提到的 DevPod）会向配置写入 ForwardAgent yes。先在本地核查最终生效配置：

ssh -G your-remote-devbox | grep -i forwardagent

若输出 forwardagent yes，立即在 ~/.ssh/config 末尾锁死全局默认禁转；确需转发的跳板机则通过 IdentityAgent 绑定只含受限密钥的独立套接字（由 ssh-agent -a ~/.ssh/agent-restricted.sock 启动）：

Host bastion-jump
    HostName jump.internal.example.com
    ForwardAgent yes
    IdentityAgent ~/.ssh/agent-restricted.sock
    IdentitiesOnly yes

Host *
    ForwardAgent no
    IdentitiesOnly yes

第二步：用硬件密钥或 macOS Secure Enclave 开启逐次确认

如果本机密钥每次签名都强制物理触摸或指纹验证，远端 Agent 就无法在后台静默发起推送或横向连接：

1. OpenSSH 8.2+ FIDO2 硬件密钥（如 YubiKey）：生成要求验证的密钥，加载时附加 -c 启用确认约束：

ssh-keygen -t ed25519-sk -O verify-required -f ~/.ssh/id_ed25519_sk
ssh-add -c ~/.ssh/id_ed25519_sk

2. macOS Secure Enclave 与 Bitwarden：在 macOS 上用 Secretive 将密钥存入 Secure Enclave 绑定每次会话 Touch ID 确认；或开启 Bitwarden Desktop 内置 SSH Agent 的逐次弹窗确认。

第三步：在远端改用单仓 Deploy Key 或 GitHub App 短效令牌

远程机器上的编程 Agent 只需访问当前任务对应的仓库，无需借用个人全局身份：

1. 单仓库 Deploy Key：在远端生成专用密钥（ssh-keygen -t ed25519 -f ~/.ssh/id_repo_deploy -N ""），填入目标 GitHub 仓库 Settings -> Deploy keys，按需设只读或单仓可写，阻断跨仓污染。
2. GitHub App 1 小时短效令牌：通过 Git Credential Helper 签发默认 60 分钟过期的 Installation Token，仅授予目标仓库 contents:write 权限（至于 Codex CLI 后续是否会原生内置 GitHub App 短效令牌自动换取机制，官方尚未公布，待核实 [待验证]）。

第四步：用本地服务受控检出与分支推送替代裸套接字透传

ChatGPT Desktop 之所以要用 forwarded-ssh-agent.sock，是因为让个人桌面端直接兼任了远程执行器，缺少独立的凭据隔离层。

团队落地时，可借助 HiFox 将个人终端与远程执行环境解耦：按《电脑》与《连接代码库》规范，团队共享任务应使用专门的远程电脑，避免共享个人凭据；而在 macOS 上，虽然本地服务可将 ChatGPT 桌面端内置的 Codex CLI 登记为兜底运行时（Runtime），但文档建议优先使用自行安装并放入 PATH 的独立 Codex CLI。同时，根据《HiFox CLI》的「代码库 worktree」机制，hifox repo checkout <url> 会在本地服务缓存中检出独立 worktree 并切至专用分支（如 <产品>-agent/<Agent 名称>/<任务编号>），完成后由 hifox repo push 将该分支推回远端，让组织代码托管凭据留在 Agent 沙箱之外，无需向 Agent 暴露个人全局 SSH_AUTH_SOCK（至于本地服务在各操作系统底层存储代码托管凭据的具体加密细节，当前帮助文档未展开说明，待核实 [待验证]）。

避坑指南：排查远程 Agent 转发隐患的三个误区

1. 误把「远端硬盘没有私钥文件」当成安全：SSH Agent 转发从不落盘私钥文件，攻击者只需复用软链即可签名。应在远端运行 echo $SSH_AUTH_SOCK 与 ssh-add -L，若能列出本机公钥，说明全局身份已暴露。
2. 以为「PR #28131 自动关闭」就无需设防：无论桌面端远程脚本还是 DevPod、VS Code Remote 等工具，都可能开启 Agent 转发。不能只看单一 PR 状态，必须以 ssh -G 实测结果为准。
3. 只靠命令黑名单拦截，却保留高权限套接字：如 HN 用户 m000 所言，若只拦截字面的 ssh 或 git push --force，被注入的 Agent 仍可用 Python 脚本直连 SSH_AUTH_SOCK 或改写 .git/config 绕过。收回套接字远比维护黑名单可靠。

结论：把便利留给长连接，把签名权锁回最小边界

在自治编程 Agent 自主读取外部代码、连续执行 Shell 命令的场景下，默认把本机全局 SSH_AUTH_SOCK 动态续接给远端常驻守护进程，等于给远程环境发了一张免审签名通行证。建议今天完成三项检查：

1. 清查转发配置与软链：在本机运行 ssh -G <remote-host> | grep forwardagent 并在 ~/.ssh/config 设 Host * ForwardAgent no，检查远端是否存在 forwarded-ssh-agent.sock（拦截边界参考《编程 Agent 审批门：在失控前从哪里拦住它们》与《在自有电脑与云端运行 Codex 的边界对比》）。
2. 切换逐次确认与单仓最小凭证：将日常私钥迁入要求 Touch ID 或物理触摸确认的 Secure Enclave / YubiKey，远端开发机改用单仓 Deploy Key 或 60 分钟短效 GitHub App 令牌。
3. 收拢到沙箱外受控分支交付：在 HiFox 中结合《Agent 如何执行任务》与《工作目录》机制，让远程电脑上的 Codex 在独立 Git Worktree 中运行，通过 hifox repo checkout 与 hifox repo push 把托管凭据留在沙箱外，待任务进入等人审阅状态并由工程师检查分支后再合并（团队配置参考《Codex 团队工作流：如何在工程师之间共享一套配置》）。