2026 DeepSeek Harness 원격 Web UI: SSH 터널인가, 공개 인터넷 입구인가?

원격 장치에서 DeepSeek Harness Web UI를 열었지만, 어디까지 공개된 것인지 판단하기 어렵습니다.

개인 또는 소수의 고정 구성원이라면 로컬 주소 수신 대기를 유지하고 SSH 터널을 사용하십시오. 팀 전체가 접속해야 한다면 독립 인증, TLS, 접근 감사와 출처 제한을 먼저 갖춘 뒤에만 외부 주소 수신 대기를 검토해야 합니다. trustedHosts는 Host 신뢰 범위이지 로그인 인증이 아닙니다.

개인 개발자는 가끔 다른 기기에서 안전하게 접속하려는 경우에 이 글이 맞습니다. 플랫폼 엔지니어는 여러 구성원에게 안정적인 입구를 제공해야 할 때 참고하십시오. 보안 담당자는 리버스 프록시, Host 신뢰, 애플리케이션 권한이 실제 통제 체인을 이루는지 확인할 수 있습니다.

01

DeepSeek Harness 원격 Web UI 접근 등급

공식 저장소 기준으로 dsh web은 기본적으로 http://127.0.0.1:3080에서 Web UI를 제공합니다. 이 기본값은 외부 네트워크에 바로 노출하지 않는 로컬 주소 접근입니다. 공식 Web UI 안내는 모델 설정과 작업 공간 선택까지 설명하지만, 페이지가 열린다는 사실을 사용자 인증이 완료됐다는 뜻으로 설명하지는 않습니다. 공식 실행 안내와 공식 Web UI 가이드를 기준으로 확인해야 합니다.

접속 인원과 책임 범위를 다음처럼 나누면 결정이 빨라집니다.

사용 범위	권장 입구	네트워크 범위	반드시 확인할 통제
개인 접속	로컬 주소 수신 대기 + SSH 터널	SSH 사용자와 로컬 장치 중심	SSH 키, 포트 포워딩, 종료 확인
고정된 소수 구성원	제한된 SSH 터널 또는 사설 네트워크	허용된 구성원 중심	구성원별 키 회수, 연결 기록
정식 팀 입구	TLS 리버스 프록시 + 독립 인증	지정된 도메인과 허용 출처	로그인, 세션 만료, 권한 철회, 감사 로그

여기서 중요한 점은 로컬 주소 수신 대기와 외부 주소 수신 대기의 차이가 네트워크 도달성을 바꾼다는 것입니다. 사용자가 누구인지 확인하는 인증 절차를 자동으로 추가하지는 않습니다. 공개 입구를 만들면서 로그인, 세션 관리, 작업 권한을 별도로 설계하지 않았다면 페이지가 보이는 것만으로는 검수 통과가 아닙니다.

DeepSeek Harness는 현재 개발 미리보기 단계이며 호환성이 깨지는 변경이 있을 수 있다고 공식 저장소에 명시되어 있습니다. 2026년 8월 19일 기준 실행 명령과 기본 주소를 확인한 뒤, 업데이트 때마다 다시 검수하십시오. 최신 태그와 릴리스 기록도 함께 확인하는 편이 좋습니다.

02

SSH 터널과 공개 인터넷 입구의 노출 범위

개인 접속의 빠른 선택

원격 맥에서 개인적으로 접속한다면 서버의 Web UI는 계속 127.0.0.1에 묶어 두십시오. 클라이언트 장치에서 다음처럼 로컬 포트를 원격 맥의 Web UI로 연결합니다.

ssh -N -L 3080:127.0.0.1:3080 사용자명@원격주소

그 다음 클라이언트 브라우저에서 다음 주소를 엽니다.

http://127.0.0.1:3080

-L 포트 포워딩은 SSH 연결 안에서 원격 호스트의 TCP 서비스로 연결하는 방식입니다. 따라서 Web UI 자체를 외부 인터페이스에 열지 않고도 다른 장소에서 접근할 수 있습니다. SSH 포트 포워딩 공식 문서를 기준으로 옵션을 확인하십시오.

이 방식의 장점은 분명합니다.

• 공개 방화벽 규칙을 추가하지 않아도 됩니다.
• Web UI가 계속 로컬 주소에서 동작합니다.
• SSH 키를 끊으면 접근 경로도 함께 닫힙니다.
• 개인 사용에 필요하지 않은 로그인 서버와 인증 저장소를 운영하지 않아도 됩니다.

단점도 있습니다.

• 사용자가 늘면 개인별 키와 접속 절차를 관리해야 합니다.
• 터널이 끊기면 브라우저도 끊깁니다.
• 팀별 세션, 역할별 권한, 구성원별 감사가 자동으로 생기지 않습니다.
• SSH 계정이 Web UI보다 넓은 시스템 권한을 갖고 있으면 권한 범위가 과도해질 수 있습니다.

