为了防止大模型写代码时改坏本地系统，开发者把代码生成与调试搬进远端隔离沙箱，原本是极其合理的防御直觉。然而云平台 Fly.io 的安全专家 Thomas Ptacek 在 2025 年 2 月 7 日公开指出了一个被长期忽视的反常事实：VS Code Remote - SSH 的底层行为特征，与安全领域常见的远程访问木马几乎如出一辙。
现代工具为了给开发者提供极致的补全与调试体验，悄悄绕过了最基础的信任边界。
悄然降临的厚后端：从就地取材到全量驻留
老一辈程序员习惯的远端编辑，典范是 Emacs 的 TRAMP 机制。本地编辑器只通过 SSH 管道向目标机器发送最基础的 Shell 原生指令，不在远端留存独立运行环境，进退极为干净。
VS Code 采取了截然相反的工程路径。首次连接远程主机时，它会通过一段 Bash 脚本，静默下载并部署一套与客户端版本完全匹配的 VS Code Server。这套服务端自带独立的 Node.js 运行时，独立于目标机器自身的业务运行环境。随后，它在远端占用随机的 localhost TCP 端口，经由 SSH 端口转发建立 WebSocket 连接，实现文件遍历、进程拉起与自持久化。
站在工程实现角度，微软的选择并非不可理喻。若要在远端提供顺畅的语言服务器协议支持、断点调试与复杂插件生态，将整个后端推向远端是最省力、响应最快的设计。这套流量全部封装在已经通过认证的 SSH 隧道内，并没有把端口赤裸暴露在公网，Fly.io 在实际对接时甚至不必修改底层逻辑。
但从系统审计与安全防护的视角审视，这种未经声明的运行时注入，打破了传统运维对服务器状态确定性的把控。
意料之外的越权与双向穿透
当开发团队将这套架构搬入共享开发环境或排查生产故障时，隐蔽的信任漏洞开始浮出水面。
VS Code Server 在远端生成随机密钥作为访问凭证，但其内置的 /version 接口属于免认证 HTTP 路径。更为关键的是，默认配置下服务端监听的是远端机器的 localhost TCP 端口。在多用户共享的跳板机或测试服务器上，同一台机器内的其他普通用户完全能够嗅探该端口。微软在官方安全文档中给出了缓解方案，明确建议在多用户场景下手动开启参数，将监听机制改为受系统文件权限严格限制的 Unix Socket。
然而，更严重的认知盲区在于连接方向与信任关系的颠倒。
隔离沙箱本意是防范大模型越界，却把本地主机的后门交了出去。
开发者普遍预设远端服务器是安全的容器，本地电脑是唯一的受控主体。但微软官方安全警告明确指出：一旦远端服务器先前已被攻击者拿下，或者开发人员连接了一个不可信的远端实例，攻击者便能够利用当前活跃的 VS Code Remote 通道，反向在开发者的本地笔记本电脑上执行任意代码。
古人云：借车者驰之，借衣者被之。当开发者把自己的桌面客户端与远端服务深层绑定，就等于在两台机器之间开辟了一条全双工的特权通道。相比之下，同生态的 JetBrains Gateway 在 SSH 隧道之外额外强制引入了 TLS 1.3 双重加密与验证，正是试图在传输逻辑上多卡一道闸门。
- 风险.切忌使用个人日常开发机连接不可信来源的公网 VM 或第三方容器镜像，避免远端恶意载荷通过 IDE 内部协议反向突破本地防护网。
生产排障与 Agent 时代的合规边界
这一争议在当前 AI 编程自动化（Agentic Workflow）的浪潮下被进一步放大。为了让大模型在封闭闭环中自我修正语法错误、运行单测并持续迭代，团队不得不给予其极高的 Shell 执行权限。工程师为了自保，选择在隔离的云主机上运行这套流程，却通过 VS Code 把云主机挂回了自己的笔记本电脑。
木马与现代开发工具的区别，往往不在于所调用的底层系统调用，而在于用户的知情权与授权粒度。能够遍历目录、拉起子进程并常驻内存的程序，在研发环境叫辅助后端，在审计日志里就是标准的高危后门。
- 建议.多用户机器必须强制指定 Unix Socket 监听配置；生产环境发生严重故障排障时，严禁使用 VS Code Server 驻留，应退回至标准 SSH 终端就地处理。
技术工具的演进往往遵循一条规律：为了换取极致的平滑体验，系统总会倾向于向深处侵蚀权限。理解脚下踩着的每一根 RPC 管道究竟通向何方，依然是工程开发里最基本、也最昂贵的安全自觉。