VSCode의 SSH 에이전트는 너무 과합니다 (2025)

AI 요약

Fly.io는 LLM이 만든 코드를 실행 환경에서 반복 검증하는 에이전트 개발 방식에 관심을 보입니다. 개발 노트북 대신 빠르게 띄운 Linux 인스턴스에서 에이전트를 실행하면 시스템 설정까지 건드릴 위험을 줄일 수 있기 때문입니다. 이 환경에 VSCode Remote-SSH를 연결하려던 중, 원격 편집 기능이 실제로 어떤 구성요소를 설치하고 어떤 권한을 주는지 살펴봤습니다.

원격 서버에 설치되는 구성요소

Emacs의 원격 편집 기능 Tramp는 SSH로 연결한 뒤 원격 셸 명령을 실행하는 방식입니다. 저자는 VSCode도 비슷하게 동작할 것으로 예상했지만, Remote-SSH는 Bash 스크립트로 에이전트를 설치하며 그 안에는 Node.js 바이너리도 포함됩니다. 에이전트는 SSH 포트 포워딩을 거쳐 로컬 VSCode 프런트엔드와 WebSocket 연결을 맺습니다.

저자가 살펴본 프로토콜은 원격 파일 탐색과 임의 파일 편집, 셸용 PTY 실행, 원격 에이전트의 지속 실행을 지원합니다. 글은 이를 원격 호스트에 광범위한 접근 권한을 주는 구성으로 묘사하며, 특히 개발 서버나 운영 서버에 사용하면 우려스럽다고 지적합니다. Fly.io가 원하는 Fly Machine 연결에는 이 기능을 쓸 필요가 없었지만, 조사하며 알게 된 내용을 블로그에 공유했습니다.

신뢰 경계는 양방향입니다

토론에서 반복해서 제기된 보안 쟁점은 원격 머신이 로컬 VSCode를 거쳐 로컬 머신에서 코드를 실행할 수 있다는 점입니다. VSCode Remote-SSH 확장 페이지에도 원격 머신이 손상되면 로컬 머신에서 코드 실행으로 이어질 수 있으니 신뢰하는 원격 머신에만 연결하라는 경고가 있습니다. 따라서 원격을 LLM 에이전트의 샌드박스로 쓰더라도, 그 원격 환경이 로컬 클라이언트에 영향을 주지 않는다고 가정해서는 안 됩니다.

다만 댓글에서는 기능의 성격을 두고 의견이 갈렸습니다. VSCode Remote-SSH는 단순히 원격 파일을 편집하는 도구가 아니라, 원격 환경에서 확장과 터미널, 개발 도구를 실행하는 개발 환경이라고 보는 이용자도 있습니다. 이런 목적이라면 원격 에이전트 설치와 터널링은 기능에 필요한 설계라는 주장입니다. 반면 사용자가 원격 파일 편집만 기대한다면 Node.js와 수백 MB 규모의 구성요소가 설치되는 점, 원격 호스트가 로컬에 명령을 보낼 수 있는 점이 예상 밖의 공격 표면이라는 지적도 나왔습니다.

운영 환경과 대안

일부 댓글은 운영 서버에서 Remote-SSH를 쓰는 것 자체가 문제라고 지적하며, SSH 권한과 접근 제어를 제한해야 한다고 주장합니다. 서버 관리자들은 VSCode가 MOTD를 표시하지 않거나 세션을 재사용하지 않는 문제, 원격 홈 디렉터리에 여러 버전의 서버 파일이 쌓이는 문제도 언급했습니다. 반대로 Tramp는 기본 셸 명령만으로 동작하며 원격에 별도 Node.js 설치가 필요 없다는 의견과, Open Remote SSH·Zygos VSCodium 같은 대안을 소개하는 댓글도 있었습니다.

Hacker News 반응

