이 문서는 Secure Shell (SSH) 프로토콜에서 사용하는 키 에이전트 프로토콜을 정의한다.
Internet Engineering Task Force D. Miller
Internet-Draft OpenSSH
Intended status: Standards Track 13 November 2025
Expires: 17 May 2026
draft-ietf-sshm-ssh-agent-12
이 문서는 Secure Shell (SSH) 프로토콜에서 사용하는 키 에이전트 프로토콜을 기술한다.
이 주석은 RFC로 발행되기 전에 제거되어야 한다.
IANA 고려 사항 섹션에서, "thisRFC"를, 할당된 번호를 포함한 "RFC"로 (번호가 정해지면) 교체해야 한다.
이 인터넷-초안(Internet-Draft)은 BCP 78 및 BCP 79의 규정을 완전히 준수하여 제출되었다.
인터넷-초안은 인터넷 엔지니어링 태스크 포스(IETF)의 작업 문서이다. 다른 그룹도 인터넷-초안 형태의 작업 문서를 배포할 수 있다. 현재 인터넷-초안 목록은 https://datatracker.ietf.org/drafts/current/ 에서 확인할 수 있다.
인터넷-초안은 최대 6개월간 유효한 초안 문서이며, 언제든지 다른 문서에 의해 업데이트, 교체 또는 폐기될 수 있다. 인터넷-초안을 참고 자료로 사용하거나, "진행 중인 작업(work in progress)" 이외의 용도로 인용하는 것은 부적절하다.
이 인터넷-초안의 유효기간은 2026년 5월 17일에 만료된다.
Copyright (c) 2025 IETF Trust 및 문서 저자로 식별된 개인. All rights reserved.
이 문서는 발행일 현재 유효한 IETF 문서에 대한 IETF Trust의 법적 규정(https://trustee.ietf.org/license-info)에 따라 BCP 78의 적용을 받는다. 이 문서에 대해 사용자에게 부여되는 권리와 제한 사항은 위 문서들을 주의 깊게 검토해야 한다. 코드 컴포넌트(Code Components)는 이 문서에서 발췌될 수 있으며, Trust Legal Provisions의 섹션 4.e에 기술된 개정 BSD 라이선스(Revised BSD License) 문구를 포함해야 하며, 개정 BSD 라이선스에 명시된 바와 같이 보증 없이 제공된다.
Miller Expires 17 May 2026 [Page 1]
Internet-Draft SSH Agent Protocol November 2025
코드 컴포넌트는 이 문서에서 추출될 수 있으며, Trust Legal Provisions 섹션 4.e에 기술된 개정 BSD 라이선스 문구를 포함해야 하고, 개정 BSD 라이선스에 설명된 대로 보증 없이 제공된다.
Miller Expires 17 May 2026 [Page 2]
Internet-Draft SSH Agent Protocol November 2025
7.7. SSH 연결 프로토콜 채널 타입에 추가 .......................23
7.8. 지정 전문가를 위한 가이드라인(Guidance for Designated
Experts) ...................................................24
8. 보안 고려 사항(Security Considerations) ......................24
9. 구현 상태(Implementation Status) .............................26
10. 참고 문헌(References) ........................................27
10.1. 표준 참고 문헌(Normative References) ....................27
10.2. 참고용 문헌(Informative References) .....................28
감사의 글(Acknowledgments) .......................................29
저자 주소(Author's Address) ......................................29
Secure Shell(SSH)은 신뢰할 수 없는 네트워크 상에서 안전한 원격 연결과 로그인을 위한 프로토콜이다. SSH는 공개키 인증을 포함한 다양한 인증 메커니즘을 지원한다. 이 문서는 일반적으로 "에이전트(agent)"라 불리는 개인키 보관 구성요소와 상호작용하기 위한 프로토콜을 기술한다. SSH 클라이언트(그리고 경우에 따라 SSH 서버) 는 이 프로토콜을 통해 에이전트를 호출하여, 에이전트에 보관된 공개키 및 개인키를 사용한 연산을 수행할 수 있다.
키를 에이전트에 보관하는 방식은, 매 사용 시마다 키를 로드하고 언랩(unwrapping)하는 방식에 비해 사용성과 보안 측면에서 이점이 있다. 각 키 언랩은 암호(pass-phrase) 입력을 요구할 수 있기 때문이다. 에이전트에 대한 접근은 SSH 연결을 통해 포워딩할 수도 있으며, 이를 통해 원격 시스템이 키의 실제 비밀 재료를 직접 노출받지 않고도 저장된 키를 사용할 수 있다. 마지막으로, 에이전트는 전용 구성요소로 구현될 수 있으며, 이는 전체 SSH 서버나 클라이언트에 키를 직접 로드하는 것에 비해 공격 표면이 더 작고, 시스템 전반으로부터 특별한 보호를 받을 수 있다.
이 섹션은 RFC로 발행되기 전에 제거되어야 한다.
이 에이전트 프로토콜은 이미 널리 사용되고 있는 사실상의(de-facto) 표준이며, 수년간 여러 인기 있는 SSH 클라이언트와 서버에 의해 구현되어 왔다. 이 문서의 목적은 이미 구현된 이 프로토콜을 기술하는 것이다.
이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" 과 같은 키워드는 모두 대문자로 표기된 경우에 한하여 BCP 14 [RFC2119] [RFC8174] 에서 설명한 대로 해석해야 한다.
Miller Expires 17 May 2026 [Page 3]
Internet-Draft SSH Agent Protocol November 2025
에이전트 프로토콜은 패킷화된 요청-응답 프로토콜이며, 전적으로 클라이언트에 의해 구동된다. 이 프로토콜은 클라이언트가 에이전트에 보내는 여러 종류의 요청과, 그에 대한 응답 메시지들로 구성된다. 에이전트는 클라이언트의 요청에 대한 응답으로만 메시지를 전송하며, 그 외의 경우에는 메시지를 보내지 않는다. 응답은 요청 순서대로 전송된다.
이러한 요청에는 에이전트에 키를 로드하고, 에이전트에서 일부 또는 모든 키를 제거하고, 이미 로드된 키를 사용해 서명 연산을 수행하는 기능이 포함된다.
에이전트는 사용 가능한 연산의 부분집합이나 키 타입의 부분집합만 지원할 수도 있으며, 특정 문맥에서는 임의의 연산을 거부할 수도 있다. 예를 들어, 에이전트는 로컬 클라이언트에 대해서만 키 추가/제거를 허용하고, 특정 클라이언트에는 일부 키만 사용 가능하게 할 수 있다. 이러한 이유로, 에이전트의 클라이언트는 어떤 연산이든 거부될 수 있음을 고려하고, 그런 경우에도 정상적으로 실패(fail gracefully)하도록 준비해야 한다.
이 섹션은 RFC로 발행되기 전에 제거되어야 한다.
이 프로토콜은 이름이 비슷한 [draft-ietf-secsh-agent-02] 에서 기술된 프로토콜과는 별개이며, 서로 호환되지 않는다. 후자의 초안은 2004년에 만료되었다.
이후 이 문서에서 "에이전트(agent)"는 이 프로토콜의 응답자(responder) 측을 구현하는 키 관리 구성요소를 의미한다. "클라이언트(client)"는 에이전트와 통신하기 위해 이 프로토콜의 요청자(requester) 측을 구현하는 도구를 의미한다. 해당 클라이언트가 [RFC4251] Secure Shell 클라이언트임을 명시할 필요가 있을 때는, 이를 명시적으로 "SSH 클라이언트"라고 부른다. 마찬가지로 "SSH 서버"는 Secure Shell 서버를 의미한다.
모든 인코딩 데이터 타입("byte", "uint32", "string" 등)은 [RFC4251]의 섹션 5 에서 정의된 것과 동일하다. 추가로, 대괄호 안에 길이가 명시되지 않은 "byte[]" 타입은, 길이가 문맥에 의해 결정되는 0개 이상의 바이트로 이루어진 순수 시퀀스를 의미한다.
길이 단위는 별도 표기가 없는 한 바이트(byte) 단위를 사용한다.
Miller Expires 17 May 2026 [Page 4]
Internet-Draft SSH Agent Protocol November 2025
메시지는 길이, 타입, 내용으로 구성된다.
textuint32 length byte type byte[length - 1] contents
이후 섹션들에서는 "length" 필드는 생략한다. 설명의 명확성을 위해, 메시지의 기호 이름(symbolic name)을 표기하며, 해당 숫자 값은 아래의 섹션 6.1에 나열되어 있다.
다음의 일반적인 메시지들은 클라이언트의 요청에 대한 에이전트의 응답으로 전송될 수 있다. 성공 시, 에이전트는 반드시 다음과 같은 단일 바이트 응답을 보내야 한다(MUST):
textbyte SSH_AGENT_SUCCESS
또는, 추가 필드를 포함할 수 있는, 요청별 성공 메시지를 보낼 수 있다. 실패 시, 에이전트는 반드시 다음과 같은 단일 바이트 응답을 보내야 한다(MUST):
textbyte SSH_AGENT_FAILURE
또는, 추가 필드를 포함할 수 있는, 요청별 실패 메시지를 보낼 수 있다. SSH_AGENT_FAILURE 메시지는 알 수 없거나 지원하지 않는 타입의 요청에 대한 응답으로도 반드시 전송되어야 한다(MUST).
키는 SSH_AGENTC_ADD_IDENTITY 또는 SSH_AGENTC_ADD_ID_CONSTRAINED 메시지를 사용하여 에이전트에 추가할 수 있다. 후자의 변형은 키 사용에 대해 선택적인 제약조건을 두면서 키를 추가할 수 있게 한다.
키를 위한 일반적인 SSH_AGENTC_ADD_IDENTITY 메시지 형식은 다음과 같다.
textbyte SSH_AGENTC_ADD_IDENTITY string key type byte[] contents string comment
Miller Expires 17 May 2026 [Page 5]
Internet-Draft SSH Agent Protocol November 2025
여기서 "key type"은 지정된 키 타입 이름이며, 예를 들어 [RFC4253] 에서 정의된 RSA 키의 경우 "ssh-rsa"가 된다. "contents"는 키의 공개 및 개인 구성요소들로, 키 타입에 따라 달라진다. 표준 및 일반적으로 사용되는 키 타입들에 대한 상세 내용은 이후에 기술한다. "comment"는 선택적인, 사람이 읽을 수 있는 키 이름 또는 주석으로, UTF-8 문자열이며, 사용자에게 표시되는 메시지에서 키를 식별하는 데 사용될 수 있다.
SSH_AGENTC_ADD_ID_CONSTRAINED 메시지는 유사하지만, 하위 필드가 하나 더 추가된다.
textbyte SSH_AGENTC_ADD_ID_CONSTRAINED string key type byte[] contents string comment constraint[] constraints
제약조건(constraints)은 키의 유효 기간이나 사용을 제한하기 위해 사용된다. 섹션 3.2.7에서 제약조건 타입과 형식에 대해 자세히 다룬다. 클라이언트는 제약조건이 비어 있는 SSH_AGENTC_ADD_ID_CONSTRAINED를 보내는 것보다, SSH_AGENTC_ADD_IDENTITY 메시지를 우선적으로 사용해야 한다(SHOULD). 다만 둘 다 유효하며 동등하다.
에이전트는 이러한 메시지의 결과로 키를 성공적으로 로드했다면 SSH_AGENT_SUCCESS로, 그렇지 않다면 SSH_AGENT_FAILURE로 반드시 응답해야 한다(MUST).
에이전트는 이 문서에서 정의된 키 타입의 부분집합만 지원할 수 있으며(MAY), 추가적인 키 타입을 지원할 수도 있다(MAY). 에이전트가 추가 요청에서 받은 타입 이름을 인식하지 못한다면, 반드시 정상적으로 실패하고(MUST), SSH_AGENT_FAILURE 응답을 돌려주어야 한다.
DSA 키는 키 타입 "ssh-dss"를 가지며, [RFC4253] 에서 정의된다. 이들은 다음 메시지를 사용해 에이전트에 추가할 수 있다. "constraints" 필드는 SSH_AGENTC_ADD_ID_CONSTRAINED 메시지에만 포함된다.
textbyte SSH_AGENTC_ADD_IDENTITY or SSH_AGENTC_ADD_ID_CONSTRAINED string "ssh-dss" mpint p mpint q mpint g mpint y mpint x string comment constraint[] constraints
Miller Expires 17 May 2026 [Page 6]
Internet-Draft SSH Agent Protocol November 2025
"p", "q", "g" 값은 DSA 도메인 파라미터이다. "y"와 "x"는 각각 공개키와 개인키이다. 이 값들은 [FIPS.186-4] 섹션 4.1에서 정의된 것과 동일하다.
ECDSA 키는 "ecdsa-sha2-"로 시작하는 키 타입을 가지며, [RFC5656] 에서 정의된다. 이들은 다음 메시지를 사용해 에이전트에 추가할 수 있다. "constraints" 필드는 SSH_AGENTC_ADD_ID_CONSTRAINED 메시지에만 포함된다.
textbyte SSH_AGENTC_ADD_IDENTITY or SSH_AGENTC_ADD_ID_CONSTRAINED string key type string ecdsa_curve_name string Q mpint d string comment constraint[] constraints
"Q"와 "d" 값은 각각 ECDSA 공개 값과 개인 값이다. 둘 다 [FIPS.186-5] 섹션 6.2에서 정의된다.
[RFC8709] 는 Ed25519와 Ed448을 각각 "ssh-ed25519" 및 "ssh-ed448" 키 타입 이름으로 정의한다. 이들은 다음 메시지를 사용해 에이전트에 추가할 수 있다. "constraints" 필드는 SSH_AGENTC_ADD_ID_CONSTRAINED 메시지에만 포함된다.
textbyte SSH_AGENTC_ADD_IDENTITY or SSH_AGENTC_ADD_ID_CONSTRAINED string "ssh-ed25519" or "ssh-ed448" string ENC(A) string k || ENC(A) string comment constraint[] constraints
첫 번째 값은 EDDSA 공개키 ENC(A) 이다. 두 번째 값은 개인키 k와 공개키 ENC(A)의 연결(concatenation)이다 (이러한 형태의 중복된 공개키 포함은 널리 배포된 구현과의 호환성을 유지하기 위한 것이다). ENC(A)와 k 값의 내용과 해석은 [RFC8032] 섹션 3.2에서 정의된다.
Miller Expires 17 May 2026 [Page 7]
Internet-Draft SSH Agent Protocol November 2025
RSA 키는 키 타입 "ssh-rsa"를 가지며, [RFC4253] 에서 정의된다. 이들은 다음 메시지를 사용해 에이전트에 추가할 수 있다. "constraints" 필드는 SSH_AGENTC_ADD_ID_CONSTRAINED 메시지에만 포함된다.
textbyte SSH_AGENTC_ADD_IDENTITY or SSH_AGENTC_ADD_ID_CONSTRAINED string "ssh-rsa" mpint n mpint e mpint d mpint iqmp mpint p mpint q string comment constraint[] constraints
"n"은 공개 합성 모듈러스(modulus)이다. "e"는 공개 지수(exponent)이다. "d"는 개인 지수이다. "p"와 "q"는 개인 소인(prime factor)이다. "iqmp"는 "q"의 "p"에 대한 모듈러 역수이다. 이 값들 중 "iqmp"를 제외한 나머지는(이는 다른 값들로부터 계산 가능하다) [FIPS.186-5] 섹션 5.1에서 정의된다.
에이전트와 그 클라이언트는 이 문서에 기술되지 않은 추가적인 키 타입을 지원할 수 있다(MAY). 벤더별 키 타입은, IANA에 코드 포인트가 할당될 때까지 [RFC4251] 섹션 4.2에서 정의된 도메인-정규화된 이름 규칙(domain-qualified naming convention)을 반드시 사용해야 한다(MUST).
스마트카드나 기타 하드웨어 토큰에 호스팅된 키는 SSH_AGENTC_ADD_SMARTCARD_KEY 및 SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED 요청을 사용하여 추가할 수 있다. "constraints" 필드는 SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED 변형에서만 포함됨에 주의한다.
textbyte SSH_AGENTC_ADD_SMARTCARD_KEY or SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED string token id string PIN constraint[] constraints
Miller Expires 17 May 2026 [Page 8]
Internet-Draft SSH Agent Protocol November 2025
여기서 "token id"는 하드웨어 토큰에 대한 불투명(opaque) 식별자이며, "PIN"은 키를 잠금 해제하기 위한 선택적 비밀번호 또는 PIN이다. "token id"의 해석은 프로토콜에서 정의하지 않으며, 전적으로 에이전트에 맡겨진다.
일반적으로, 하드웨어 토큰이 지원하는 키 중 공개 구성요소만 에이전트에 로드되므로, 엄밀히 말하면 이 메시지는 실제로 해당 하드웨어 토큰에 대한 향후 개인키 연산을 위임(delegate)하는 역할을 한다.
에이전트는 이러한 메시지의 결과로 하나 이상의 키를 성공적으로 로드했다면 SSH_AGENT_SUCCESS, 키를 찾지 못했다면 SSH_AGENT_FAILURE 로 반드시 응답해야 한다(MUST). "token id"를 인식하지 못했거나 에이전트가 토큰-호스팅 키를 전혀 지원하지 않는 경우에도, 에이전트는 SSH_AGENT_FAILURE를 반환해야 한다(SHOULD).
제약된(constrained) 형태의 키 추가 메시지들에서는 여러 제약조건을 사용할 수 있다. 각 제약조건은 타입 바이트 한 개와 그 뒤에 0개 이상의 값 바이트들로 표현된다.
*_CONSTRAINED 요청으로 키를 추가할 때 0개 이상의 제약조건을 지정할 수 있다. 여러 제약조건은 요청 끝에 연속해서 붙는다.
textbyte constraint1_type byte[] constraint1_data byte constraint2_type byte[] constraint2_data .... byte constraintN_type byte[] constraintN_data
제약조건을 완전히 파싱하려면 그 구조를 사전에 알고 있어야 하며, 알 수 없는 제약조건을 만났을 때 안전하게 복구하는 것은 불가능하다. 따라서, 에이전트가 요청된 제약조건을 인식하지 못하거나 지원하지 않는 경우, 반드시 파싱을 중단하고(MUST), 요청을 거부한 뒤 SSH_AGENT_FAILURE 메시지를 클라이언트에 반환해야 한다.
다음 제약조건들이 정의된다.
이 제약조건은 에이전트가 키의 수명을 제한하도록 요청한다. 에이전트는 키가 추가된 시점으로부터 지정된 기간(초 단위)이 경과하면 키를 삭제해야 한다.
Miller Expires 17 May 2026 [Page 9]
Internet-Draft SSH Agent Protocol November 2025
textbyte SSH_AGENT_CONSTRAIN_LIFETIME uint32 seconds
이 제약조건은, 이 키를 사용하는 각 개인키 연산마다 명시적인 사용자 확인을 요구하도록 에이전트에 요청한다. 예를 들어, 에이전트는 서명 연산을 완료하기 전에 확인 대화상자를 표시할 수 있다.
textbyte SSH_AGENT_CONSTRAIN_CONFIRM
에이전트는 명명된(named) 제약조건을 지원하는 확장 제약조건(extension constraint)을 통해 실험적이거나 사적 용도의 제약조건을 구현할 수 있다.
textbyte SSH_AGENT_CONSTRAIN_EXTENSION string extension name byte[] extension-specific details
확장 이름(extension name)은 UTF-8 문자열로 구성되어야 하며(MUST), [RFC4251] 섹션 6 에서 정의된 이름 규칙을 따라 구현 도메인(implementation domain)을 접미사로 가져야 한다. 예: "foo@example.com".
앞서 언급했듯이, 지원되지 않는 제약조건을 가진 키는 에이전트가 거부해야 하므로, 제약조건 확장은 클라이언트와 에이전트가 모두 이를 지원하는 경우에만 사용할 수 있다. 그렇지 않으면, 에이전트는 키를 거부해야 한다. 이는 바람직한 동작으로, 제약조건 확장은 키에 제한을 명시할 수 있는데, 만약 이 제한이 무시된다면 키가 사용자의 의도와 달리 사용 가능한 상태가 될 수 있기 때문이다(즉, 에이전트는 안전한 방식으로 실패하게 된다).
이전에 에이전트에 로드된 키들은 그들의 공개키 블롭(blob)으로 참조된다. 공개키 블롭은 공개키에 대한 표준 SSH 와이어 인코딩이다. SSH 프로토콜 키 인코딩은 "ssh-rsa" 및 "ssh-dss" 키에 대해 [RFC4253] 에서 정의되며, "ecdsa-sha2-*" 키에 대해 [RFC5656], "ssh-ed25519" 및 "ssh-ed448" 키에 대해 [RFC8709] 에서 정의된다.
클라이언트는 다음 메시지를 사용하여, 에이전트가 보관하는 모든 키의 제거를 요청할 수 있다.
textbyte SSH_AGENTC_REMOVE_ALL_IDENTITIES
Miller Expires 17 May 2026 [Page 10]
Internet-Draft SSH Agent Protocol November 2025
이러한 메시지를 수신하면, 에이전트는 보유하고 있는 모든 키를 삭제해야 하며, 반드시 SSH_AGENT_SUCCESS로 응답해야 한다(MUST).
특정 키만 제거할 수도 있다.
textbyte SSH_AGENTC_REMOVE_IDENTITY string key blob
여기서 "key blob"은 제거할 키의 표준 공개키 인코딩(섹션 3.3)을 의미한다.
에이전트는 키를 삭제했다면 SSH_AGENT_SUCCESS, 키를 찾지 못했다면 SSH_AGENT_FAILURE로 반드시 응답해야 한다(MUST).
토큰-호스팅 키는 다음 메시지를 사용하여 에이전트에서 제거할 수 있다.
textbyte SSH_AGENTC_REMOVE_SMARTCARD_KEY string token id string PIN
여기서 "token id"는 하드웨어 토큰에 대한 불투명 식별자이며, "PIN"은 선택적인 비밀번호 또는 PIN이다(일반적으로 사용되지는 않는다). 둘 다 UTF-8로 인코딩한다. 토큰-호스팅 키 삭제 요청은, 에이전트가 "token id"에 대응되는 장치에서 로드한 모든 키를 제거하도록 해야 한다(SHOULD).
에이전트는 키를 삭제했다면 SSH_AGENT_SUCCESS, 찾지 못했다면 SSH_AGENT_FAILURE로 반드시 응답해야 한다(MUST).
클라이언트는 다음 메시지를 사용하여 에이전트에 키 목록을 요청할 수 있다.
textbyte SSH_AGENTC_REQUEST_IDENTITIES
에이전트는 다음 프리앰블(preamble)을 가진 메시지로 반드시 응답해야 한다(MUST).
textbyte SSH_AGENT_IDENTITIES_ANSWER uint32 nkeys
여기서 "nkeys"는 이어지는 키의 개수를 나타낸다. 프리앰블 뒤에는 0개 이상의 키가 이어지고, 각 키는 다음과 같이 인코딩된다.
textstring key blob string comment
Miller Expires 17 May 2026 [Page 11]
Internet-Draft SSH Agent Protocol November 2025
여기서 "key blob"은 키의 표준 공개키 인코딩(섹션 3.3)이며, "comment"는 UTF-8로 인코딩된 사람이 읽을 수 있는 주석이다.
클라이언트는 다음 메시지를 사용하여 에이전트에 개인키 서명 연산을 요청할 수 있다.
textbyte SSH_AGENTC_SIGN_REQUEST string key blob string data uint32 flags
여기서 "key blob"은 서명을 수행할 키(섹션 3.3에 따라 인코딩)를 의미하며, "data"는 서명할 데이터, "flags"는 0개 이상의 서명 플래그를 비트 OR 연산으로 결합한 비트필드이다(아래 참조).
에이전트가 요청된 플래그를 지원하지 않거나, 기타 이유로 서명을 생성할 수 없거나 생성하기를 원치 않는 경우(예: 해당 키가 에이전트에 없거나, 제약된 키에 대해 사용자가 확인을 거부한 경우), 반드시 SSH_AGENT_FAILURE 메시지로 응답해야 한다(MUST).
성공 시, 에이전트는 다음으로 반드시 응답해야 한다(MUST).
textbyte SSH_AGENT_SIGN_RESPONSE string signature
서명 형식은 사용 중인 키 타입의 알고리즘에 따라 달라진다. SSH 프로토콜 서명 형식은 "ssh-rsa" 및 "ssh-dss" 키에 대해 [RFC4253], "ecdsa-sha2-*" 키에 대해 [RFC5656], "ssh-ed25519" 및 "ssh-ed448" 키에 대해 [RFC8709] 에서 정의된다.
현재 서명 요청 메시지에 대해 정의된 플래그는 두 개이다: SSH_AGENT_RSA_SHA2_256 및 SSH_AGENT_RSA_SHA2_512 (섹션 6.3에서 정의). 이 두 플래그는 "ssh-rsa" 키에 대해서만 유효하며, 각각 "rsa-sha2-256" 또는 "rsa-sha2-512" 서명 방법을 사용한 서명을 에이전트에 요청한다. 이 서명 스킴은 [RFC8332] 에서 정의된다.
Miller Expires 17 May 2026 [Page 12]
Internet-Draft SSH Agent Protocol November 2025
에이전트 프로토콜은 에이전트를 일시적으로 암호(pass-phrase)로 잠글 수 있도록 하는 기능을 지원한다. 잠겨 있는 동안, 에이전트는 (최소한 개인키 서명 연산에 대해서는) 민감한 연산(sensitive operations) 처리를 잠정 중단해야 하며(MUST), 동일한 암호로 잠금 해제되기 전까지는 이를 유지해야 한다.
다음 메시지는 에이전트 잠금을 요청한다.
textbyte SSH_AGENTC_LOCK string passphrase
에이전트는 성공적으로 잠겼다면 SSH_AGENT_SUCCESS, 그렇지 않다면(예: 이미 잠겨 있는 경우) SSH_AGENT_FAILURE로 반드시 응답해야 한다(MUST).
다음 메시지는 에이전트 잠금 해제를 요청한다.
textbyte SSH_AGENTC_UNLOCK string passphrase
에이전트가 이미 잠겨 있고, 제공된 암호가 잠글 때 사용한 것과 일치한다면, 반드시 잠금을 해제하고(MUST), SSH_AGENT_SUCCESS로 응답해야 한다. 에이전트가 이미 잠금 해제된 상태이거나 암호가 일치하지 않는 경우, 반드시 SSH_AGENT_FAILURE로 응답해야 한다(MUST).
에이전트 프로토콜은 선택적인 확장 메커니즘을 포함하고 있으며, 이를 통해 벤더별 및 실험적인 메시지를 에이전트 프로토콜을 통해 전송할 수 있다. 클라이언트로부터의 확장 요청은 다음과 같이 구성된다.
textbyte SSH_AGENTC_EXTENSION string extension type byte[] extension request-specific contents
확장 타입(extension type)은 UTF-8 문자열로, 확장 메시지의 타입을 나타낸다. 구현별 확장은 [RFC4251] 섹션 6에서 정의된 확장 이름 규칙에 따라, 구현 도메인(implementation domain)을 접미사로 가져야 한다(MUST). 예: "foo@example.com".
에이전트가 주어진 타입의 확장을 지원하지 않는다면, 비어 있는 SSH_AGENT_FAILURE 메시지로 응답해야 한다(MUST). 이 응답은 확장 메커니즘을 전혀 지원하지 않는 에이전트에서도 사용된다.
Miller Expires 17 May 2026 [Page 13]
Internet-Draft SSH Agent Protocol November 2025
성공한 확장 응답 메시지의 내용은 확장 타입에 따라 달라진다. 성공적인 확장 요청은, 성공 시 SSH_AGENT_SUCCESS 또는 확장별 응답 메시지 중 하나를 반드시 반환해야 한다(MUST).
textbyte SSH_AGENT_EXTENSION_RESPONSE string extension type byte[] extension response-specific contents
여기서 extension type은 요청 시 사용된 것과 동일하다.
확장 실패는 SSH_AGENT_EXTENSION_FAILURE 메시지를 사용하여 신호를 보내야 한다(SHOULD).
textbyte SSH_AGENT_EXTENSION_FAILURE
확장은 표준 SSH_AGENT_FAILURE 메시지를 사용하지 말아야 한다(SHOULD NOT). 이렇게 하면, 실패한 요청을 해당 확장이 지원되지 않는 경우와 구분할 수 있다.
클라이언트가 에이전트가 어떤(있다면) 확장을 지원하는지 질의할 수 있도록, 단일 선택적 확장 요청 "query"가 정의된다.
textbyte SSH_AGENTC_EXTENSION string "query"
에이전트가 쿼리 확장을 지원한다면, 지원하는 확장 이름 목록으로 응답해야 한다(SHOULD).
textbyte SSH_AGENT_EXTENSION_RESPONSE string "query" string[] supported extension types
에이전트는 로컬 시스템에 연결 지향(connection-oriented) 엔드포인트로 노출된다. 유닉스 계열 시스템에서는, 일반적으로 에이전트가 파일 시스템 기반 Unix 도메인 소켓을 리슨(listen)하도록 구성한다. Microsoft Windows에서는, Windows Named Pipe를 사용하는 것이 일반적이다. 이러한 엔드포인트에 대한 접근은 섹션 8에서 논의된 대로 제어해야 한다.
Miller Expires 17 May 2026 [Page 14]
Internet-Draft SSH Agent Protocol November 2025
두 경우 모두, 리슨 중인 엔드포인트의 이름 또는 주소를 "SSH_AUTH_SOCK"이라는 환경 변수로 노출하는 것이 일반적이다. 에이전트의 클라이언트는 이 변수를 사용해 리슨 중인 에이전트를 찾아 연결한다. 에이전트는, 클라이언트가 엔드포인트를 찾을 수 있도록, 사용자별 기본 위치와 같은 암묵적인 메커니즘을 사용할 수도 있다(MAY).
에이전트 프로토콜은 SSH 연결 위에서 [RFC4254]의 연결 프로토콜을 사용하여 포워딩될 수 있으며, 이를 통해 어떤 세션 채널에 대해서도 에이전트 포워딩을 요청할 수 있다. 이 모델은 X11 포워딩( [RFC4254] 섹션 6.3 )에 대한 연결 프로토콜의 지원과 유사하다. 이 기능은 SSH 프로토콜 및 에이전트 구현에서 선택적(OPTIONAL)이다.
에이전트 포워딩에 대한 지원은, SSH 서버가 [RFC8308] 확장 메커니즘을 사용하여 SSH_MSG_EXT_INFO 메시지 안에서 "agent-forward"라는 이름으로 광고할 수 있다.
textstring "agent-forward" string "0" (version)
이 프로토콜은 [RFC8308] 확장 메커니즘보다 훨씬 먼저 설계되었으며, 에이전트 포워딩을 지원하지만 이 기능을 광고하지 않는 SSH 구현이 여럿 널리 배포되어 있다는 점에 유의한다. SSH 클라이언트는, [RFC8308] 광고가 없는 경우에도, 아래에 언급된 벤더별 이름을 사용하여 에이전트 포워딩을 시도해볼 수 있다(MAY). 마찬가지로, SSH 서버도 이 문서에서 설명하는 이름 외에 벤더별 이름을 추가로 구현할 수 있다(MAY).
SSH 클라이언트는, 이전에 열린 세션( [RFC4254] 섹션 6.1 )에 대해 다음 채널 요청을 사용하여 에이전트 포워딩을 요청할 수 있다. 이 요청은 채널이 열린 이후, 셸, 명령 또는 서브시스템이 실행되기 전에 전송된다.
textbyte SSH_MSG_CHANNEL_REQUEST uint32 channel_id string "agent-req" or "auth-agent-req@openssh.com" boolean want_reply
Miller Expires 17 May 2026 [Page 15]
Internet-Draft SSH Agent Protocol November 2025
여기서 channel_id는 이미 설정된 세션 채널의 식별자로, 이전의 SSH_MSG_CHANNEL_OPEN 요청으로부터 반환된 값이다. want_reply 플래그는 SSH 서버가 요청 성공 여부를 확인하는 응답을 보낼지 여부를 나타내며, [RFC4254] 섹션 5.4 에서 규정한 대로 해석된다.
SSH 서버가 이 요청을 수락하면, 일반적으로 엔드포인트(예: 리슨 소켓)를 제공하도록 구성하고, 이 사실을 하위 세션에 알린다. 대부분의 유닉스 계열 시스템 구현에서는 사용자별(private) 리슨 Unix 도메인 소켓을 제공하고, 그 위치를 SSH_AUTH_SOCK 환경 변수에 기록하는 방식으로 구현한다.
앞서 언급했듯이, 많은 기존 구현은 표준화 이전의 "auth-agent-req@openssh.com" 요청 이름만 지원한다. "agent-req" 이름은 섹션 5.1에서 설명한 방식으로 명시적으로 지원이 광고된 경우에만 사용해야 한다(SHOULD).
SSH 클라이언트가 세션에 대해 에이전트 포워딩을 요청한 후, SSH 서버는 이후에 포워딩된 에이전트에 대한 연결을 요청할 수 있다. SSH 서버는 SSH 클라이언트의 에이전트와 통신하기 위한 전용 채널을 요청함으로써 이를 수행한다.
textbyte SSH_MSG_CHANNEL_OPEN string "agent-connect" or "auth-agent@openssh.com" uint32 channel_id uint32 local_window uint32 local_maxpacket
channel_id, local_window, local_maxpacket 필드는 [RFC4254] 섹션 5.1 에서 규정한 대로 해석해야 한다.
위와 같이, "agent-connect" 채널 타입 이름은 섹션 5.1에서 설명한 방식으로 명시적으로 지원이 광고된 경우에만 사용해야 한다(SHOULD).
SSH 클라이언트는 여러 개의 동시 활성 에이전트 연결을 처리할 수 있어야 한다(SHOULD).
SSH 클라이언트는, 세션을 열지 않고 에이전트 포워딩만 필요로 하는 상황을 지원하기 위해, 사전에 에이전트 포워딩 요청이 없더라도(승인 여부에 따라) 에이전트 연결 요청을 수락할 수 있다(MAY). 마찬가지로, SSH 클라이언트는 에이전트 포워딩이 요청되었던 세션이 종료된 이후에도 에이전트 연결 요청을 계속 수락할 수 있다(MAY).
Miller Expires 17 May 2026 [Page 16]
Internet-Draft SSH Agent Protocol November 2025
SSH 클라이언트는, SSH 클라이언트가 에이전트 포워딩을 원치 않거나 요청하지 않았는데도 SSH 서버가 에이전트 연결 요청을 보내는 경우, 반드시 무단(unauthorised) 에이전트 연결 요청을 거부해야 한다(MUST).
"agent-connect" 요청에는 어떤 세션 채널이 연결 요청을 발생시켰는지를 구분하기 위한 식별자가 포함되지 않으므로, 이 프로토콜을 사용하는 SSH 연결은 사실상 단일 SSH 클라이언트 측 에이전트에 대해서만 접근을 포워딩할 수 있다(단, 그 단일 에이전트에 대한 동시 연결은 여러 개일 수 있다).
다음 번호들은 클라이언트에서 에이전트로의 요청에 사용된다.
textSSH_AGENTC_REQUEST_IDENTITIES 11 SSH_AGENTC_SIGN_REQUEST 13 SSH_AGENTC_ADD_IDENTITY 17 SSH_AGENTC_REMOVE_IDENTITY 18 SSH_AGENTC_REMOVE_ALL_IDENTITIES 19 SSH_AGENTC_ADD_SMARTCARD_KEY 20 SSH_AGENTC_REMOVE_SMARTCARD_KEY 21 SSH_AGENTC_LOCK 22 SSH_AGENTC_UNLOCK 23 SSH_AGENTC_ADD_ID_CONSTRAINED 25 SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED 26 SSH_AGENTC_EXTENSION 27
다음 번호들은 에이전트에서 클라이언트로의 응답에 사용된다.
textSSH_AGENT_FAILURE 5 SSH_AGENT_SUCCESS 6 SSH_AGENT_IDENTITIES_ANSWER 12 SSH_AGENT_SIGN_RESPONSE 14 SSH_AGENT_EXTENSION_FAILURE 28 SSH_AGENT_EXTENSION_RESPONSE 29
다음 메시지 번호들은 레거시 SSH 프로토콜 버전 1을 지원하는 구현을 위해 예약되어 있다: 1-4, 7-10, 15-16 및 24(포함). 이 메시지 번호들은 레거시 프로토콜을 지원하는 구현에서만 사용할 수 있으며(MAY), 그 외 용도로 재사용되어서는 안 된다(MUST NOT).
Miller Expires 17 May 2026 [Page 17]
Internet-Draft SSH Agent Protocol November 2025
메시지 번호 240-255 범위는 조직(organization)-로컬 에이전트 프로토콜 확장을 위해 예약되어 있으며, 범용 구현에서는 사용해서는 안 된다(MUST NOT).
다음 번호들은 키 제약조건을 식별하는 데 사용된다. 이 값들은 키 제약조건에서만 사용되며, 메시지 번호로는 사용되지 않는다.
textSSH_AGENT_CONSTRAIN_LIFETIME 1 SSH_AGENT_CONSTRAIN_CONFIRM 2 SSH_AGENT_CONSTRAIN_EXTENSION 255
다음 번호들은 서명 요청(SSH_AGENTC_SIGN_REQUEST) 메시지에 존재할 수 있다. 이 플래그들은 0개 이상의 플래그를 논리 OR 한 비트필드를 형성한다.
textSSH_AGENT_RSA_SHA2_256 0x00000002 SSH_AGENT_RSA_SHA2_512 0x00000004
플래그 값 1은 과거 구현을 위해 예약(reserved)되어 있다.
이 프로토콜은 네 개의 레지스트리(registry)가 필요하다. 하나는 메시지 번호, 하나는 제약조건, 하나는 서명 요청 플래그, 하나는 확장 요청 이름을 위한 것이다. 추가로, 기존의 세 레지스트리에 대해 신규 코드 포인트가 요청된다.
"SSH agent protocol numbers" 라는 제목의 이 레지스트리는, 클라이언트 요청 및 에이전트 응답에 대한 메시지 번호를 기록한다. 이 레지스트리는 Secure Shell (SSH) Protocol Parameters 레지스트리 그룹 [RFC4250] 에서 생성되어야 한다. 초기 상태는 다음 번호 및 예약 항목들로 구성되어야 한다. 이후 메시지 번호 할당은 [RFC8126] 에 따른 EXPERT REVIEW 절차를 통해 이루어진다.
| Number(s) | Identifier | Reference | |==========:|:-----------------------------------------|:--------------------------| | 1 | reserved | thisrfc, Section 6.1.1 | | 2 | reserved | thisrfc, Section 6.1.1 | | 3 | reserved | thisrfc, Section 6.1.1 | | 4 | reserved | thisrfc, Section 6.1.1 | | 5 | SSH_AGENT_FAILURE | thisrfc, Section 6.1 | | 6 | SSH_AGENT_SUCCESS | thisrfc, Section 6.1 | | 7 | reserved | thisrfc, Section 6.1.1 | | 8 | reserved | thisrfc, Section 6.1.1 | | 9 | reserved | thisrfc, Section 6.1.1 | | 10 | reserved | thisrfc, Section 6.1.1 | | 11 | SSH_AGENTC_REQUEST_IDENTITIES | thisrfc, Section 6.1 | | 12 | SSH_AGENT_IDENTITIES_ANSWER | thisrfc, Section 6.1 | | 13 | SSH_AGENTC_SIGN_REQUEST | thisrfc, Section 6.1 | | 14 | SSH_AGENT_SIGN_RESPONSE | thisrfc, Section 6.1 | | 15 | reserved | thisrfc, Section 6.1.1 | | 16 | reserved | thisrfc, Section 6.1.1 | | 17 | SSH_AGENTC_ADD_IDENTITY | thisrfc, Section 6.1 | | 18 | SSH_AGENTC_REMOVE_IDENTITY | thisrfc, Section 6.1 | | 19 | SSH_AGENTC_REMOVE_ALL_IDENTITIES | thisrfc, Section 6.1 | | 20 | SSH_AGENTC_ADD_SMARTCARD_KEY | thisrfc, Section 6.1 | | 21 | SSH_AGENTC_REMOVE_SMARTCARD_KEY | thisrfc, Section 6.1 | | 22 | SSH_AGENTC_LOCK | thisrfc, Section 6.1 | | 23 | SSH_AGENTC_UNLOCK | thisrfc, Section 6.1 | | 24 | reserved | thisrfc, Section 6.1.1 | | 25 | SSH_AGENTC_ADD_ID_CONSTRAINED | thisrfc, Section 6.1 | | 26 | SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED | thisrfc, Section 6.1 | | 27 | SSH_AGENTC_EXTENSION | thisrfc, Section 6.1 | | 28 | SSH_AGENT_EXTENSION_FAILURE | thisrfc, Section 6.1 | | 29 | SSH_AGENT_EXTENSION_RESPONSE | thisrfc, Section 6.1 | | 240-255 | Reserved for organizational use | thisrfc, Section 6.1 |
Table 1
Miller Expires 17 May 2026 [Page 18-20]
Internet-Draft SSH Agent Protocol November 2025
"SSH agent key constraint numbers" 라는 제목의 이 레지스트리는 키 사용 제약조건에 대한 번호를 기록한다. 이 레지스트리는 Secure Shell (SSH) Protocol Parameters 레지스트리 그룹 [RFC4250] 에서 생성되어야 한다. 초기 상태는 다음 번호들로 구성되어야 한다. 이후 메시지 번호 할당은 [RFC8126] 에 따른 EXPERT REVIEW 절차를 통해 이루어진다.
| Number | Identifier | Reference |
|---|---|---|
| 1 | SSH_AGENT_CONSTRAIN_LIFETIME | thisrfc, Section 6.2 |
| 2 | SSH_AGENT_CONSTRAIN_CONFIRM | thisrfc, Section 6.2 |
| 255 | SSH_AGENT_CONSTRAIN_EXTENSION | thisrfc, Section 6.2 |
Table 2
Miller Expires 17 May 2026 [Page 21]
Internet-Draft SSH Agent Protocol November 2025
"SSH agent signature flags" 라는 제목의 이 레지스트리는 서명 요청(SSH_AGENTC_SIGN_REQUEST)에 사용되는 플래그 값들을 기록한다. 이 레지스트리는 Secure Shell (SSH) Protocol Parameters 레지스트리 그룹 [RFC4250] 에서 생성되어야 한다. 초기 상태는 다음 번호들로 구성되어야 한다. 플래그들은 비트 OR 로 결합된다는 점에 유의하며, 모든 플래그 값은 2의 거듭제곱이어야 하고, 사용 가능한 최대 플래그 값은 0x80000000 이다.
이후 메시지 번호 할당은 [RFC8126] 에 따른 EXPERT REVIEW 절차를 통해 이루어진다.
| Number | Identifier | Reference |
|---|---|---|
| 0x01 | reserved | thisrfc, Section 6.3 |
| 0x02 | SSH_AGENT_RSA_SHA2_256 | thisrfc, Section 6.3 |
| 0x04 | SSH_AGENT_RSA_SHA2_512 | thisrfc, Section 6.3 |
Table 3
"SSH agent extension request names" 라는 제목의 이 레지스트리는 일반 확장 요청 메시지(SSH_AGENTC_EXTENSION)에서 사용되는 이름들을 기록한다. 이 레지스트리는 Secure Shell (SSH) Protocol Parameters 레지스트리 그룹 [RFC4250] 에서 생성되어야 한다. 초기 상태는 다음 이름들로 구성되어야 한다.
향후 이름 할당은 [RFC8126] 에 따른 EXPERT REVIEW 절차를 통해 이루어진다.
| Extension Name | Reference |
|---|---|
| query | thisrfc, Section 3.8.1 |
Table 4
Miller Expires 17 May 2026 [Page 22]
Internet-Draft SSH Agent Protocol November 2025
IANA는 Secure Shell (SSH) Protocol Parameters 레지스트리 그룹 [RFC4250] 의 Extension Names [IANA-SSH-EXT] 테이블에 다음 항목을 추가해 줄 것이 요청된다.
| Extension Name | Reference |
|---|---|
| agent-forward | thisrfc, Section 5.1 |
Table 5
IANA는 Secure Shell (SSH) Protocol Parameters 레지스트리 그룹 [RFC4250] 의 Connection Protocol Channel Request Names [IANA-SSH-CHANREQ] 테이블에 다음 항목을 추가해 줄 것이 요청된다.
| Request Type | Reference |
|---|---|
| agent-req | thisrfc, Section 5.2 |
Table 6
IANA는 Secure Shell (SSH) Protocol Parameters [RFC4250] 의 Connection Protocol Channel Types [IANA-SSH-CHANTYPE] 테이블에 다음 항목을 추가해 줄 것이 요청된다.
| Request Type | Reference |
|---|---|
| agent-connect | thisrfc, Section 5.3 |
Table 7
Miller Expires 17 May 2026 [Page 23]
Internet-Draft SSH Agent Protocol November 2025
지정 전문가(Designated Expert, DE)가 위에서 설명한 신규 레지스트리(섹션 7.1, 7.2, 7.3, 7.4)에 대한 추가 요청을 검토하도록 요청받은 경우, [RFC5226] 에서 설명한 적절한 문서가 존재하며 영구적이고 공개적으로 이용 가능함을 확인해야 한다. DE는 요청된 코드 포인트에 대한 목적과 사용 방식의 명확성 또한 확인해야 한다. 또한, IETF에서 작성된 명세가 이들 레지스트리에 코드 포인트를 요청하는 경우, 해당 명세가 SSHM 워킹 그룹 및 ssh@ietf.org 메일링 리스트에 검토를 위해 제공되었는지 확인해야 한다. IETF 외부에서 작성된 명세를 위한 코드 포인트 요청은, 진행 중인 IETF 작업이나 기존 IETF 명세와 충돌해서는 안 된다.
SSH 에이전트 프로토콜 번호(섹션 7.1) 및 SSH 에이전트 서명 플래그(섹션 7.3) 레지스트리에서 사용 가능한 코드 포인트 수는 제한적이므로, DE는 코드 포인트 사용이 충분히 정당화되었는지 특히 주의를 기울여야 한다. SSH 에이전트 프로토콜 번호의 경우, 명명된 확장 요청(섹션 7.4)은 대부분의 사용 사례에서 대체 방안을 제공하며, 실질적으로 사용 가능한 코드 포인트 수에 제한이 없다.
에이전트는 일반적으로 장기적인 로그인 인증 자격증명(long-lived login authentication credentials)을 보관하고, 이에 대한 통제된 접근을 제공하는 서비스이다. 그 성격상 민감하고 신뢰받는 소프트웨어 구성요소이다. 더구나, 에이전트 프로토콜 자체는 어떤 인증이나 전송 보안(transport security)도 포함하지 않는다. 일반적으로, 에이전트와 통신할 수 있다는 것만으로도, 그 에이전트에 개인키 연산을 수행하도록 요청하기에는 충분하다.
에이전트에 접근할 수 있으면 개인키 연산을 수행할 수 있다는 점을 고려하면, 에이전트는 반드시 소유자와 그가 허가한 대리인에게만 노출되도록 하는 것이 매우 중요하다. 유닉스 계열 시스템에서는 파일 시스템 권한을 통해 에이전트 소켓에 대한 접근을 제어하고, 소켓에 연결된 클라이언트의 신원을 확인하는 메커니즘(e.g. 일부 유닉스 계열 시스템의 SO_PEERCRED)을 사용함으로써 이를 달성할 수 있다. Windows에서는, Named Pipe 생성 시 보안 설명자(security descriptor)를 부여하여 접근을 제어할 수 있다.
에이전트의 주요 설계 목표는, 공격자가 피해자의 에이전트에 비특권(unprivileged) 접근 권한을 얻더라도, 에이전트에 로드된 키의 사본을 얻지 못하도록 하는 것이다. 다만, 키가 확인 제약조건 없이 로드된 경우, 공격자가 그 키의 사용 자체를 도용(steal)하는 것(예: 서명 호출)을 막지는 못할 수도 있다.
Miller Expires 17 May 2026 [Page 24]
Internet-Draft SSH Agent Protocol November 2025
이러한 점을 고려하면, 에이전트는 가능한 한 다른 프로세스가 자신의 메모리를 읽지 못하도록 하여 로드된 키의 탈취를 방지해야 한다. 여기에는 일반적으로 디버깅 인터페이스를 비활성화하고, 비정상 종료 시 프로세스 메모리 덤프 생성을 방지하는 것이 포함된다.
또 다른, 더 미묘한 키 탈취 수단으로는 암호학적 사이드 채널이 있다. 개인키 연산은, 에이전트가 동작하는 호스트의 시간 차이, 전력 소비, 메모리 서브시스템(예: CPU 캐시)의 부수적인 효과(side-effects)를 통해 키의 내용에 관한 정보를 누출할 수 있다. 로컬 공격자와 제약조건 없는 키를 보유한 에이전트라는 상황을 가정하면, 공격자가 관찰할 수 있는 개인키 연산 횟수는 CPU가 서명 연산을 수행할 수 있는 속도에 의해서만 제한된다. 이는 공격자에게 사이드 채널 공격을 위한 거의 이상적인 오라클(oracle)을 제공한다. 사이드 채널 공격에 대한 완전한 논의는 이 명세의 범위를 벗어나지만, 에이전트는 사이드 채널 공격에 강인한 암호 구현을 사용해야 하며(SHOULD), 개인키 연산에 실제로 소요되는 시간을 숨기기 위해 추가적인 조치를 취할 수도 있다(MAY).
로컬 에이전트에 대한 접근을 SSH 연결을 통해 포워딩하는 것(섹션 5)은 본질적으로 전이적 신뢰 관계(transitive trust relationship)를 생성한다. SSH 구현은 기본적으로 에이전트 사용 포워딩을 수행하지 않아야 하며(SHOULD NOT), 포워딩된 에이전트 연결에 대해서는 키 가시성 및 사용에 대한 추가적인 통제 메커니즘을 구현해야 한다(SHOULD).
토큰/스마트카드에 호스팅된 키의 구현에도 주의가 필요하다. 일부 시스템에서는, 장치에 호스팅된 키를 사용하기 위해 공유 라이브러리(shared library)의 경로를 제공하여 토큰을 호출해야 할 수 있다(예: 특정 PKCS#11 모듈 라이브러리 경로). 대부분의 플랫폼에서 공유 라이브러리를 로드하는 것은, 그 라이브러리 안의 코드가 로드를 수행하는 프로세스의 주소 공간 내에서 자동으로 실행됨을 의미한다. 토큰-호스팅 키 로드를 지원하는 에이전트는, 신뢰할 수 있는 토큰 제공자 라이브러리만 로드 가능하도록 해야 하며(SHOULD), 로드된 토큰 라이브러리 코드가 에이전트에 로드된 다른 키에 접근할 수 없도록 해야 하고(SHOULD), 원격 클라이언트가 토큰 키를 로드하는 것을 완전히 허용하지 않을 수도 있다(MAY).
기존 키를 토큰 라이브러리 코드로부터 보호하는 한 가지 방법은, 토큰 라이브러리를 에이전트와 별도의 프로세스에 로드하고, 에이전트가 IPC를 통해 이 프로세스에 토큰 연산을 위임하도록 구성하는 것이다.
Miller Expires 17 May 2026 [Page 25]
Internet-Draft SSH Agent Protocol November 2025
마지막으로, 섹션 3.7의 에이전트 잠금 기능과 관련하여, 에이전트는 암호에 대한 무차별 대입(brute-force guessing) 공격에 대한 대응책(countermeasure)을 마련해야 한다(SHOULD). 이는, 잘못된 암호로 잠금 해제 시도가 있을 때 강제 지연을 두고(후속 실패에 대해 점진적으로 증가시킬 수 있음), 일정 횟수 이상 잠금 해제 실패가 발생하면 일정 시간 동안 추가 요청을 거부하는 락아웃(lockout) 기간을 두거나, 잠금 해제 실패가 일정 임계치를 넘으면 에이전트가 보유한 모든 키를 삭제하는 방식이 될 수 있다.
이 섹션은 RFC로 발행되기 전에 제거되어야 한다.
편집자에게 주: RFC7942에 대한 고아 참조(orphaned reference)도 함께 제거해 주시기 바란다.
이 섹션은 [RFC7942] 에서 제안된 방식에 따라, 이 인터넷-초안이 게시될 당시 이 명세에서 정의한 프로토콜의 알려진 구현 상태를 기록한다. 이 섹션의 구현 설명은 IETF가 초안을 RFC로 진행시키는 과정에서 의사결정에 도움이 되는 것을 목적으로 한다. 여기에 나열된 개별 구현은 IETF가 이를 보증한다는 의미가 아니다. 또한, 여기 제시된 정보는 IETF 기여자들이 제공한 내용을 별도로 검증한 것이 아니다. 이 목록은 사용 가능한 구현이나 그 기능을 나열한 카탈로그가 아니며, 그렇게 해석해서도 안 된다. 다른 구현이 존재할 수 있음에 유의해야 한다.
[RFC7942] 에 따르면, "이는 검토자와 워킹 그룹이 실제 동작하는 코드(running code)의 혜택을 받은 문서에 적절한 주의를 기울이도록 하며, 그 코드는 귀중한 실험 및 피드백의 증거가 되어 구현된 프로토콜을 더욱 성숙하게 만들 수 있다. 이 정보를 어떻게 활용할지는 개별 워킹 그룹에 달려 있다." 라고 한다.
다음 프로젝트들은 이 프로토콜의 구현을 유지하고 있다.
OpenSSH
OpenSSH는 이 프로토콜의 원래 구현체이며, 2000년부터 이를 지원해 왔다.
웹사이트: https://www.openssh.com/
PuTTY
PuTTY는 다중 플랫폼용 인기 SSH 클라이언트 구현체이며, 2001년부터 호환 가능한 에이전트 클라이언트를 포함해 왔다.
Miller Expires 17 May 2026 [Page 26]
Internet-Draft SSH Agent Protocol November 2025
Dropbear
Dropbear는 유닉스 계열 시스템용 SSH 클라이언트 및 서버 구현체이다. 2005년부터 에이전트 프로토콜을 지원해 왔다.
Paramiko
Paramiko는 Python 프로그래밍 언어로 작성된 SSH 클라이언트 및 서버 구현체이다. 2005년부터 에이전트 프로토콜 구현을 지원해 왔다.
Golang x/crypto/ssh/agent
Go 프로그래밍 언어 프로젝트는 2015년부터 외부 "x" 리포지토리에서 이 프로토콜의 구현을 지원해 왔다.
이 목록은 완전하지 않다.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, https://www.rfc-editor.org/info/rfc4250.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, https://www.rfc-editor.org/info/rfc4251.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, https://www.rfc-editor.org/info/rfc4253.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, January 2006, https://www.rfc-editor.org/info/rfc4254.
Miller Expires 17 May 2026 [Page 27]
Internet-Draft SSH Agent Protocol November 2025
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, https://www.rfc-editor.org/info/rfc5226.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, https://www.rfc-editor.org/info/rfc5656.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, https://www.rfc-editor.org/info/rfc8032.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 2018, https://www.rfc-editor.org/info/rfc8308.
[RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol", RFC 8332, DOI 10.17487/RFC8332, March 2018, https://www.rfc-editor.org/info/rfc8332.
[RFC8709] Harris, B. and L. Velvindron, "Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol", RFC 8709, DOI 10.17487/RFC8709, February 2020, https://www.rfc-editor.org/info/rfc8709.
[FIPS.186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, https://doi.org/10.6028/NIST.FIPS.186-4.
[FIPS.186-5] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-5, DOI 10.6028/NIST.FIPS.186-5, February 2023, https://doi.org/10.6028/NIST.FIPS.186-5.
Miller Expires 17 May 2026 [Page 28]
Internet-Draft SSH Agent Protocol November 2025
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, https://www.rfc-editor.org/info/rfc7942.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, https://www.rfc-editor.org/info/rfc8126.
[IANA-SSH-CHANREQ] IANA, "Connection Protocol Channel Types", https://www.iana.org/assignments/ssh-parameters/.
[IANA-SSH-CHANTYPE] IANA, "Extension Names", https://www.iana.org/assignments/ssh-parameters/.
[IANA-SSH-EXT] IANA, "Connection Protocol Channel Request Names", https://www.iana.org/assignments/ssh-parameters/.
[draft-ietf-secsh-agent-02] Ylonen, T., Rinne, T. J., and S. Lehtinen, "Secure Shell Authentication Agent Protocol", January 2004, https://datatracker.ietf.org/doc/html/draft-ietf-secsh-agent-02.
이 프로토콜은 Markus Friedl에 의해 설계되고 처음 구현되었으며, 이는 Tatu Ylonen이 설계한 레거시 SSH 버전 1용 에이전트 프로토콜을 기반으로 한다.
이 문서를 검토하고 개선하는 데 도움을 준 Simon Tatham, Niels Möller, James Spencer, Simon Josefsson, Matt Johnston, Jakub Jelen, Rich Salz, Caspar Schutijser, Florian Obser, Martin Thomson, Deb Cooley, Tero Kivinen에게 감사한다.
Damien Miller
OpenSSH
Email: djm@openssh.com
URI: https://www.openssh.com/
Miller Expires 17 May 2026 [Page 29]
