Kerberos는 SSH와 어떻게 작동합니까?

랩톱, 서버 1, 서버 2, Kerberos 서버의 네 대의 컴퓨터가 있다고 가정합니다.

• PuTTY 또는 SSH를 사용하여 L에서 S1로 로그인하여 사용자 이름 / 비밀번호를 제공합니다
• S1에서 SSH로 S2로. Kerberos가 나를 인증하므로 비밀번호가 필요하지 않습니다

"L은 사용자 이름을 S1에 보냅니다", "K는 ...를 S1에 보냅니다"등 모든 중요한 SSH 및 KRB5 프로토콜 교환을 설명합니다.

(이 질문은 커뮤니티 편집 용 입니다. 비전문가 독자 를 위해 개선하십시오 .)

첫 로그인 :

• L은 사용자 이름과 SSH 인증 요청을 S1에 보냅니다.
• S1은 사용 가능한 SSH 인증 메커니즘을 "비밀번호"와 함께 반환합니다.
• L은 "암호"를 선택하고 일반 암호를 S1에 보냅니다.
• S1은 사용자 이름과 비밀번호를 PAM 스택에 제공합니다.
• S1에서 PAM (보통 pam_krb5또는 pam_sss)은 Kerberos KDC에 TGT (티켓 부여 티켓)를 요청합니다.
  1. S1은 TGT를 얻는다.
     • 이전 스타일 (사전 인증없이) : S1은 AS-REQ를 전송하고 TGT가 포함 된 AS-REP를 수신합니다.
     • 새로운 스타일 (사전 인증 포함) : S1은 비밀번호를 사용하여 현재 타임 스탬프를 암호화하고 AS-REQ에 첨부합니다. 서버는 타임 스탬프를 해독하고 허용 된 시간 차이 내에 있는지 확인합니다. 암호 해독에 실패하면 암호가 즉시 거부됩니다. 그렇지 않으면 TGT가 AS-REP에 리턴됩니다.
  2. S1은 암호에서 생성 된 키를 사용하여 TGT의 암호 해독을 시도합니다. 암호 해독에 성공하면 암호가 올바른 것으로 수락됩니다.
  3. TGT는 새로 생성 된 자격 증명 캐시에 저장됩니다. ( $KRB5CCNAME환경 변수를 검사하여 ccache를 찾거나 klist해당 내용을 나열 하는 데 사용할 수 있습니다.)
• S1은 PAM을 사용하여 권한 부여 검사 (구성에 따라 다름)를 수행하고 세션을 엽니 다.
  • pam_krb5권한 부여 단계에서 호출 되면 ~/.k5login존재 여부를 확인합니다 . 그렇다면 클라이언트 Kerberos 프린시 펄을 나열해야합니다. 그렇지 않으면 허용되는 유일한 주체는 입니다.username@DEFAULT-REALM

두 번째 로그인 :

• S1은 S2에 사용자 이름 및 SSH 인증 요청을 보냅니다.
• S2는 사용 가능한 인증 mechs를 반환, 그 중 하나는 "gssapi-with-mic" ¹
• S1 은 TGT가 포함 된 TGS-REQ를 KDC에 전송하고 서비스 티켓이 포함 된 TGS-REP를 수신하여 티켓을 요청합니다.host/s2.example.com@EXAMPLE.COM
• S1은 "AP-REQ"(인증 요청)를 생성하여 S2로 보냅니다.
• S2가 요청의 암호 해독을 시도합니다. 성공하면 인증이 완료됩니다. (PAM은 인증에 사용되지 않습니다.)
  • LDAP와 같은 다른 프로토콜은 요청에 포함 된 "세션 키"를 사용하여 추가 데이터 전송을 암호화하도록 선택할 수 있습니다. 그러나 SSH는 이미 자체 암호화 계층을 협상했습니다.
• 인증에 성공하면 S2는 PAM을 사용하여 S1과 동일한 권한 검사를 수행하고 세션을 엽니 다.
• 신임 정보 전달이 사용 가능하고 TGT에 "전달 가능"플래그가있는 경우 S1은 사용자의 TGT 사본 ( "전달됨"플래그가 설정된)을 요청하고이를 S2로 전송하여 새 ccache에 저장합니다. 이것은 재귀 Kerberos 인증 로그인을 허용합니다.

TGT도 로컬에서 얻을 수 있습니다. Linux에서는을 사용하여이 작업을 수행 kinit한 다음을 사용하여 연결하십시오 ssh -K. Windows의 경우 Windows AD 도메인에 로그인하면 Windows가 자동으로이를 수행합니다. 그렇지 않으면 MIT Kerberos를 사용할 수 있습니다. PuTTY 0.61은 Windows (SSPI) 및 MIT (GSSAPI) 사용을 모두 지원하지만 수동으로 전달 (위임)을 활성화해야합니다.

¹ gssapi-keyex 도 가능하지만 공식 OpenSSH에는 수용되지 않았습니다.

간단히 말해서, 이상적으로는 Kerberos 티켓은 kinit소위 "싱글 사인온"설정에서 명령 또는 로컬 로그인 시퀀스의 일부로 터미널 (L)에서 얻어야합니다 . 그러면 비밀번호 프롬프트없이 원격 시스템 (S1, S2)에 액세스 할 수 있습니다. "티켓 포워딩"이라고 알려진 기술을 사용하면 체인 액세스 (L → S1 → S2)가 가능합니다. 이러한 설정은 특히 KDC가 터미널 (L)에서 직접 액세스 할 수 있어야합니다.

grawity 의 다른 답변은 이 접근법을 자세히 설명합니다.

여기서 명백한 유일한 단계는 S1에 자격 증명을 사용하여 kinitK (클라이언트 인증)로부터 티켓을 부여 하는 PAM 모듈이 있다는 것입니다 . 그런 다음 Kerberos 인증을 사용하여 S2에 SSH하면 클라이언트 서비스 인증이 수행됩니다. 나는 지루한 모든 교환 메시지를 메시지로 통해 얻는 이점을 보지 못합니다.

-vvv모든 메시지를보고 Kerberos에 대한 Wikipedia 설명 을 읽으려면 ssh 명령 에을 던지십시오 .