[!NOTE] SSH3는 아마 이름이 변경될 것입니다. 여전히 HTTP/3 Extended connect 위에서 실행되는 SSH 연결 프로토콜(RFC4254)이지만, 필요한 변경 사항이 많고 널리 사용되는 SSH 구현체의 철학과 너무 거리가 있어 통합을 고려하기 어렵습니다. 사양 초안은 이미 "HTTP/3을 통한 원격 터미널"로 이름이 변경되었지만, 좋은 영구적인 이름을 정하는 데 시간이 필요합니다.

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

SSH3는 SSH 프로토콜을 완전히 재검토하여 그 의미를 HTTP 메커니즘 위에 매핑합니다. 이는 우리의 연구 작업의 결과이며, 우리(연구자)는 최근 이를 인터넷 초안 (draft-michel-remote-terminal-http3-00)으로 제안했습니다.

간단히 말해, SSH3는 보안 채널 설정을 위해 QUIC+TLS1.3을 사용하고, 사용자 인증을 위해 HTTP Authorization 메커니즘을 사용합니다. 무엇보다도 SSH3는 다음과 같은 개선 사항을 제공합니다:

• 훨씬 빠른 세션 설정
• 기존 SSH 인증 외에 OAuth 2.0 및 OpenID Connect와 같은 새로운 HTTP 인증 방법
• 포트 스캐닝 공격에 대한 복원력: SSH3 서버를 다른 인터넷 사용자로부터 보이지 않게 만들 수 있습니다.
• 기존 TCP 포트 포워딩 외에 UDP 포트 포워딩
• 최신 QUIC 프로토콜이 허용하는 모든 기능: 연결 마이그레이션(곧) 및 다중 경로 연결

[!TIP] 빨리 시작하고 싶으신가요? SSH3 설치 방법을 확인하세요. SSH3 서버 설정 및 SSH3 클라이언트 사용 방법을 배울 수 있습니다.

⚡ SSH3가 더 빠릅니다

세션 설정 속도가 빠른 것이지 처리량이 빠른 것은 아닙니다! SSH3는 SSHv2보다 훨씬 빠른 세션 설정을 제공합니다. SSHv2로 새 세션을 설정하는 데 5~7번의 네트워크 왕복 시간이 걸릴 수 있으며, 사용자가 쉽게 알아차릴 수 있습니다. SSH3는 단 3번의 왕복 시간만 필요합니다. 실행 중인 세션의 키 입력 지연 시간은 변경되지 않습니다.

SSH3(위쪽) VS SSHv2(아래쪽) 세션 설정 (서버에 대한 핑 100ms).

🔒 SSH3 보안

SSHv2가 사용자 인증 및 보안 채널 설정을 위해 자체 프로토콜을 정의하는 반면, SSH3는 TLS 1.3, QUIC 및 HTTP의 강력하고 검증된 메커니즘에 의존합니다. 이러한 프로토콜은 이미 전자상거래 및 인터넷 뱅킹과 같은 인터넷 상의 보안이 중요한 애플리케이션을 보호하는 데 광범위하게 사용되고 있습니다.

SSH3는 이미 일반적인 비밀번호 기반 및 공개 키(RSA 및 EdDSA/ed25519) 인증 방법을 구현하고 있습니다. 또한 OAuth 2.0과 같은 새로운 인증 방법을 지원하며 Google/Microsoft/Github 계정을 사용하여 서버에 로그인할 수 있습니다.

🧪 SSH3는 아직 실험 단계입니다

SSH3는 더 빠른 세션 설정에 대한 가능성을 보여주지만, 아직 초기 개념 증명 단계에 있습니다. 새로운 복잡한 프로토콜과 마찬가지로, 합리적인 보안 결론을 내리기 전에 전문가의 암호 검토가 장기간에 걸쳐 필요합니다.

우리는 커뮤니티의 피드백과 분석을 용이하게 하기 위해 SSH3를 오픈 소스 프로젝트로 개발하고 있습니다. 그러나 추가적인 동료 검토 없이는 생산 시스템에 적합하다고 보증할 수 없습니다. 관련 전문 지식이 있으시면 함께 협력해 주시기 바랍니다!

🥷 지금은 프로덕션 서버에 SSH3 서버를 배포하지 마십시오

