요약

  • SSH는 첫 번째 키 교환 해시를 세션 식별자로 사용합니다. 이 값은 협상된 전송 기록(transcript)에서 도출되며, 어느 한쪽 끝점이 임의로 선언하는 것이 아닙니다.
  • 재키잉(rekeying)은 알고리즘, 트래픽 키, 초기화 벡터, 압축, 심지어 서버 호스트 키까지 교체할 수 있지만, 원래의 세션 식별자는 그대로 유지됩니다. 새로운 보호가 곧 새로운 상위 계층 상태를 의미하지는 않습니다.
  • 공개 키 인증은 세션 식별자를 계정, 서비스, 방법, 알고리즘, 키와 함께 서명합니다. 이는 세션 간 재사용 공격을 차단하지만, 유효한 서명이라도 서버 로컬 인증 없이 셸, 포워딩 규칙 또는 기타 작업을 부여하지는 않습니다.

긴 연결은 한 세트 이상의 키를 필요로 했다

보안 원격 로그인은 관리해야 할 두 가지 종류의 연속성을 가집니다. 대화는 수 시간 지속되고, 여러 논리적 채널을 운반하며, 애플리케이션 상태를 축적할 수 있습니다. 그러나 패킷을 보호하는 암호화 키가 반드시 그만큼 오래 지속될 필요는 없습니다.

키 교체가 모든 상위 계층 연관성을 파괴한다면, 루틴한 재키잉은 셸을 닫고 전송을 중단하며 포워딩 채널을 버리게 됩니다. 반대로 키 교체가 조용히 새로운 식별자를 만든다면, 교체 전에 이루어진 인증 선언이 그 인증이 수행되기 위해 의도된 연결에서 분리될 수 있습니다.

SSH 버전 2는 작업을 계층으로 분리함으로써 이에 응답했습니다.RFC 4251은 서버를 인증하고 바이트 스트림을 보호하는 전송 프로토콜, 그 위의 사용자 인증 프로토콜, 그리고 셸, 서브시스템, 포워딩된 스트림을 멀티플렉싱하는 연결 프로토콜을 설명합니다. 이 분리는 장식이 아닙니다. 전송 보호가 변경되는 동안 상위 프로토콜이 자신이 속한 대화를 계속 인식할 수 있게 합니다.

이 계층들 사이의 다리는 사용자가 선택하지도 않고 서버가 친숙한 세션 이름으로 공표하지도 않는 하나의 값입니다.

그 이름은 교환으로부터 구성되었다

양쪽은 키 교환을SSH_MSG_KEXINIT으로 시작합니다. 이 패킷은 무작위 쿠키와 키 교환, 서버 호스트 키, 암호화, 무결성, 압축 등 각 항목에 대한 정렬된 목록을 포함합니다. 각 범주에서 선택되는 항목은 해당 방법의 조건 하에서 양쪽 모두 지원하는 첫 번째 클라이언트 선호 옵션입니다.

협상만으로 보안 채널이 확립되지는 않습니다. 선택된 키 교환 방법은 공유 비밀K와 교환 해시H를 생성합니다. 원래의 유한체 디피-헬먼(Diffie–Hellman) 구성에서H는 양쪽의 프로토콜 식별 문자열, 양쪽의 원시 KEXINIT 페이로드, 서버 호스트 키, 두 개의 임시 교환 값, 공유 비밀을 모두 포괄합니다.

이 구성이 중요합니다. 버전 문자열, 알고리즘 제안, 서버 키 또는 임시 입력 중 하나를 변경하면 해싱되는 전송 기록 자체가 달라집니다. 따라서 이 값은 “세션 47”과 같은 단순한 주장이 아닙니다. 끝점들이 실제로 협상하고 계산한 내용의 압축된 결과입니다.

무작위 쿠키는 예측 불가능성에 기여합니다. 그러나 양쪽의 KEXINIT 패킷이 해시에 들어가므로 어느 한쪽에 일방적인 명명 권한을 주지 않습니다. 공유 비밀 역시 식별자가 아닙니다. SSH는 세션 식별자를 자격 증명으로 만들지 않고 노출할 수 있으며, 식별자를 가진다고 해서K가 드러나거나 유효한 트래픽 보호를 계산할 능력이 생기지 않습니다.

호스트 서명은 더 좁은 질문에 답했다

서버는 협상에서 선택된 호스트 키로 교환 해시에 서명합니다. 검증이 성공하면, 해당 개인 호스트 키의 보유자가 이 교환 전송 기록에 서명했다는 사실이 확인됩니다. 이는 또한 알고리즘 협상이 경로상에서 몰래 재작성되는 것을 막아줍니다.

