VS Code 的 SSH 连接背后还有运行时，远程编辑权限需要算完整
据 Fly.io 的技术评论，VS Code Remote SSH 的连接过程包含远端服务和运行时。微软的官方说明也明确描述了 VS Code Server 在远程主机上的安装和运行。
作者：韩启明｜OC 政策与安全编辑
据 Fly.io 的技术评论，VS Code Remote SSH 的连接过程包含远端服务和运行时。微软的官方说明也明确描述了 VS Code Server 在远程主机上的安装和运行。
一句话结论：远程开发的信任边界，要覆盖远端执行的代码与扩展。
用户在本机打开的是一个编辑器窗口，真正处理文件、工具和部分扩展的环境却可以在服务器上。SSH 保护连接通道，而 VS Code Server 提供远程开发所需的能力。它并非仅把文本文件传到本机再传回去。
Fly.io 作者对这一实现的复杂度表达了强烈不满，但评论本身没有披露一个新漏洞，也不能据此把正常的 Remote SSH 架构称为恶意软件。产品公开的能力与部署时应承担的风险，需要分开讨论。
这个差别在生产环境尤其重要。为方便编辑而使用的登录账户，如果同时能读取服务凭据、修改应用目录和运行进程，那么远程开发环境也会进入相应的信任范围。加密连接不会主动缩小账户权限。
微软文档把本地和远端扩展执行位置作了区分。团队可以据此核对哪些扩展需要进入远端、使用什么账户，以及开发环境与生产环境是否真正隔离。遇到受限网络，还应把服务端组件的获取和更新纳入管理。
这些都是可检查的配置问题。与其笼统争论编辑器是否“过重”，更实际的办法是列出它在远端安装什么、运行什么、能够访问什么，并验证关闭会话后的清理和保留行为符合预期。
关键事实
- 来源：Fly.io 评论与微软 Remote SSH 文档。
- 架构：本地编辑器通过 SSH 使用远端 VS Code Server。
- 定性：工程与权限讨论，不是本次发现新漏洞的报道。
OC 判断
便利工具越接近生产环境，账户和扩展的边界就越值得明示。问题可以通过专用开发机、合适的账户权限和组件管理来处理；不能仅凭连接名称里有 SSH，就把整套运行时都视作已经审查完毕。
为什么重要
- 对开发者：了解扩展到底在哪台机器执行。
- 对企业：远程开发环境应进入资产和权限管理。
- 对用户：工作流越顺滑，越需要可理解的控制入口。
评论
围绕这篇文章补充信息、提出问题或分享观察。