현재 프로토타입 상태를 고려하여, 샌드박스 환경이나 사설 네트워크에서 SSH3를 테스트하는 것이 좋습니다. 실험 서버를 인터넷에 직접 노출시키는 것은 철저한 보안 검증 전에 위험을 초래할 수 있습니다.

서버를 비밀 경로 뒤에 숨기는 것이 잠재적인 이점이 있지만, 프로덕션에 들어가기 전에 엄격한 취약점 분석의 필요성을 대체하지는 않습니다. 우리는 SSH3의 미래 가능성에 대해 기대하고 있지만, 추가적인 검토를 권장합니다.

🥷 SSH3 공용 서버를 숨길 수 있습니다

SSH3를 사용하면 SSH 서버에 대한 일반적인 스캐닝 및 사전 공격(dictionary attacks)의 스트레스를 피할 수 있습니다. Google Drive의 비밀 문서와 마찬가지로, SSH3 서버는 비밀 링크 뒤에 숨겨져 이 특정 링크에 대한 HTTP 요청을 한 인증 시도에만 응답하도록 할 수 있습니다. 예를 들면 다음과 같습니다:

ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>

<my-long-secret>을 임의의 값, 예를 들어 M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU로 바꾸면, SSH3 서버는 https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU URL로의 SSH3 연결 시도에만 응답하고 다른 요청에는 404 Not Found를 응답합니다. 따라서 인터넷의 공격자와 크롤러는 SSH3 서버의 존재를 감지할 수 없습니다. 그들은 모든 요청에 404 상태 코드를 응답하는 단순한 웹 서버만 보게 됩니다.

명심하세요: SSH3 서버를 비밀 URL 뒤에 두는 것은 스캐닝 공격의 영향을 줄일 수 있지만, 기존의 인증 메커니즘을 대체하지는 않으며 절대로 대체해서는 안 됩니다. 비밀 링크는 호스트가 발견되는 것을 방지하는 데만 사용해야 합니다. 비밀 URL을 아는 사람이 서버에 접근 권한을 부여받지 않아야 합니다. 위에서 설명한 기존 인증 메커니즘을 사용하여 서버를 보호하십시오.

💐 SSH3는 이미 기능이 풍부합니다

SSH3는 SSHv2 프로토콜에서는 제공할 수 없었던 새로운 기능을 제공합니다.

완전히 새로운 기능

• UDP 포트 포워딩: 이제 SSH3 호스트에서만 접근 가능한 QUIC, DNS, RTP 또는 모든 UDP 기반 서버에 액세스할 수 있습니다. UDP 패킷은 QUIC 데이터그램을 사용하여 전달됩니다.
• X.509 인증서: 이제 일반적인 HTTPS 인증서를 사용하여 SSH3 서버를 인증할 수 있습니다. 이 메커니즘은 기존 SSHv2 호스트 키 메커니즘보다 더 안전합니다. 예를 들어 LetsEncrypt를 사용하여 인증서를 쉽게 얻을 수 있습니다.
• 비밀 링크 뒤에 서버 숨기기.
• OpenID Connect를 사용한 키리스(keyless) 보안 사용자 인증. 회사의 SSO나 Google/Github 계정을 사용하여 SSH3 서버에 연결할 수 있으며, 더 이상 사용자의 공개 키를 복사할 필요가 없습니다.

구현된 유명한 OpenSSH 기능

이 SSH3 구현은 이미 OpenSSH의 많은 인기 기능을 제공하므로, OpenSSH에 익숙하다면 SSH3 채택 과정이 원활할 것입니다. SSH3가 구현한 OpenSSH 기능 중 일부는 다음과 같습니다:

• 서버에서 ~/.ssh/authorized_keys 파싱
• 인증서 기반 서버 인증
• X.509 인증서를 사용하지 않을 때의 known_hosts 메커니즘
• 공개 키 인증을 위해 ssh-agent 자동 사용
• 원격 서버에서 로컬 키를 사용할 수 있도록 SSH 에이전트 포워딩
• 직접 TCP 포트 포워딩 (역방향 포트 포워딩은 나중에 구현 예정)
• 프록시 점프 (-proxy-jump 매개변수 참조). A가 SSH3 클라이언트이고 B와 C가 모두 SSH3 서버인 경우, B를 게이트웨이/프록시로 사용하여 A에서 C로 연결할 수 있습니다. 프록시는 UDP 포워딩을 사용하여 A에서 C로 QUIC 패킷을 전달하므로, B는 A<->C SSH3 트래픽을 해독할 수 없습니다.
• 클라이언트에서 ~/.ssh/config를 파싱하고 Hostname, User, Port 및 IdentityFile 설정 옵션을 처리합니다 (다른 옵션은 현재 무시됨). 또한 OpenSSH의 ProxyJump와 유사하게 동작하는 새로운 UDPProxyJump 옵션도 파싱합니다.

