웹 브라우저에서 SSH 공개키 인증을 위한 HTTP 기반 에이전트 설계

초록

본 논문은 웹 브라우저 내에서 SSH 클라이언트를 구현할 때 필수적인 공개키 인증을 HTTP 환경에서 안전하게 수행하기 위한 “ssh‑web agent” 시스템을 제안한다. 동일 출처 정책, 로컬 자원 접근 제한 등을 극복하기 위해 CORS와 TLS를 활용하고, 신뢰 서버 목록과 DH 키 교환을 통한 논리적 세션을 도입한다. 프로토콜 상세와 성능 분석을 통해 실현 가능성을 검증한다.

상세 분석

이 논문은 SSH 공개키 인증을 웹 애플리케이션에 통합하려는 실용적 요구를 정확히 파악하고, 기존 ssh‑agent의 동작 방식을 HTTP 기반으로 옮기는 설계를 제시한다. 핵심 아이디어는 로컬 호스트에서 동작하는 “ssh‑web agent”가 사용자 인증 요청을 받아, 신뢰된 원격 서버와 DH 키 교환으로 공유 비밀을 생성하고, 이를 기반으로 세션 식별자를 암호화·전송한다는 점이다. 이를 위해 CORS 헤더와 Referer 검증을 조합해 요청 출처를 확인하고, 별도 “trusted‑servers” 파일에 공개키와 허용 Referer 값을 저장함으로써 중간자 공격을 방지한다.

프로토콜은 POST‑형식의 application/x‑www‑form‑urlencoded 요청에 Base64 인코딩된 바이너리 메시지를 담아 전송하고, 응답은 text/plain 형태로 반환한다. 메시지 타입은 KEX_DH_REQUEST/RESPONSE, PRIVATE, NEW 등으로 구분되며, 각 타입마다 RFC 4251/4253에 정의된 데이터 형식을 그대로 사용한다. 특히 DH 파라미터(p, g)와 서버 서명을 검증한 뒤, 에이전트는 DH 응답에 암호화된 세션 식별자를 포함시켜 전송함으로써 논리적 세션을 확립한다.

인증 흐름에서는 서버가 SSH 세션 식별자를 포함한 AUTH_REQUEST를 전송하고, 에이전트는 해당 식별자를 이용해 SSH 메시지를 서명한 뒤 AUTH_RESPONSE에 암호화된 형태로 반환한다. 서명에 사용되는 개인키는 로컬 ssh‑agent와 동일하게 관리되며, 에이전트는 사용자와 동일 UID로 바인딩되어 권한 상승을 방지한다.

보안 측면에서 가장 큰 위험은 “trusted‑servers” 파일의 관리와 Referer 기반 검증이다. 파일이 변조되면 악성 서버가 인증 요청을 위조할 수 있다. 또한 Referer 헤더는 클라이언트가 조작 가능하므로, 서명 검증 단계에서 반드시 서버 공개키와 일치하는지 확인해야 한다. 논문은 이러한 점을 인식하고 파일 보호와 TLS 사용을 권고하지만, 실운용에서는 OS‑level 접근 제어와 정기적인 무결성 검사가 필요하다.

성능 분석에서는 DH 키 교환과 암호화·복호화가 주된 비용이며, 네트워크 지연이 전체 인증 시간에 크게 영향을 미친다. 한 세션당 최소 4번의 HTTP 요청(서버↔에이전트↔서버)과 TLS 핸드쉐이크가 요구되므로, 지연이 80 ms 이하일 때 실용적이라고 주장한다. 실제 환경에서는 브라우저와 로컬 에이전트 간의 IPC 비용도 고려해야 한다.

전체적으로 이 설계는 웹 기반 SSH 클라이언트가 공개키 인증을 안전하게 지원하도록 하는 구체적인 방안을 제공하지만, 구현 복잡성, 신뢰 서버 관리, 그리고 브라우저 보안 모델과의 충돌 가능성을 충분히 평가하고 보완책을 마련해야 한다.