VSCode's SSH Agent Is Bananas (2025)
https://fly.io/blog/vscode-ssh-wtf/📌 VSCode 的 SSH 遠端外掛，行為像不像後門程式？
TL;DR：Fly.io 工程師實測發現，VSCode 遠端 SSH 連線會在對端偷偷灌一整套 agent，具備任意編輯檔案與開 shell 的能力。
當你在遠端伺服器上打開 VSCode 做遠端編輯，你以為只是連上一個終端機視窗，實際上發生的事情遠比這複雜：一段 Bash 指令碼會在對端下載一個包含完整 Node.js 執行環境的 agent 程式，並透過 WebSocket 連回你本機的 VSCode 前端。Fly.io 的 Thomas Ptacek 在研究如何把 VSCode 遠端編輯串接進 Fly Machine 時，意外挖出了這套機制的細節。
🤔 為什麼要在乎 VSCode 怎麼連遠端
文章的起點是 AI 輔助開發的趨勢：現在人人都在用 VSCode 的各種 fork 搭配 LLM 生成程式碼，而讓效果最好的用法，是把 LLM 與一個能執行程式碼的環境串成閉環（agent 設定）——LLM 寫程式碼、agent 執行、錯誤回饋給 LLM、如此反覆迭代，這是對抗幻覺（hallucination）相當有效的手段。但問題是，你不會希望這個反覆試錯的過程發生在自己的開發筆電上，因為 LLM 一樣會很樂意去「迭代」你的系統設定，而不只是你手上的 Git 專案。理想做法是把這個閉環丟到一個乾淨、用完即丟的雲端執行環境裡，而這正是作者想把 VSCode 遠端編輯接進 Fly Machine 的原因。
🧩 對照 Emacs Tramp：VSCode 選擇的是「整套進駐」
作者拿 Emacs 世界的遠端編輯始祖 Tramp 做對照：Tramp 是「就地取材」（live off the land），只要對端有能跑 Bourne shell 指令的互動環境（通常是 SSH session）就能運作。VSCode 也有類似遠端編輯功能，但做法完全不同：它會在對端執行一段 Bash 指令碼，下載並安裝一個 agent，其中包含一份 Node.js 的二進位安裝檔。這個 agent 透過連接埠轉發的 SSH 通道運行，並與本機 VSCode 前端建立一條 WebSocket 連線。
💡 這條連線能做的事，作者的形容很直接
文章指出，這條 WebSocket 連線底層協定可以：在檔案系統中任意遊走、編輯任意檔案、啟動自己的 shell PTY 處理程序，以及讓自己持續存在（persist）。作者提到，在資安圈裡，這種行為模式的工具有一個對應的名稱，但他選擇不直接說出口，只暗示那個詞帶有「鼠類」的意味——言下之意是這套機制的行為特徵與 rootkit 類工具相當接近。他表示自己會對讓人用 VSCode 遠端編輯連上開發用伺服器感到不安，若這發生在正式環境的事故處理過程中，更會是災難級的情況。
⚠️ 最後其實繞過了這個問題
值得注意的是，作者最後說明，Fly.io 要讓自訂連線在 VSCode 裡對接 Fly Machine，其實完全不需要碰到上述這套機制，所以這些細節在深層意義上「不影響」他們原本要做的事——純粹是研究過程中順帶弄清楚、也想讓讀者一併知道的背景知識。
🎯 實務啟示
如果你的團隊會用 VSCode（或其 AI 編碼 fork）遠端連線到開發機、測試機，甚至正式環境伺服器，值得先弄清楚對端到底被裝了什麼、那個 agent 擁有多大的操作權限，再決定是否要在敏感主機上開放這種連線方式，尤其是在事故排除等高風險時刻。
🔗 來源
- 標題：VSCode’s SSH Agent Is Bananas (2025)
- 作者／機構：Thomas Ptacek，Fly.io
- 連結：https://fly.io/blog/vscode-ssh-wtf/
#VSCode #RemoteSSH #DevSecOps #AICoding #AgenticAI #SoftwareSecurity #Flyio #DeveloperTools #LLMAgents #InfoSec
原始資料 Hacker News · 收集於 2026-09-24
摘要原文
Author Name Thomas Ptacek @tqbf @tqbf We’re interested in getting integrated into the flow VSCode uses to do remote editing over SSH, because everybody is using VSCode now, and, in particular, they’re using forks of VSCode that generate code with LLMs. ”hallucination” is what we call it when LLMs get code wrong; “engineering” is what we call it when people do. LLM-generated code is useful in the general case if you know what you’re doing. But it’s ultra-useful if you can close the loop between the LLM and the execution environment (with an “Agent” setup). There’s lots to say about this, but for the moment: it’s a semi-effective antidote to hallucination: the LLM generates the code, the agent scaffolding runs the code, the code generates errors, the agent feeds it back to the LLM, the process iterates. So, obviously, the issue here is you don’t want this iterative development process happening on your development laptop, because LLMs have boundary issues, and they’ll iterate on your system configuration just as happily on the Git project you happen to be working in. A thing you’d really like to be able to do: run a closed-loop agent-y (“agentic”? is that what we say now) configuration for an LLM, on a clean-slate Linux instance that spins up instantly and that can’t screw you over in any way. You get where we’re going with this. Anyways! I would like to register a concern. Emacs hosts the spiritual forebearer of remote editing systems, a blob of hyper-useful Elisp called “Tramp” . If you can hook Tramp up to any kind of interactive environment — usually, an SSH session — where it can run Bourne shell commands, it can extend Emacs to that environment. So, VSCode has a feature like Tramp. Which, neat, right? You’d think, take Tramp, maybe simplify it a bit, switch out Elisp for Typescript. You’d think wrong! Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node. I think this is the source code ? The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can: Wander around the filesystem Edit arbitrary files Launch its own shell PTY processes Persist itself In security-world, there’s a name for tools that work this way. I won’t say it out loud, because that’s not fair to VSCode, but let’s just say the name is murid in nature. I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production. It turns out we don’t have to care about any of this to get a custom connection to a Fly Machine working in VSCode, so none of this matters in any kind of deep way, but: we’ve decided to just be a blog again, so: we had to learn this, and now you do too. Next post ↑ A Blog, If You Can Keep It Previous post ↓ AI GPU Clusters, From Your Laptop, With Livebook (301 points, 199 comments on Hacker News)
由 claude-code/sonnet 自動生成