SSH 키에는 포트 포워딩 허용 범위를 제한하는 옵션을 둘 수 있습니다. 운영 환경에서는 Web UI가 있는 주소와 포트만 허용하고, 불필요한 셸·에이전트 전달·추가 포워딩을 제한하는 방향으로 검토하십시오. SSH 서버의 포워딩 제한 문서에서 permitopen, no-port-forwarding 관련 동작을 확인할 수 있습니다.

팀 입구의 공개 범위

외부 주소 또는 0.0.0.0에 바인딩하면 연결 가능한 인터페이스가 넓어집니다. 이것은 단순한 설정 변경이 아니라 방화벽, DNS, 프록시, 인증과 로그의 책임 범위를 동시에 늘리는 결정입니다.

공개 입구를 선택하려면 최소한 다음 항목을 문서로 고정해야 합니다.

• 외부에서 접속할 공식 주소
• 허용할 네트워크 또는 출처
• TLS 종료 위치
• 사용자 인증 방식
• 세션 만료와 로그아웃 방식
• 구성원 제거 시 즉시 차단하는 절차
• 긴급하게 외부 입구를 닫는 방법
• 업데이트 뒤 다시 확인할 설정과 로그

리버스 프록시는 내부 Web UI로 요청을 전달하고, 외부의 TLS와 인증을 맡는 구조로 사용할 수 있습니다. 다만 프록시는 Host와 전달 헤더를 바꿀 수 있으므로 백엔드가 실제로 어떤 Host 값을 받는지 확인해야 합니다. 공식 리버스 프록시 설정 문서에는 프록시 전달과 Host 헤더 설정의 기본 동작이 정리되어 있습니다.

03

trustedHosts와 사용자 인증의 경계

trustedHosts가 로그인 인증이 될 수 없는 이유

trustedHosts는 요청에 포함된 Host authority가 허용 목록에 있는지 제한하는 용도로 이해해야 합니다. 이 설정은 “어떤 Host 이름으로 들어온 요청을 신뢰할 것인가”를 다룹니다. “이 사용자가 누구인가”를 확인하거나 “이 사용자가 어떤 작업을 할 수 있는가”를 결정하는 계정 시스템과는 역할이 다릅니다.

따라서 다음 상황이 가능합니다.

• 허용된 Host로 페이지가 열리지만 로그인 절차가 없습니다.
• 잘못된 Host는 거부되지만 허용된 사용자인지 확인하지 않습니다.
• 프록시가 Host 또는 전달 헤더를 바꾸어 예상과 다른 값이 백엔드에 전달됩니다.
• 페이지 접근은 제한했지만 Harness 내부의 파일, 명령 실행, 작업 승인 권한은 그대로 넓게 남습니다.

Host 헤더 검증은 DNS 재바인딩이나 잘못된 가상 호스트 처리와 관련된 별도 경계입니다. 사용자 계정 인증을 대신하지 않습니다. Host 헤더 검증 테스트 가이드도 이 둘을 분리해 설명합니다.

0.0.0.0으로 외부 주소 수신 대기를 설정한 뒤에는 다음 경계를 각각 확인하십시오.

1. 외부 포트가 실제로 열렸는지 확인합니다.
2. 허용되지 않은 출처에서 접근할 수 없는지 확인합니다.
3. 잘못된 Host가 거부되는지 확인합니다.
4. 인증되지 않은 사용자가 작업 화면에 들어가지 못하는지 확인합니다.
5. 인증된 사용자의 작업 범위가 필요한 workspace와 도구로 제한되는지 확인합니다.
6. 구성원을 제거한 뒤 기존 세션과 새 세션이 모두 차단되는지 확인합니다.

이 중 하나라도 “페이지가 열리니 통과”로 처리하면 안 됩니다. 네트워크 도달, Host 신뢰, 사용자 인증, Harness 권한은 서로 다른 네 개의 검사 결과로 기록해야 합니다.

04

전송 보호와 비밀값 경계

SSH 터널은 클라이언트와 원격 맥 사이의 전송 구간을 암호화합니다. 그러나 SSH 인증이 곧 Web UI의 사용자 인증은 아닙니다. SSH 계정을 공유하면 누가 실제로 작업했는지 구분하기 어렵고, 계정을 삭제하지 않은 채 팀에서 제외하면 접근이 남을 수 있습니다.

팀용 HTTPS 입구는 책임이 더 넓습니다.

• 인증서 갱신 실패를 감시해야 합니다.
• 프록시가 브라우저와 백엔드 사이에서 어떤 헤더를 전달하는지 확인해야 합니다.
• 세션 쿠키의 보안 속성과 만료를 검수해야 합니다.
• API Key가 URL, 브라우저 저장소, 로그 또는 화면에 노출되지 않는지 확인해야 합니다.
• 프록시 로그에 요청 본문이나 민감한 헤더가 저장되지 않는지 확인해야 합니다.