그러나 수학적으로만으로는 그 공개 키가 사용자가 의도한 호스트명에 속한다는 것을 증명하지 못합니다. 클라이언트는 여전히 신뢰 규칙이 필요합니다. 저장된 호스트 키 연관, 인증서 기반 시스템, 검증된 지문 또는 다른 구성된 방법입니다. 검증 없이 낯선 키를 수용하면 완전히 유효한 서명이 잘못된 기계에서 나올 수 있습니다.

이것이 첫 번째 중요한 권한 경계입니다. 교환 해시는 프로토콜 증거를 기록합니다. 호스트 서명은 그 증거를 하나의 키에 연결합니다. 클라이언트의 신뢰 구성은 그 키를 의도된 서버 이름에 연결합니다. 이 세 단계를 “SSH가 서버를 인증했다”로 압축하면 운영상의 결정이 여전히 발생하는 지점이 지워집니다.

첫 번째 교환 해시만이 세션 식별자가 되었다

RFC 4253은 첫 번째 키 교환에서H에 두 가지 역할을 부여합니다. 암호화 및 무결성 키 도출에 참여하고, 그 연결의 고유 식별자인session_id가 됩니다. 이후의 교환은 새로운 보호를 위한 새로운 공유 비밀과 교환 해시를 만들지만,session_id를 대체하지는 않습니다.

재키잉은 그 외의 면에서 실질적일 수 있습니다. 어느 쪽이든 시작할 수 있고, 알고리즘이 바뀔 수 있으며, 호스트 키가 바뀔 수 있습니다. 모든 키와 초기화 벡터는 재계산되고, 암호화 및 압축 문맥은 new-keys 경계 이후 재설정됩니다. 그러나 서버는 여전히 서버이고 클라이언트는 여전히 클라이언트이며, 세션 식별자는 고정된 채로 유지됩니다.

이는 중요한 것이 변하지 않았다는 주장이 아닙니다. 새로운 호스트 키는 새로운 신뢰 평가를 요구할 수 있습니다. 더 약한 협상 방법은 수용 불가능할 수 있습니다. 실패한 재키잉은 연결을 종료할 수 있습니다. 불변성이 말하는 바는 더 좁습니다. 성공적인 전송 갱신은 새로운 상위 계층 대화를 만들어내지 않는다는 것입니다.

식별자가 대체 연결에서 살아남지도 않습니다. TCP 손실 후 재접속하면 새로운 초기 교환이 새로운H를 만듭니다. 애플리케이션은 자체 메커니즘으로 파일, 터미널 또는 작업을 복구할 수 있지만, 사용자와 호스트 이름이 일치한다는 이유만으로 새 전송을 같은 SSH 세션이라고 부를 수는 없습니다.

사용자 인증은 연결을 요청에 결합했다

클라이언트가 사용자 개인 키의 소유를 증명할 때 이 고정된 값이 유용해집니다.RFC 4252는 이 증명을 사용자명에 대한 서명으로만 정의하지 않습니다. 서명된 바이트 열은 세션 식별자로 시작하여 정확한SSH_MSG_USERAUTH_REQUEST를 이어갑니다. 즉, 메시지 번호, 사용자 이름, 요청된 서비스, 방법 이름, 불리언 값, 공개 키 알고리즘, 공개 키 블롭(blob)입니다.

그 서명을 기록한 공격자는 그것을 다른 연결에 그대로 넣을 수 없습니다. 다른 연결은 다른 첫 교환 해시, 따라서 다른 세션 식별자를 가집니다. 계정, 서비스, 방법, 알고리즘 또는 키를 바꾸는 것 역시 서명된 진술을 바꿉니다.

이 설계는 세 가지 질문을 구별로 유지합니다. 서명이 제출된 키에 대해 검증되는가? 그 키가 주장된 계정에 수용 가능한가? 서버의 인증 정책(다른 방법을 요구할 수 있는)이 완료되었는가? 하나의 유효한 암호학적 계산이 이 세 가지를 모두 답하지 않습니다.

호스트 기반 인증은 동일한 연결 결합 패턴을 사용하며 추가로 클라이언트 호스트와 클라이언트 사용자 필드를 포함합니다. 이 경우에도 서명은 요청에 명명된 문맥에서의 소유 증명입니다. 서버는 여전히 호스트 키가 명명된 클라이언트에 속하는지, 그 호스트와 사용자가 로그인할 수 있는지를 결정해야 합니다.

인증 성공은 모든 채널을 사전 승인하지 않았다

서버가SSH_MSG_USERAUTH_SUCCESS를 보내면 요청된 서비스가 시작될 수 있습니다. 그 패킷을 일반적인 허가로 읽고 싶어질 수 있으나, 이 아키텍처는 그 지름길을 거부합니다.

