메뉴
HN
Hacker News • 2일 전

VSCode의 SSH 원격 편집 기능은 충격적이다

IMP
6/10
핵심 요약

Thomas Ptacek가 VSCode의 SSH 원격 편집(Remote-SSH) 방식을 분석한 글이다. Emacs의 Tramp와 달리 VSCode는 원격 서버에 Node 바이너리를 포함한 에이전트를 직접 설치하며, 이 에이전트는 파일시스템 탐색, 임의 파일 수정, 셸 PTY 프로세스 실행, 자기 지속(persist)까지 가능하다. 이는 사실상 원격 접근 툴(_rat_)과 유사한 동작 방식이라, 개발 서버에서는 신중해야 하고 운영 환경에서는 절대 허용하면 안 된다는 지적이다.

번역된 본문

저자: Thomas Ptacek (@tqbf)

우리는 VSCode가 SSH를 통해 원격 편집을 하는 워크플로우에 통합되는 것에 관심이 있다. 요즘은 모두가 VSCode를 쓰고 있고, 특히 LLM으로 코드를 생성하는 VSCode 포크(fork)들을 쓰고 있기 때문이다. LLM이 코드를 잘못 만들어내는 것을 우리는 "환각(hallucination)"이라 부르고, 사람이 그럴 때는 "엔지니어링"이라 부른다.

LLM이 생성한 코드는 제대로 알고 쓰는 경우라면 일반적으로 유용하다. 하지만 LLM과 실행 환경 사이의 루프를 닫을 수 있다면("Agent" 설정) 그 유용성은 극대화된다. 이에 대해 할 말은 많지만, 당장은 이렇게 말하겠다: LLM이 코드를 생성하고, 에이전트 스캐폴딩이 그 코드를 실행하고, 코드가 에러를 만들어내면, 에이전트가 그것을 LLM에 되먹이고, 이 과정이 반복된다. 이는 환각에 대한 반쯤 효과적인 해독제다.

당연히 문제는 이 반복적 개발 과정을 개발용 노트북에서 돌리고 싶지 않다는 것이다. LLM은 경계 문제가 있어서, 당신이 작업 중인 Git 프로젝트만큼이나 기꺼이 시스템 설정까지 건드리며 반복하기 때문이다. 정말 원하는 것은: 즉시 뜨는 깨끗한 Linux 인스턴스에서, 어떤 방식으로도 당신을 해칠 수 없는 환경에서, LLM을 위한 폐쇄 루프형 에이전트 구성을 돌리는 것이다. 우리가 어디로 가려는지 알 것이다.

아무튼! 우려 사항 하나를 짚고 싶다. Emacs에는 원격 편집 시스템의 정신적 조상 격인, "Tramp"라는 초유용한 Elisp 덩어리가 있다. Tramp를 대화형 환경(보통 SSH 세션)에 연결만 하면, 거기서 Bourne 셸 명령을 실행할 수 있고, Emacs를 그 환경으로 확장할 수 있다.

그래서 VSCode에도 Tramp 같은 기능이 있다. 멋지지 않은가? Tramp를 가져다가 좀 단순화하고 Elisp 대신 TypeScript로 바꾼 것이라고 생각할 것이다. 틀렸다! 원격 연결 위에 이미 있는 것들만 활용하는 Tramp와 달리, VSCode는 대대적인 침공을 감행한다. 에이전트를 다운로드하는 Bash 스니펫 스테이저(stager)를 실행하는데, 여기에는 Node 바이너리 설치본까지 포함된다. 이게 소스 코드인 것 같다.

이 에이전트는 포트 포워딩된 SSH 위에서 동작하며, 실행 중인 VSCode 프론트엔드로 WebSockets 연결을 수립한다. 그 연결 위의 프로토콜은 다음을 할 수 있다:

  • 파일시스템을 마음껏 돌아다니기
  • 임의의 파일 편집
  • 자체 셸 PTY 프로세스 실행
  • 자기 자신을 지속(persist)시키기

보안 업계에는 이런 방식으로 동작하는 도구를 부르는 이름이 있다. VSCode에게 불공평하니 굳이 말하진 않겠지만, 그 이름은 쥐과(murid)와 관련이 있다고만 해두자.

사람들이 개발 서버에서 VSCode 원격 편집을 하게 두는 것은 조금 긴장될 일이고, 운영 환경에서 인시던트 중에 그런 일이 벌어진다면 경악할 일이다.

결국 우리는 Fly Machine에 커스텀 연결을 VSCode에서 동작시키기 위해 이 모든 것을 알 필요가 없었고, 어떤 깊은 의미에서도 중요하지 않은 일이지만: 우리는 그냥 블로그 하기로 했으니까, 우리가 이걸 배웠고 이제 여러분도 알게 됐다.

다음 글 ↑ Semgrep이 훨씬 흥미로워졌나? 이전 글 ↓ 라이브북(Livebook)으로, 노트북에서 AI GPU 클러스터를

원문 보기
원문 보기 (영어)
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 ↑ Did Semgrep Just Get A Lot More Interesting? Previous post ↓ AI GPU Clusters, From Your Laptop, With Livebook