• @walrus01 — 에이전트에 SSH 접근 권한을 줄 때는 무슨 일을 하는지 지켜보고 이해하고 싶습니다. 제가 직접 CLI에 입력할 수 있는 명령만 입력하고, 결과가 놀랍지 않기를 바랍니다. 제 경험으로는 Opencode와 충분히 똑똑한 LLM이 비교적 잘합니다.
  • @pixl97 — 모두가 그렇게 한다면 AI 안전 문제가 지금처럼 크지는 않을 겁니다. 기본적인 사람의 행동은 실행해 둔 뒤 잊어버리는 쪽이고, 일이 빠르게 통제 불능이 될 수 있습니다.
• @danielklnstein — (2025)라는 표시가 빠졌습니다. VSCode SSH 에이전트는 원격 개발에 큰 도움이 됩니다. Fly가 단점이라고 부른 부분은 장점이기도 합니다. 여러 팀에서 이 확장 기능을 많이 썼지만 문제가 된 적은 없습니다. SSH 접근 권한을 원하는 보안 정책에 맞게 제한하면 됩니다.
  • @devonbleak — 제가 마지막으로 살펴봤을 때는 프로토콜에 원격 시스템이 로컬 프런트엔드 시스템의 파일을 수정하고 코드를 실행하는 기능도 있었습니다. 정말 과합니다. Remote-SSH 확장 페이지에도 손상된 원격 머신이 로컬에서 코드를 실행할 수 있다는 보안 안내가 있습니다.
  • @jasomill — SSH 셸과 파일 쓰기·실행 권한을 일부러 제공한 원격 머신에서 코드를 실행하는 기능 자체는 취약점이 아닙니다. 하지만 잠재적으로 신뢰할 수 없는 원격 시스템이 로컬 머신에서 임의 코드를 실행하도록 허용하는 원격 접근 프로토콜은 심각한 문제입니다. 원격 시스템과 운영자를 신뢰하더라도 그 안에서 신뢰할 수 없는 코드를 직접 실행한다면 마찬가지입니다.
• @Joker_vD — Tramp도 기본적으로 같은 일을 하지 않나요? 원격 파일을 돌아다니고, 파일을 수정하고, 셸을 실행할 수 있습니다. 이런 도구를 RAT라고 부르는 셈인데, 원격 셸을 허용한 SSH 자체도 그런 도구의 전형적인 사례입니다. 왜 이렇게 놀라는지 모르겠습니다.
  • @chlorion — Tramp는 한 방향으로만 동작합니다. 제가 이해한 바로는 원격 쪽에서 로컬 쪽을 돌아다닐 수 없습니다. 그러니 전혀 같은 일이 아닙니다.
• @MajesticHobo2 — VSCode 아키텍처에서 원격이 로컬 머신을 마음대로 다룰 수 있는 부분은 받아들일 수 없습니다.
  • @devonbleak — 그 반대 방향도 가능합니다. VSCode Remote-SSH 확장 페이지에 원격 시스템이 로컬 머신에서 코드를 실행할 수 있다고 안내되어 있습니다.
• @10000truths — 원격 머신에서 파일을 수정하고 임의 명령을 실행하도록 만든 프로그램이 그 일을 할 수 있다는 이야기입니다. 왜 과하다는 건지 모르겠습니다. VSCode는 원격 머신이 인터넷에 접속할 수 있다고 가정할 수 없으니 SSH/SFTP로 바이너리를 보내는 게 자연스러운 설치 방식입니다.
  • @bobtheborg — 실제 우려는 예를 들어 운영 머신에 Node와 VSCode Server가 설치된다는 점인 것 같습니다. 설치 소프트웨어를 엄격하게 관리해야 하는 곳에 무심코 공격 표면을 더하고 싶지는 않습니다.
• @broken-kebab — 글에서 언급한 TRAMP는 원격 머신에 아무것도 설치하지 않고 SSH와 셸 명령만으로 동작합니다. 더 자연스럽게 느껴집니다. Node.js의 보안 이력도 좋다고만 할 수 없고, 문제는 파일 편집 기능 자체보다 꼭 필요하지 않은 공격 표면을 늘린다는 점인 것 같습니다.

원문: Fly.io / 번역·요약: Trawling