SSH, Host 헤더 없이 어떻게 여러 VM에 접속할까?
SSH는 HTTP와 달리 Host 헤더(Host Header)가 없어, IP 주소 공유 시 연결 대상을 구분하기 어려움
exe.dev는 각 VM에 할당된 고유 IP 주소 풀(IP Address Pool)을 활용하여 SSH 연결을 라우팅함
점프 호스트(Jump Host)를 사용하거나 SSH 설정 파일(config)을 수정하는 등, 커뮤니티에서 다양한 해결책 제시
SSH 프록시(SSH Proxy) 사용 시 보안 취약점 및 연결 방식에 대한 논쟁 발생
SSH 프록시 아키텍처(SSH Proxy Architecture)의 구현
exe.dev는 SSH 프록시(SSH Proxy)를 사용하여 여러 VM에 대한 SSH 연결을 관리한다. 사용자, IP 주소 기반 튜플(Tuple)을 통해 연결을 특정 VM으로 라우팅하는 방식을 사용한다. 이러한 아키텍처는 VM 생성 시 사용자별로 IP 주소를 할당하고, SSH 연결 시 공개 키(Public Key)를 기반으로 인증하는 과정을 포함한다. 데이터 격리 아키텍처(Data Isolation Architecture)를 구축하여 각 VM의 보안을 유지하는 것이 핵심이다.
점프 호스트(Jump Host) 방식의 장단점
커뮤니티에서는 점프 호스트(Jump Host)를 활용하여 SSH 연결을 단순화하는 방법을 제시한다. 점프 호스트(Jump Host)는 단일 IP 주소를 통해 여러 VM에 접근할 수 있게 해주며, SSH 설정 파일(config)을 통해 쉽게 구성할 수 있다. 하지만, 이중 암호화(Double Encryption)로 인한 성능 저하 및 SSH 클라이언트 라이브러리 호환성 문제가 발생할 수 있다. 단순성(Simplicity)과 성능(Performance) 사이의 트레이드 오프(Trade-offs)를 고려해야 한다.
SSH 설정 파일(config)을 이용한 연결 관리
SSH 설정 파일(config)을 사용하여 특정 도메인에 대한 프록시 점프(ProxyJump)를 설정하는 방법이 제시되었다. 이 방법을 사용하면, 사용자는 `Match` 구문을 통해 특정 호스트에 대한 설정을 맞춤화할 수 있다. SSH 설정 파일(config) 관리는 유연성을 제공하지만, 사용자 설정 변경에 대한 부담이 있을 수 있다. 사용자 경험(User Experience)과 관리 용이성(Manageability) 사이의 균형을 맞추는 것이 중요하다.
SSH 프록시(SSH Proxy) 보안 문제 및 MiTM 공격 가능성
SSH 프록시(SSH Proxy)를 사용할 경우, 연결이 중간자 공격(MiTM, Man-in-the-Middle)에 취약해질 수 있다는 우려가 제기되었다. 특히, 프록시가 사용자의 모든 연결을 가로채어 검사하는 경우, 데이터 미저장 정책(Zero-Retention Policy)을 준수하기 어렵다. 보안(Security)과 편의성(Convenience) 사이의 균형을 맞추는 것이 중요하며, 프록시의 구현 방식에 따라 보안 수준이 크게 달라질 수 있다.