🙏 커뮤니티 지원

SSH3가 책임감 있게 발전할 수 있도록 도와주세요! 역량 있는 보안 연구자들이 코드베이스를 검토하고 피드백을 제공해 주시기 바랍니다. 또한, 시간이 지남에 따라 정식 IETF/IRTF 프로세스를 통해 SSH3를 발전시킬 수 있도록 관련 표준 기관에 저희를 연결해 주시기 바랍니다.

협력을 통해 반복적으로 SSH3를 안전한 생산 준비 상태로 개선할 수 있기를 바랍니다. 그러나 광범위한 전문가 암호 검토 및 권위 있는 보안 기관의 채택 증거 없이는 확실한 보안 주장을 신뢰성 있게 할 수 없습니다. SSH3의 가능성을 실현하기 위해 함께 노력합시다!

SSH3 설치

마지막 릴리스 바이너리를 다운로드하거나, Go install을 사용하여 설치하거나, 소스 코드를 컴파일하여 직접 바이너리를 생성할 수 있습니다.

[!TIP] SSH3는 아직 실험 단계이며 연구 작업의 결과입니다. 새로운 SSH3 서버를 공개적으로 배포하는 것이 두렵다면 SSH3의 비밀 경로 기능을 사용하여 비밀 URL 뒤에 숨길 수 있습니다.

Go install을 사용하여 ssh3 및 ssh3-server 설치

go install github.com/francoismichel/ssh3/cmd/...@latest

소스에서 SSH3 컴파일

최신 Golang 버전이 필요합니다. 소스 코드를 다운로드하고 바이너리를 컴파일하는 방법은 다음과 같습니다:

git clone https://github.com/francoismichel/ssh3    # 저장소 복제
cd ssh3
go build -o ssh3 cmd/ssh3/main.go                        # 클라이언트 빌드
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go   # 서버 빌드, gcc 설치 필요

루트/sudo 권한이 있고 ssh3를 모든 사용자가 사용할 수 있게 하려면 바이너리를 /usr/bin에 직접 복사하면 됩니다:

cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin

그렇지 않으면 .bashrc 또는 이와 동등한 파일의 끝에 다음 줄을 추가하여 실행 파일을 PATH 환경 변수에 추가할 수 있습니다:

export PATH=$PATH:/path/to/the/ssh3/directory

SSH3 서버 배포

호스트에 연결하기 전에 SSH3 서버를 배포해야 합니다. 현재 SSH3 데몬은 없으므로, 지금은 screen 또는 유사한 유틸리티를 사용하여 ssh3-server 실행 파일을 백그라운드에서 실행해야 합니다.

[!NOTE] SSH3는 HTTP/3 위에서 실행되므로 서버는 X.509 인증서와 해당 개인 키가 필요합니다. 공용 도메인 이름에 대한 공용 인증서는 서버의 -generate-public-cert 명령줄 인수를 통해 Let's Encrypt를 사용하여 자동으로 생성할 수 있습니다. 실제 인증 기관이 서명한 인증서를 생성하지 않으려거나 공용 도메인 이름이 없는 경우, -generate-selfsigned-cert 명령줄 인수를 사용하여 자체 서명된 인증서를 생성할 수 있습니다. 자체 서명된 인증서는 SSHv2의 호스트 키 메커니즘과 유사한 보안 보장을 제공하며, 동일한 보안 문제가 있습니다: 서버에 처음 연결할 때 중간자 공격에 취약할 수 있습니다. Let's Encrypt와 같은 공용 인증 기관이 서명한 실제 인증서를 사용하면 이 문제가 해결됩니다.

다음은 ssh3-server 실행 파일의 사용법입니다: