▲

SSH3 - HTTP/3를 사용하는 더 빠르고 풍부한 보안 셸

 (github.com/francoismichel)
7P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • SSH3는 HTTP/3 위에서 동작하는 차세대 보안 쉘 프로토콜로, 전통적인 SSHv2 대비 세션 연결 속도를 대폭 향상시킴
  • QUIC와 TLS 1.3을 통해 보안 채널을 형성하고, OAuth 2.0, OpenID Connect 등 현대적 인증체계를 지원함
  • 서버를 비밀 경로 뒤에 숨길 수 있어 포트 스캐닝 등 공격에 강하며, UDP 포트 포워딩/QUIC 멀티패스 등 새로운 기능을 제공함
  • OpenSSH의 여러 핵심 기능을 이미 채택했으나, 현재는 실험적 단계이므로 실제 운영 환경 배포는 권장하지 않음
  • SSH3 라는 이름이 적절하지 않다는 의견이 많아서, 표준화 초안은 “Remote Terminals over HTTP/3”으로 변경되었고 이름 변경이 진행 중임

SSH3 프로젝트 개요와 중요성

  • SSH3는 기존 SSH 프로토콜을 HTTP/3 및 현대적 웹 기술에 맞춰 재설계한 오픈소스 솔루션
    • 기존 SSH 연결 프로토콜(RFC4254)의 의미를 HTTP/3 Extended CONNECT와 QUIC+TLS 1.3 채널 위에서 재구성
  • IETF 인터넷 초안 draft-michel-remote-terminal-http3 로 제안되었으며, 세션 연결 속도를 크게 줄이고, 현대 인증방식 확장 등 다양한 장점을 제공
  • 다른 SSH 구현체 대비, QUIC 사용 및 숨김형 서버 구성 같은 혁신적 아이디어가 특징

주요 기능 및 특징

  • 빠른 세션 연결
    • 기존 SSHv2 연결이 평균 5~7회 네트워크 왕복이 필요한 반면, SSH3는 3회 왕복만 필요해 사용자가 느끼는 대기 시간을 크게 줄임
    • 키 입력 지연(latency)은 기존 수준으로 유지됨
  • 강화된 보안
    • TLS1.3, QUIC, HTTP 인증에 기반해, 이미 전자상거래·인터넷뱅킹 등에 사용되는 검증된 보안 프로토콜 활용
    • RSA, EdDSA/ed25519 기반 공개키 방식 및 OAuth 2.0, OpenID Connect 등 다양한 인증 방법 지원
    • Google, Microsoft, Github 계정으로도 로그인 가능
  • 서버를 숨기는 기능
    • 서버를 특정 비밀 URL(예: https://192.0.2.0:443/M3MzkxYWMx... 등) 뒤에 두고, 해당 URL로 인증 요청이 들어온 경우만 응답
    • 그 외 요청에는 404 Not Found 반환으로, 인터넷 상의 공격자·크롤러가 서버 존재를 파악하지 못함
    • 단, 비밀 경로는 인증의 대체가 아니므로 반드시 별도의 인증 메커니즘(공개키, 패스워드, OIDC 등) 사용 권장
  • 지속 개발 중인 실험적 프로젝트
    • 구조적으로 신뢰성 있는 보안성 검증이 필요하며, 운영 서버에 도입은 권장하지 않음
    • 실험 환경 또는 폐쇄 네트워크에서 커뮤니티 피드백 수렴 중
  • OpenSSH 호환성 및 추가 기능
    • ~/.ssh/authorized_keys 및 known_hosts 파싱, ssh-agent 연동, TCP/UDP 포트 포워딩, Proxy Jump 지원
    • UDP 포워딩 지원으로 DNS·RTP·QUIC 서비스 등 UDP 기반 서버 접근 경로 제공, QUIC datagram 경로 사용
    • X.509 인증서를 통한 HTTPS 수준의 서버 인증 기능
    • 키리스(Keyless) 인증: OpenID Connect로 공개키 복사 없이 기업 SSO 또는 구글/깃허브 등 외부 계정만으로 접속 가능

결론

  • SSH3는 현대적 네트워크 프로토콜과 인증을 도입해 SSH 환경을 진화시키는 오픈소스 실험적 프로젝트
  • 속도, 유연성, 보안성을 대폭 강화하지만, 충분한 검증 전에는 실운영 사용에 신중해야 함
  • OpenSSH와 유사한 사용자 경험을 제공하며, 신규 기능도 풍부함.
  • 제대로 된 보안성 평가와 커뮤니티 참여를 통해 다음 세대 SSH로 자리매김할 가능성을 갖고 있음
▲
GN⁺ 4일전  [-]
Hacker News 의견
  • ssh3라는 이름이 정말 마음에 안 들었음, 레포 최상단에 “SSH3는 이름이 바뀔 예정임. 아직은 SSH Connection Protocol(RFC4254)이 HTTP/3 Extended connect 위에서 동작하는 형태이지만, 필요한 변경 사항이 많고 기존 SSH와 너무 달라서 쉽게 통합될 수 없는 수준임. 명세 초안은 이미 ‘Remote Terminals over HTTP/3’로 바꿨고, 더 나은 영구적 이름을 고민할 시간이 필요함”이라고 써 놓아서 좋았음
    • 이런 이름은 마치 누가 “Windows 12”나 “Linux 7”이란 레포 만든 것 같이 어울리지 않는 느낌임
    • SSH3 대신 Secure Hypertext Interactive TTY 같은 이름 제안임
    • SSH/3는 어떨지 생각해봤음 (SSH + HTTP/3 느낌)
    • 이 Thread는 정말 본격적인 ‘bike-shedding’ 논쟁의 명작임
    • SSH2/3 정도면 어떨까 생각해봤음, 대부분 SSH2인데 HTTP/3 위에 올라가는 구조임
  • SSH가 느린데, 내 경험상 가장 큰 병목은 세션 셋업에 있다는 의견임. PAM 같은 것 때문이든, OpenBSD의 정책이든, SSH 연결을 재사용하던 새로 만들던 매번 세션 셋업 단계가 심각하게 느림. 장시간 세션에선야 괜찮지만, 간단하게 커맨드 하나 실행하려고 해도 매번 오버헤드가 있기에 Ansible 성능도 만족스럽지 않았고, 그래서 세션 오버헤드 없는 리모트 커맨드 실행 미니 ansible을 직접 만들게 되었음
  • ‘이게 진짜 전통적인 SSH보다 빠르다고?’ 의심이 들었는데, README 보니 연결 설정 단계만 빠르고, 연결 이후 실제 속도는 동일하다고 해서 납득했음. 이 정도만 해도 타당한 개선임
    • 실제로는 그런 의미에서 더 빠르진 않음. 단일 SSH 연결에서 여러 포트를 트래픽 포워딩할 때 헤드오브라인 블로킹이 생기는데, QUIC/HTTP3 프로토콜은 이런 문제를 해결할 수 있음
    • 내기해도 좋지만, 이 프로토콜이 고레이지 지연 링크에서 SSH보다 훨씬 빠를 거라 생각함, UDP기반이라 ack 기다리지 않고 대량 데이터를 연속 전송할 수 있기에 세계 각지에서 큰 파일 scp할 때 상당한 속도 향상을 기대함
    • VPN 위에서 진짜 빠를 수 있음, "TCP 안에 또 TCP"라는 덫(성능문제)이 없어서임
    • HTTP/3, QUIC 전체의 주된 장점이 기존 대비 라운드트립 감소, 그래서 연결 설정이 더 빨라지는 것과 일맥상통함
  • “SSHv2로는 세션 초기화에 5~7번 정도 라운드트립이 필요한데, SSH3에서는 3번만 필요함. 실제 세션 동안 입력 지연(키 입력–반응 시간)은 동일함”이라는 설명이었음. 사용자 입장에선 연결 속도가 크게 신경 쓰인 적 없어 매력을 못 느끼겠음. SSH는 전투적으로 검증된 안정성도 있고, 이런 새 도구가 실제로 프로덕션급이라 할지라도 신뢰하기에 리스크가 큼
    • UDP 터널이 핵심 기능임, wireguard보다 훨씬 가볍고 OpenID 인증 같은 것도 있음
    • ‘연결 속도’가 항상 나를 조금은 괴롭힘. 원격에서 커맨드를 바로 실행할 때 느린 것이 특히 아쉬웠음
    • ssh3에서는 헤드오브라인 블로킹이 해결되었을 가능성이 높음, 한 물리연결에서 여러 포트나 연결을 멀티플렉싱하면 더 빠를 것임
    • 부드러운 사용자 경험이 필요하다면 Mosh 추천임
  • 모든 어플리케이션 레이어 프로토콜이 http에 흡수되는 게 왜 이리 슬픈 느낌인지 모르겠음
    • 정말 그런 흐름이라면 슬플 것 같음, HTTP 전형적 모델이 대부분 경우 너무 제약적이면서 복잡해서 많은 곳에 안 맞음. 그런데 HTTP/2나 QUIC(HTTP/3의 트랜스포트)는 너무 범용적이라 HTTP라는 명칭 자체가 큰 의미가 없어지는 듯함. 최소한 QUIC는 TCP 대체제로 꽤 명확히 포지셔닝해서 씀
    • 사실 이렇게 모든 프로토콜이 표준화되면 트래픽 쉐이핑, 검열 등이 어려워서 긍정적으로 생각함. 결국 트래픽이 HTTP거나, 랜덤 바이트 스트림이면 (즉, 눈에 띄지 않으면) 네트워크 감시/차단이 어려움. 새로운 프로토콜을 만든다면, 통신사가 뭔가 특별히 유리하게 해주지 않는 이상, HTTP로 위장하는 게 느려지지 않고 잘 다니는 방법임
    • 이런 현상은 기업 보안팀이 뭐든 죄다 차단하거나 가로막으려 하는 관행 탓임. Zscaler나 TLS 미들맨 모드 쓰는 팀 너희 말하는 거임
    • 이런 식의 차단은, 공항 와이파이나 전 세계 호텔에서도 나타남. 예를 들어 Apple Mail로 메일이 안 간다거나 하는 이유도 기업 방침으로 25번 포트를 막기 때문임. 스팸 막는다면서 143, 587, 993 등 다 막아서 결국 80, 443만 통과 시킴. IPv6가 좀 나아지길 바람. 그리고 EU의 ChatControl 추진 같은 일은 멈췄으면 함. 진짜 IT를 아는 사람 말을 좀 들어줬으면 함
    • connection init, 즉 망 연결 초기화 복잡성이 높아져서 결국 battle-tested 프로토콜 기반 best practice에 올라가야 하는 것도 이해는 감. 그런데 실제 전송은 더이상 hypertext가 아닌 상황에서 계속 http라 부르는 게 어색한 느낌임
  • SSH 기능 자체가 진화하는 건 멋진 일인데, 어차피 거의 새로 만드는 작업이라면 좀 더 실험적인 새 기능도 넣었으면 하는 아쉬움임. 예를 들어 Mosh 같은 “로밍/일시적 네트워크 불안정” 대응 같은 편의 기능 있으면 좋겠음 https://mosh.org/
    • Mosh의 장점은 키 입력 반응 무지 빠르고, 마치 로컬 셸에 직접 작업하는 것 같은 느낌임. SSH3는 이런 부분 개선은 없나 궁금함. QUIC가 약간은 보완하겠지만, Mosh와는 또 다름
    • 내 이해로 connection migration이나 multipath 지원은 QUIC의 기본 특성이며, roaming 기능과 '내장 tmux'의 차이는 그게 시스템에 직접 녹아든 것이 진짜 가치가 있는지는 잘 모르겠음
  • 짧은 명칭/약어에 집착하는 사람들이 궁금함, 정말 별로임. 이제는 명령어가 길어도 되니 최대한 기술적으로 명확한 긴 이름을 써야 한다고 생각함. 풀네임을 기본으로 쓰고 약어는 일부 시스템 관리자나 배포판에서 줄여서 써도 됨. 사람들에겐 풀네임을 가르쳐야 함. 예를 들어 Set-Location이 cd 대신 더 바람직함, remote-terminals-over-http3 같은 이름이 ssh3보다 좋음
  • 마지막 커밋이 1년 전인데, 혹시 프로젝트 최근 진행 상황 아는 사람 있음?
  • 프로젝트 계획이 궁금해짐. 릴리즈나 깃허브 활동 모두 1년 넘게 소식 없음. 논문부터 시작한 방식이니 관련 연구나 다른 부수 작업을 계속하고 있을 수도 있다고 생각함
    • 이 포인트 지적해줘서 고마움. 개인적으로는 이 프로젝트 이제 끝났다고 판단함. 239커밋 정도로 사실상 Proof of Concept 수준이라 아직 진지하게 쓸 만한 게 아님. 반면 OpenBSD 쪽(OpenSSH)는 여전히 엄청 활발하니 아직 충분히 대체될 여지는 없어 보임 https://github.com/openbsd/src/commits/master/
  • 프로젝트 아이디어는 괜찮음. 일반 H3 프록시로 프록싱이 가능하다면 특히 기대됨. 거기에 multipath/migration, TCP 관련 블로킹 이슈까지 해결한다면 이미 엄청난 발전임
답변달기