공식 Web UI 가이드에서는 Settings에서 DeepSeek API Key를 입력하고 저장한 뒤 모델 경로를 사용할 수 있다고 안내합니다. 따라서 원격 공유를 시작하기 전에 브라우저 개발자 도구, 프록시 접근 로그, 셸 환경과 프로젝트 파일을 함께 점검해야 합니다. 공식 모델 설정 안내를 기준으로 현재 저장 동작을 다시 확인하십시오.

05

감사와 유지보수 비용

개인 SSH 터널은 짧게 쓰고 닫는 구조입니다. 연결이 필요할 때만 열고, 작업이 끝나면 SSH 프로세스를 종료하면 됩니다. 개인 사용자가 공개 입구를 별도로 운영하면 인증서, 방화벽, 로그인 실패, 세션, 구성원 회수와 버전 변경까지 계속 관리해야 합니다.

팀 입구는 반대로 운영 책임자를 지정해야 합니다. 최소한 다음 기록을 남기십시오.

• 입구 주소와 바인딩 주소
• 허용 출처 목록
• 인증 정책과 세션 만료 정책
• 변경한 사람과 변경 시각
• 실패한 로그인 또는 거부된 Host 기록
• 구성원 추가·삭제 기록
• 업데이트 후 재검수 결과
• 긴급 차단 절차와 복구 담당자

공개 입구는 고정 팀에 유리하지만, SSH 터널의 단순성을 그대로 대체하지는 않습니다. 팀 구성원이 자주 바뀌거나, 외부 협력자가 브라우저만으로 접속해야 하거나, 감사 자료가 필요한 경우에만 운영 비용을 감당할 가치가 생깁니다.

06

단말부터 복구까지 이어지는 최종 검수

설정 파일만 보고 결론을 내리지 마십시오. 다음 순서로 실제 연결을 검수하십시오.

1. 원격 맥에서 Web UI의 현재 수신 대기 주소를 확인합니다.
2. 외부 장치에서 포트 도달성을 확인합니다.
3. 개인 경로라면 SSH 터널을 열고 로컬 브라우저에서 접속합니다.
4. 팀 경로라면 인증되지 않은 상태에서 작업 화면이 차단되는지 확인합니다.
5. 허용된 사용자로 로그인하고 지정된 workspace만 보이는지 확인합니다.
6. 승인된 범위 안에서 읽기 작업과 제한된 작업을 각각 실행합니다.
7. 잘못된 Host와 허용되지 않은 출처로 요청해 거부 기록을 확인합니다.
8. SSH 종료 또는 프록시 차단 뒤 브라우저가 실제로 끊기는지 확인합니다.
9. 서비스를 다시 시작한 뒤 동일한 인증과 권한 검사를 반복합니다.
10. 수신 대기 상태, 입구 로그, 권한 확인 결과를 한 묶음으로 저장합니다.

판정은 다음처럼 단순화할 수 있습니다.

• 개인 또는 소수 구성원이고 공개 감사가 필요 없다면 SSH 터널을 유지합니다.
• 고정 팀이 매일 접속하고 독립 인증, TLS, 출처 제한, 로그와 권한 회수가 준비됐다면 통제된 공개 입구를 만듭니다.
• 인증 또는 권한 검수가 하나라도 불완전하면 외부 주소 수신 대기를 중단하고 로컬 주소 접근으로 되돌립니다.
• 장시간 실행이 필요하지만 브라우저 공유가 필요 없다면 원격 맥에서 Harness를 계속 실행하고, 필요할 때만 SSH 터널을 엽니다.

현재 방식이 개인 맥의 수동 실행이라면 절전, 네트워크 변경, 재부팅 뒤 프로세스 복구가 약점이 됩니다. 반대로 검증되지 않은 공개 입구는 인증 누락, 헤더 처리 오류, 구성원 회수 실패라는 더 큰 운영 부담을 만듭니다. 장시간 유지할 원격 맥이 필요하다면 맥 미니 주문 환경과 원격 맥 개인정보 보호 방침을 먼저 확인하고, 실제 작업 전에는 임시 접속과 복구 절차를 따로 검수하는 편이 안전합니다.

결국 선택 기준은 “SSH가 더 안전한가, 공개 입구가 더 편한가”가 아닙니다. 임시 개인 접속이면 SSH 터널이 책임 범위를 줄입니다. 장기 팀 입구라면 별도 인증과 감사 체계를 갖춘 공개 설계가 필요합니다. 둘 중 어느 조건도 충족하지 못한다면 Web UI를 공개하지 말고 로컬 주소 접근으로 돌아가십시오.