Fly.io工程师Thomas Ptacek于9月23日发布长文"VSCode's SSH Agent Is Bananas"，系统拆解VSCode Remote-SSH代理的工作机制并指出其本质是远端可执行本地任意代码。文章以Emacs Tramp作为对照基准，指出Tramp"在远端环境上就地取材"，VSCode则是把整套Node二进制代理从Bash片段部署到远端，再通过端口转发的SSH建立WebSocket回连本地前端，这种架构在安全模型上属于典型的远程代码执行通路。
代理协议具备三类危险能力
Ptacek详细列出WebSocket连接上的三类能力：浏览远端文件系统、编辑任意文件、以及启动自己的Shell PTY进程。代理还会在远端持续驻留，以便在SSH连接断开时仍能恢复会话。这套机制对VSCode用户的"远程编辑"体验而言是核心支撑，但也意味着任何能影响远端机器的因素都能反向作用于本地开发机——远端被入侵等同于本地被入侵，远程SSH会话的安全边界与本地机器不再有本质差别。
Fly.io团队接触这套架构是因为希望自家Fly Machine能被VSCode Remote-SSH识别为远端目标，最终选择仅做基础连接兼容、不深度集成代理能力。Ptacek以幽默的方式提示读者：如果远程开发机跑在生产环境、并且VSCode被攻击者突破，远程代码执行将导致生产事故链路被攻击者直接接入。他特别强调对生产服务器使用VSCode Remote-SSH"会感到紧张"，对事故响应期间使用更会"血压拉满"。
Reddit与GitHub讨论佐证同类担忧
Reddit与Hacker News讨论中，用户devonbleak引用VSCode官方文档中的安全提示——"只能连接到受信任的、属于可信方的安全远端机器，被入侵的远端可通过VSCode Remote连接在本地机器上执行代码"——指出这并非隐藏漏洞，而是VSCode官方公开承认的风险模型。评论普遍把这种模式类比为Jenkins主从协议下的"slave可执行master代码"问题。
Hacker News用户danielklnstein则反驳称Remote-SSH在多个团队中长期使用从未出现事故，关键在于按需精细控制远端访问即可。讨论中还有人指出，VSCode Remote-SSH插件并非开源，微软对内部实现保持封闭，导致管理员无法基于源代码审查其行为；社区开源替代品包括jeanp413/open-remote-ssh与F1yingWhite/fast-remote-ssh，但都缺乏官方插件的稳定性与功能完整度。
管理员视角的真实痛点是工具不透明
系统管理员godelski指出三大长期困扰：VSCode不显示登录提示信息MotD，导致管理员无法通过横幅告知用户重要事项；插件不会复用SSH会话，多月内会累积数十个半开连接，需要脚本强制清理；底层不开放源码使管理员无法理解会话建立与保持的真实路径。此外，VSCode在远端会枚举整个文件系统树，对NFS挂载点极不友好，甚至会触发操作系统的fork上限（典型Linux默认每UID 256进程上限），容易让多用户HPC环境陷入"进程资源耗尽"的拒绝服务状态。
Fly.io选择以博客形式公开讨论这套机制，而不是发布替代实现，意味着VSCode Remote-SSH短期内仍将是事实标准。Ptacek的结论很克制：Remote-SSH并非漏洞，而是设计目标就要求"远端可执行本地代码"，但用户应当在配置远端访问时充分意识到这条信任边界。生产环境的事故响应、面向不信任用户的开发沙箱、以及跨团队共享的开发机都属于"慎用"场景；普通开发者在受控VPC内的远程机器上使用仍然是合理选择，前提是把信任模型写在团队文档里。