로컬 정책은 사용자마다 수용 가능한 인증 방법과 조합을 선택합니다. 또한 이후 작업, 즉 셸 시작, 서브시스템 호출, 포트 포워딩 열기, 에이전트 포워딩 요청 수용, 특정 목적지 도달을 관할합니다. 그중 일부 결정은 클라이언트가 아직 어떤 채널을 요청할지 말하지 않았으므로 인증 중에 이루어질 수조차 없습니다.

따라서 세션 식별자는 권한이 아니라 결합을 제공합니다. 상위 계층이 “이 증명은 이 보호된 대화에 속한다”고 말할 수 있게 합니다. 그러나 “대화 내 모든 미래 행위가 승인된다”고 말할 수는 없습니다. 하나의 안정적인 문맥은 각각 별도로 승인된 여러 작업을 운반할 수 있습니다.

이 구별은 감사(audit) 주장의 범위도 한정합니다. 세션 식별자와 성공한 공개 키 방법을 포함한 로그는 인증 교환을 전송과 연관시킬 수 있습니다. 그러나 채널 및 정책 기록 없이는 어떤 명령이 실행되었는지, 어떤 포워딩 요청이 허용되었는지, 애플리케이션 데이터가 무엇을 의미했는지 증명할 수 없습니다.

알고리즘은 늙었지만 경계는 유지되었다

2006년 문서들은 모두 지속적으로 적합하지는 않았던 알고리즘들을 명명했습니다. 그렇다고 계층 간 결합을 재설계할 필요는 없었습니다.

RFC 8332는 서버 및 클라이언트 인증 모두에서 SHA-256과 SHA-512를 사용하는 RSA 서명을 추가했습니다. 기존의 RSA 공개 키 자료는ssh-rsa키 형식을 유지하면서 다른 알고리즘 이름이 더 강한 서명 절차를 선택할 수 있었습니다. 키 바이트, 서명 알고리즘, 서명되는 진술은 별개의 대상으로 남았습니다.

RFC 9142는 이후 SSH 키 교환 방법 전반에 걸친 구현 권고를 개정하여 SHA-1 기반 선택에서 벗어나게 하고, 권고 집합에서 더 강한 대안을 요구했습니다. 협상이 명명된 알고리즘을 운반했기 때문에 레지스트리와 권고는 진화할 수 있었습니다. 세션 규칙은 그대로였습니다. 첫 번째 수용된 교환이 연결의 결합 문맥을 고정하고, 이후의 키 교환은 그 안에서 보호를 갱신합니다.

이 연속성을 구식 방법에 대한 승인으로 오해해서는 안 됩니다. 약하거나 잘못 신뢰된 교환으로 만들어진 세션 식별자는 이후의 인증을 약하거나 잘못 신뢰된 시작점에 그대로 결합합니다. 결합은 문맥을 보존할 뿐, 문맥의 질을 수리하지 않습니다.

증거는 그것을 만든 계층을 유지해야 한다

부정확한 대시보드에서는 호스트 이름, 호스트 키, 교환 해시, 세션 식별자, 사용자 키라는 다섯 가지 기록이 모두 “SSH 신원”이라고 불릴 수 있습니다. 그러나 각각은 다른 질문에 답합니다.

호스트 이름은 의도된 목적지 라벨입니다. 호스트 키는 그 라벨과 연관되어야 하는 암호학적 주체입니다. 교환 해시는 하나의 협상된 키 교환을 기술하며, 그 첫 번째 값이 연결 범위의 식별자가 됩니다. 사용자 키는 하나의 계정-서비스 요청에 대한 소유 증명 방법을 지원합니다. 어느 것도 서버의 인증 규칙이나 애플리케이션의 수행 작업 기록을 대체하지 못합니다.

표준들은 이러한 의미론과 알고리즘 역사를 확립할 뿐, 모든 배포의 동작을 확립하지는 않습니다. 표준은 특정 클라이언트가 호스트 키를 검사한다는 것, 서버가 일정에 따라 키를 교체한다는 것, SHA-1이 사라졌다는 것, 로컬 정책이 합리적이라는 것, 또는 성공한 로그인이 특정 명령의 실행을 초래했다는 것을 증명하지 않습니다.

SSH의 내구성 있는 조치는 소박했지만 정확했습니다. 대화가 자신의 시작점을 잊지 않게 하면서 키가 늙도록 허용한 것입니다. 첫 번째 해시는 보편적인 신원이 되지 못했습니다. 대신 이후의 증명들이 이름을 붙일 수 있는 증거 경계가 되었습니다.