KerberosはSSHとどのように機能しますか？

ラップトップ、サーバー1、サーバー2、Kerberosサーバーの4つのコンピューターがあるとします。

• LからS1にPuTTYまたはSSHを使用してログインし、ユーザー名/パスワードを入力します
• S1からS2にSSHで接続します。Kerberosは私を認証するため、パスワードは必要ありません

重要なすべてのSSHおよびKRB5プロトコル交換について説明します。「Lはユーザー名をS1に送信します」、「Kは...をS1に送信します」など。

（この質問はコミュニティで編集されることを意図しています。専門家でない読者のために改善してください。）

最初のログイン：

• Lはユーザー名とSSH認証要求をS1に送信します
• S1は、使用可能なSSH認証メカニズムを返します。「パスワード」はその1つです
• 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に添付します。サーバーはタイムスタンプを解読し、許可されたタイムスキュー内であることを確認します。復号化に失敗すると、パスワードはすぐに拒否されます。それ以外の場合、AS-REPでTGTが返されます。
  2. S1は、パスワードから生成されたキーを使用してTGTを復号化しようとします。復号化に成功すると、パスワードは正しいものとして受け入れられます。
  3. TGTは、新しく作成された資格情報キャッシュに保存されます。（$KRB5CCNAME環境変数を調べてccacheを見つけるか、klistその内容をリストするために使用できます。）
• S1はPAMを使用して許可チェック（構成に依存）を実行し、セッションを開きます。
  • pam_krb5承認段階で呼び出された場合、~/.k5login存在するかどうかを確認します。存在する場合、クライアントKerberosプリンシパルをリストする必要があります。それ以外の場合、許可されるプリンシパルはのみです。username@DEFAULT-REALM

2回目のログイン：

• S1はユーザー名とSSH認証リクエストをS2に送信します
• S2は使用可能な認証メカニズムを返します。そのうちの1つは「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はP1を使用して許可チェックを実行し、S1と同様にセッションを開きます。
• 資格情報の転送が有効で、TGTに「forwardable」フラグがある場合、S1はユーザーのTGTのコピー（「forwarded」フラグが設定された）を要求し、それをS2に送信し、そこで新しいccacheに保存されます。これにより、Kerberos認証による再帰ログインが許可されます。

TGTもローカルで取得できることに注意してください。Linuxでは、を使用してこれを実行しkinit、を使用して接続できますssh -K。Windowsの場合、Windows ADドメインにログインしている場合、Windowsがそれを行います。それ以外の場合は、MIT Kerberosを使用できます。PuTTY 0.61は、Windows（SSPI）とMIT（GSSAPI）の両方の使用をサポートしていますが、転送（委任）を手動で有効にする必要があります。

¹ gssapi-keyexも可能ですが、公式のOpenSSHには受け入れられませんでした。

簡単に言うと、理想的には、kinitコマンドまたはいわゆる「シングルサインオン」セットアップのローカルログインシーケンスの一部として、Kerberosチケットを端末（L）で取得する必要があります。これで、リモートシステム（S1、S2）はパスワードプロンプトなしでアクセス可能になります。「チケット転送」として知られる技術を使用することにより、連鎖アクセス（L→S1→S2）が可能になります。このような設定では、特にKDCがターミナル（L）から直接アクセスできる必要があります。

grawityによるもう1つの答えは、このアプローチを詳細に説明しています。

ここでの唯一の非自明な手順は、資格情報を使用してSにPAMモジュールがあり、kinitKからチケット許可チケットを取得することです（クライアント認証）。次に、Kerberos認証を使用してS2にSSH接続すると、クライアントサービス認証が行われます。メッセージごとにすべての退屈なやり取りを経験することのメリットがわかりません。

-vvvすべてのメッセージを表示し、WikipediaのKerberosの説明を読みたい場合は、sshコマンドでa をスローします。