SSH로 편집하는 게 아니라 상주 에이전트를 설치하는 것이다

VSCode로 원격 서버를 편집할 때 벌어지는 일은 "SSH로 파일을 연다"가 아니다.

VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node.

그 에이전트는 원격에 상주하면서 파일을 읽고 고치고 셸 PTY를 띄우고, 내 로컬 프런트엔드로 역방향 연결을 만든다.

취약점 보고가 아니다. 정신 모델의 오차이고, 오차는 권한 판단에서 사고를 만든다.

출처: fly.io — VSCode SSH WTF (2025)

확인된 것

Emacs의 Tramp처럼 기존 원격 명령만 쓰는 방식이 아니다. Bash 스테이저가 Node 바이너리를 포함한 에이전트를 내려받아 설치한다.
그 에이전트는 SSH 포트 포워딩 위에서 동작하며 다음을 한다.

establishes a WebSockets connection back to your running VSCode front-end

기능은 원격 파일시스템 탐색, 임의 파일 수정, 독립적인 셸 PTY 프로세스 생성, 그리고 상주.
저자의 입장은 쓰는 장소로 구분된다.

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.
저자 본인이 단서를 달았다. 자기들의 실제 계획에 비추면 "깊은 의미에서는 아무 문제가 아니다"라고 적는다. 폭로가 아니라 관찰에 가깝다.
토론은 갈렸다. 옹호 쪽은 "어차피 원격 호스트를 신뢰해야 하는 모델"이라고 보고, 비판 쪽은 침해된 원격이 로컬에서 코드를 실행할 수 있다는 양방향성을 짚는다. 메모리 500MB 이상이라 1GB 라즈베리파이에서 죽는다는 실사용 불만도 나왔다.

판단

1. 몰라서 생기는 문제는 권한 판단에서 터진다

원격 편집을 "SSH 위의 텍스트 에디터"로 알고 쓰는 사람이 많다. 실제로는 바이너리를 내려받아 설치하고 상주시키는 일이다.

이 차이가 중요한 순간은 평소가 아니다. "잠깐 로그 좀 보려고" 프로덕션 박스에 붙을 때다. 무엇이 설치되는지 모르면 끝난 뒤 무엇이 남았는지도 모르고, 사고 조사에서 내 편집기가 만든 프로세스와 침입자가 만든 프로세스를 구분하는 데 시간을 쓰게 된다.

→ 오늘 할 수 있는 확인: 평소 접속하는 서버에서 ls ~/.vscode-server 를 한 번 쳐보는 것. 있는 줄 몰랐다면 그게 정확히 이 글의 요점이다.

2. 신뢰의 방향이 양방향이라는 게 핵심이다

"어차피 원격 호스트를 믿어야 한다"는 옹호 논리는 절반만 맞다.

보통의 SSH 세션에서 내가 감수하는 위험은 내가 원격에서 하는 일의 범위 안에 있다. 그런데 원격 에이전트가 내 프런트엔드로 WebSocket을 역방향으로 연결하면, 침해된 원격이 내 노트북 쪽으로 미칠 수 있는 표면이 생긴다. 방향이 하나 더 늘어난 것이다.

→ 실무 규칙 하나. 신뢰 등급이 다른 호스트를 같은 편집기 세션에서 열지 마라. 내 개인 개발 VM과 고객사 서버를 같은 창에 띄워두고 있다면, 그 둘은 내 노트북을 통해 이미 이어져 있다. 창을 나누는 건 공짜다.

3. 원격 박스에서 에이전트를 돌리는 구성이면 더 중요하다

요즘 흔한 배치가 있다. 격리된 리눅스 인스턴스를 하나 띄우고, 거기서 코딩 에이전트를 돌리고, VSCode로 붙어서 본다. 노트북을 더럽히지 않으려는 합리적인 선택이다.

그런데 그 박스 안에는 상주 Node 에이전트 + 코딩 에이전트 + 셸이 함께 있고, 전부 내 로컬로 이어진 같은 통로를 공유한다. "격리했다"고 부르기 전에 그 통로를 세어봐야 한다.

이번 주에 세운 규칙들이 그대로 적용된다 — 아웃바운드는 허용 목록으로, 비밀값은 모델 컨텍스트 밖으로. 여기에 하나 더 붙는다. 그 박스에서 내 노트북으로 열려 있는 연결이 무엇인지 목록으로 적어둔다.

4. 결론은 "쓰지 마라"가 아니라 "어디에 쓰는지 구분하라"다

저자 본인이 깊은 문제가 아니라고 단서를 달았고, 그 단서를 빼고 인용하면 왜곡이다. 이 도구는 편하고, 편한 데는 이유가 있다.

저자의 문장이 구분을 정확히 한다 — 개발 서버에서는 "조금 불안", 프로덕션 장애 대응 중에는 "격분". 같은 도구가 맥락에 따라 완전히 다른 물건이 된다.

→ 그래서 규칙으로 쓸 만한 건 이것이다. 내 개발 VM에는 쓰고, 남의 인프라와 프로덕션 장애 현장에는 평범한 SSH로 간다. 장애 중에 편집기를 붙이고 싶은 마음이 드는 건 그때가 가장 급하기 때문인데, 정확히 그때가 무엇이 설치되는지 확인할 여유가 가장 없는 때다.

모르는 것

직접 확인하지 않았다. 패킷을 뜨거나 설치 경로를 열어보지 않았고, 원문 서술과 토론을 읽은 결과다.
메모리 500MB 이상, 라즈베리파이 크래시는 토론에서 나온 수치이고 원문에 없다. 내가 재현한 것도 아니다.
2025년 글이다. 그 사이 VSCode의 동작이 바뀌었을 수 있고, 확인하지 않았다.
설치되는 서버 컴포넌트의 정확한 권한 범위, 세션 종료 후 잔존 여부, 자동 업데이트 동작을 확인하지 못했다. 1번의 ~/.vscode-server 확인은 존재 여부까지만 알려준다.
역방향 WebSocket을 통한 실제 공격 사례를 본 적이 없다. 2번은 구조에서 나온 추론이지 사례에 근거한 게 아니다.
JetBrains Gateway나 다른 원격 개발 도구가 같은 구조인지 조사하지 않았다. 이 글의 지적이 VSCode에 한정되는지 일반적인지 모른다.