VSCode 的 SSH Agent 也太离谱了（2025）
许多开发者赞扬 VS Code 的 Remote-SSH 功能能让远程开发无缝进行，但它也带来了严重的安全与资源问题。由于它安装了一个相当庞大的、基于 Node 的服务器端 agent，这个 agent 既能操作远程系统，又能通过双向协议在某些情况下在本地机器上执行代码，因此它模糊了预期中的信任边界，并扩大了攻击面——尤其是在生产服务器或不可信代码场景下使用时。评论者将这种架构与 sshfs 或 Emacs TRAMP 等更轻量的工具进行对比，争论 Microsoft 的警告是否足够，并指出可以通过开源或容器化替代方案来获得更严格的控制。
关于 VSCode Remote-SSH 的总体看法
- 许多人认为 VSCode 基于 SSH 的远程开发非常高效：在高延迟环境下 UX 仍然不错，团队环境一致，便于使用远程 CPU/RAM，编辑器体验也很流畅。
- 也有人不喜欢它，觉得它臃肿、黑箱化，并且违背了最初“轻量级编辑器”的理念。有些人完全不用它，转而使用 neovim、JetBrains、Sublime 或其他编辑器。
安全模型与“反向 shell”担忧
- 核心担忧是：远程主机上的 VSCode server/agent 可以通过其协议在本地机器上执行代码，实际上如果远程被攻破，它就会像远程访问木马一样工作。
- Microsoft 自己的安全说明明确警告，受损的远程端可以在本地运行代码。
- 有人认为这对一个你完全信任的“远程开发盒子”来说是可以接受且符合预期的；但也有人认为这违背了 SSH shell 直觉中的单向信任边界。
生产环境 vs. 开发环境
- 很多人强烈反对在生产服务器上安装 VSCode 远程 agent；有人把它描述为扩大攻击面，甚至像 rootkit/RAT。
- 也有人认为真正的问题是组织本来就不该给 prod 开 SSH/VSCode 访问；VSCode 无法“代替你管住这件事”。
- 还有少数管理员考虑在自己的服务器上直接禁止 VSCode remote。
资源占用与管理员痛点
- 有人抱怨
.vscode-server目录树巨大（好几 GB）、残留版本很多，并且目标机上还会被丢进 Node 运行时。 - 在低内存或小磁盘机器上（例如 Raspberry Pi、512MB VPS），VSCode server 可能耗尽资源并导致系统崩溃。
- 管理员方面的问题包括：大量滞留的 SSH 会话、看不到 MOTD、触发进程限制、失败模式不透明，以及不支持 BSD。
替代方案与架构对比
- 有人拿它和 Emacs TRAMP 及 tramp‑rpc 比较：TRAMP 只用 SSH + shell，更安全但更慢；tramp‑rpc 通过增加一个很小的远程辅助进程来提升速度。
- sshfs 和更早期的 IDE 模式（sftp/sshfs + 本地编辑器）被认为更简单，但缺少集成的语言服务器和调试器。
- VSCodium 用户依赖开源分支（例如 open-remote-ssh、zygos），但提到扩展缺口，而且一些替代方案会自带 SSH 客户端。
LLM agent 与沙箱预期
- 几位参与者把远程机器当作“LLM 沙箱”来使用，并以为通过 VSCode over SSH 可以保持这种隔离。
- 这个讨论强调：使用 VSCode remote 时，被攻破的沙箱（或者在那上面运行的 LLM agent）可以反向进入本地开发机，从而削弱了这种模型。