HTTPS를 통한 SSH 연결
(trofi.github.io)SSH를 HTTPS를 통해 전송하기
- SSH를 HTTPS를 통해 전송하려면 클라이언트와 서버 양쪽을 조정해야 함.
- 클라이언트 설정 예시에서는
~/.ssh/config파일에ProxyCommand과ServerAliveInterval을 설정함. - 사용하는
~/.ssh/https-tunnel.bash스크립트는CONNECT메서드를 헤더로 보내면서socat을 사용해 TLS 연결을 생성함.
서버 설정 예시
- 아파치2 HTTPS 서버 설정에서는
proxy_connect_module을 로드하고AllowCONNECT지시어를 사용해 특정 대상에 대한CONNECTHTTP 메서드 사용을 허용함. - 서버 측에서는
https-server에서 단일 대상인ssh-server호스트만을 위해CONNECT메서드를 사용할 수 있도록 설정함.
배경
- 병원에 머무르면서 대부분의 연결 유형이 차단된 병원 Wi-fi를 통해 원격으로 작업을 하고자 함.
- 병원 네트워크는 HTTP와 HTTPS 연결만 허용하며, SSH는 완전히 차단됨.
- SSH를 HTTP 또는 HTTPS를 통해 전송하는 방법에 대한 탐색.
가능한 방법들
- 단일 포트에서 SSH와 HTTPS 프로토콜을 공동 호스팅하고 투명하게 분배하는
sslh프로젝트. sslh는 프로토콜을 다른 프로토콜에 포함시키지 않고, 다양한 휴리스틱을 사용해 실제 백엔드로 리디렉션함.openssh의ProxyCommand지시어를 사용해 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를 결합하는 방법은 네트워크 보안과 관련된 전문 지식을 가진 사람들에게 특히 흥미로울 수 있음.
ProxyCommand와ServerAliveInterval설정을 통해 네트워크 제한을 우회하는 방법은 네트워크 관리자나 보안 전문가들에게 유용한 정보를 제공함.
댓글과 토론
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 자체가 이미 멀티플렉싱을 제공하기 때문임.