SSH 핸드셰이크와 호스트 키 인증

SSH는 포트 22로 TCP 연결을 시작합니다. 연결이 설정되면 클라이언트와 서버는 SSH-2.0-OpenSSH_9.3과 같은 버전 문자열을 서로 교환하며, 이를 통해 프로토콜 버전과 구현을 식별합니다. 이 버전 교환을 통해 양쪽은 계속 진행하기 전에 서로 호환되는지 확인할 수 있습니다.

버전을 교환한 후 양쪽은 지원하는 알고리즘을 나열한 SSH_MSG_KEXINIT 패킷을 보냅니다. 이 목록에는 키 교환 방법, 호스트 키 유형, 대칭 암호, MAC 알고리즘, 압축 방식이 포함됩니다. 두 목록의 교집합에 따라 세션에 사용할 알고리즘이 결정됩니다.

세션 키는 Diffie-Hellman 또는 ECDH와 같은 키 교환 알고리즘을 사용하여 설정됩니다. 클라이언트와 서버는 각각 임시 키 쌍을 생성하고, 공개 값을 교환한 다음, 독립적으로 동일한 공유 비밀을 계산합니다. 이 공유 비밀은 세션 키를 파생하는 데 사용되며, 네트워크를 통해 직접 전송되지는 않습니다.

서버는 호스트 개인 키를 사용하여 키 교환 해시에 서명함으로써 자신의 신원을 증명합니다. 호스트 키에는 RSA, ECDSA 또는 최신 Ed25519 형식을 사용할 수 있습니다. 클라이언트는 이에 대응하는 공개 키를 사용하여 이 서명을 검증하고, 자신이 사칭자가 아닌 실제 서버와 통신하고 있음을 확인합니다.

새 서버에 처음 연결할 때 클라이언트는 아직 호스트 공개 키를 알지 못합니다. SSH는 키 지문을 표시하고 사용자에게 이를 수락할지 묻습니다. 이 최초 사용 시 신뢰 모델은 키를 known_hosts에 저장하고, 이후 연결에서 키가 변경되었는지 감지하여 중간자 공격 가능성을 경고합니다.

새 서버의 호스트 키를 검증하는 가장 안전한 방법은 대역 외 채널을 이용하는 것입니다. 관리자는 직접 만나거나 검증된 보안 채널을 통해 서버 지문을 확인한 다음, 이를 SSH 클라이언트에 표시된 지문과 비교할 수 있습니다. 이렇게 하면 최초 연결에서 위조된 키를 무심코 수락하는 일을 방지할 수 있습니다.

known_hosts 파일은 다음 형식의 줄을 저장합니다: 호스트 이름 알고리즘 base64-key. 각 항목은 신뢰할 수 있는 서버 신원을 나타냅니다. known_hosts에 이미 있는 호스트에 연결하면 SSH는 제시된 키가 저장된 키와 일치하는지 검증하며, 일치하지 않으면 연결을 거부합니다.

키 교환이 끝나면 양쪽은 공유 비밀, 교환 해시, 세션 식별자를 사용하여 독립적으로 세션 키를 파생합니다. 통신의 각 방향과 암호화 및 MAC 작업에 대해 별도의 키가 파생됩니다. 따라서 클라이언트에서 서버로 전송되는 트래픽에 사용되는 키와 서버에서 클라이언트로 전송되는 트래픽에 사용되는 키는 서로 다릅니다.

세션 키가 설정되면 이후의 모든 SSH 통신은 암호화되고 인증됩니다. AES-256-GCM 또는 ChaCha20-Poly1305와 같이 협상된 암호는 기밀성을 보호하고, MAC은 무결성을 보장합니다. 사용자 이름과 인증 자격 증명까지도 이 암호화된 터널 안에서 전송됩니다.

2048비트 또는 4096비트 RSA 호스트 키는 폭넓게 지원되지만 속도가 느립니다. NIST 곡선을 기반으로 하는 ECDSA 키는 더 빠르지만, 일부 사용자는 NIST 곡선 매개변수를 신뢰하지 않습니다. Curve25519를 기반으로 하는 Ed25519 키는 최신 권장 방식입니다. 크기가 작고 빠르며 보안성이 뛰어나고 NIST 곡선 매개변수에 의존하지 않기 때문입니다. 대부분의 최신 SSH 서버는 기본적으로 Ed25519를 제공합니다.

SSH 핸드셰이크는 TCP 연결, 버전 교환, 알고리즘 협상, 세션 키를 설정하는 키 교환, 서버 호스트 키 검증, 사용자 인증으로 이루어집니다. 버전 교환 이후의 모든 단계는 키 교환 단계에서 설정된 암호화 및 무결성 보호 채널 안에서 수행됩니다.

최초 연결 이후 이어지는 연결에서 클라이언트는 SSH 서버 호스트 키를 어떻게 검증합니까?

이 단원에서는 포트 22로 TCP를 연결하고, 버전 문자열을 교환하며, 알고리즘 협상을 통해 암호와 키 교환 방법을 선택하고, ECDH 또는 DH로 공유 비밀을 설정하며, 통신 방향별로 세션 키를 따로 파생하는 과정을 살펴보았습니다. 또한 서버는 호스트 키 서명으로 자신을 인증하고, 클라이언트는 최초 연결에서 TOFU를 사용하여 known_hosts와 대조해 서버를 검증합니다.