3P by neo 6달전 | favorite | 댓글 1개

SSH를 HTTPS를 통해 전송하기

  • SSH를 HTTPS를 통해 전송하려면 클라이언트와 서버 양쪽을 조정해야 함.
  • 클라이언트 설정 예시에서는 ~/.ssh/config 파일에 ProxyCommandServerAliveInterval을 설정함.
  • 사용하는 ~/.ssh/https-tunnel.bash 스크립트는 CONNECT 메서드를 헤더로 보내면서 socat을 사용해 TLS 연결을 생성함.

서버 설정 예시

  • 아파치2 HTTPS 서버 설정에서는 proxy_connect_module을 로드하고 AllowCONNECT 지시어를 사용해 특정 대상에 대한 CONNECT HTTP 메서드 사용을 허용함.
  • 서버 측에서는 https-server에서 단일 대상인 ssh-server 호스트만을 위해 CONNECT 메서드를 사용할 수 있도록 설정함.

배경

  • 병원에 머무르면서 대부분의 연결 유형이 차단된 병원 Wi-fi를 통해 원격으로 작업을 하고자 함.
  • 병원 네트워크는 HTTP와 HTTPS 연결만 허용하며, SSH는 완전히 차단됨.
  • SSH를 HTTP 또는 HTTPS를 통해 전송하는 방법에 대한 탐색.

가능한 방법들

  • 단일 포트에서 SSH와 HTTPS 프로토콜을 공동 호스팅하고 투명하게 분배하는 sslh 프로젝트.
  • sslh는 프로토콜을 다른 프로토콜에 포함시키지 않고, 다양한 휴리스틱을 사용해 실제 백엔드로 리디렉션함.
  • opensshProxyCommand 지시어를 사용해 SSH 프로토콜을 다른 프로토콜에 완전히 포함시키는 방법.

SSH over HTTP

  • 간단한 SSH over HTTP 시도를 위해 아파치2를 설정해 CONNECT 메서드를 단일 대상 ssh-server:22에 대해 허용함.
  • 클라이언트 측은 socat을 사용해 쉽게 조정됨.
  • ServerAliveInterval을 사용해 HTTP 연결이 유휴 상태에서도 끊기지 않도록 함.

SSH over HTTPS

  • socat은 HTTPS 프록시를 지원하지 않으나 TLS 캡슐화는 지원함.
  • CONNECT 기반 메서드를 수동으로 구현하기 쉬움.
  • ~/.ssh/https-tunnel.bash 스크립트를 사용해 SSH over HTTPS 터널링을 구현함.

마무리

  • HTTPS의 보편적인 존재는 매우 제한적인 중간 장치를 통해 데이터를 전송할 수 있게 해줌.
  • CONNECT 메서드는 TCP 페이로드 스트림을 TLS 호스트 스트림으로 래핑하는 유용한 해킹임.
  • ServerAliveInterval은 유휴 연결에 친화적이지 않은 하위 전송에 대해 연결을 유지하는 데 사용됨.

GN⁺의 의견

  • 이 글에서 가장 중요한 것은 제한적인 네트워크 환경에서도 SSH 연결을 가능하게 하는 창의적인 해결책을 제시했다는 점임.
  • SSH와 HTTPS를 결합하는 방법은 네트워크 보안과 관련된 전문 지식을 가진 사람들에게 특히 흥미로울 수 있음.
  • ProxyCommandServerAliveInterval 설정을 통해 네트워크 제한을 우회하는 방법은 네트워크 관리자나 보안 전문가들에게 유용한 정보를 제공함.
Hacker News 의견
  • 네덜란드의 인터넷 제공업체 XS4ALL은 과거에 SSH 접속을 포트 80을 통해 제공했음. 이 기능은 호텔 와이파이 등에서 다른 포트가 차단되었을 때 유용하게 사용됨.
  • HTTPS의 보편적인 존재는 매우 제한적인 중간 장치를 통해 데이터를 전송할 수 있게 해줌. 이것이 SSL VPN이라 불리는 독점적인 VPN 프로토콜들이 HTTPS를 통해 터널을 시작하는 모드를 구현하는 주된 이유임.
  • SSH를 포트 80이나 443에 두고 다른 호스트를 통해 ProxyJump를 사용하거나, SOCKS를 통해 덜 제한된 인터넷 연결을 얻는 방법도 있음. DNS를 TLS를 통해 SSH 연결로 포워딩하는 것도 가능함.
  • Adaptive라는 회사에서는 HTTP3를 통해 SSH 및 다양한 프로토콜을 제공하는 데이터 보안 인프라를 구축 중임. 이를 통해 사용자는 외부 포트를 통해 데이터베이스, 서버 및 기타 리소스에 연결할 수 있음.
  • 실제로 대부분의 방화벽은 단순히 openssh가 포트 443에서 수신하는 것만으로도 우회할 수 있음.
  • CONNECT 메서드를 전달 프록시가 아닌 역방향 프록시처럼 생각하는 것은 흥미로운 점임. 하지만, CONNECT만으로는 충분하지 않아 웹소켓을 통해 SSH를 사용하여 기업 프록시를 우회함.
  • "새로운" 해결책에 대한 게시물의 빈번함이 불편함. 이러한 아이디어들은 새롭지 않으며, 많은 사람들이 이미 알고 있는 내용임.
  • SSH와 유사한 신원 관리 시스템이 브라우저에 내장되어 있으면 좋겠음. hobo라는 공개 키 HTTP 인증 제안에 대해 처음 읽었을 때 흥분했지만, 서버 구현이 없고 클라이언트(브라우저) 구현도 존재하지 않음을 알게 됨.
  • 약 20년 전에 기업 방화벽을 통과하기 위해 corkscrew이라는 도구를 사용했음. 이 도구에 대한 독립적인 구현과 설명이 인상적임.
  • HTTP2를 통한 터널링은 훌륭한 선택임. HTTP2 위에 구축된 RPC 프로토콜인 gRPC가 있음. HTTP2는 TCP 연결을 이용해 여러 데이터 구조를 동시에 전송하고 수신하는 데 탁월함. 그러나 HTTP3를 사용할 필요는 없을 수도 있음, QUIC 자체가 이미 멀티플렉싱을 제공하기 때문임.