最初のログイン:
- L はユーザー名と SSH 認証リクエストを S1 に送信します
- S1 は利用可能な SSH 認証メカニズムを返します。そのうちの 1 つは「パスワード」です
- L は「パスワード」を選択し、平文のパスワードを S1 に送信します
- S1 はユーザー名とパスワードを PAM スタックに渡します
- S1 では、PAM (通常は
pam_krb5またはpam_sss) は、Kerberos KDC から TGT (チケット許可チケット) を要求します。 <オール> - S1 は TGT を取得します。
- 古いスタイル (事前認証なし):S1 は AS-REQ を送信し、TGT を含む AS-REP を受信します。
- 新しいスタイル (事前認証あり):S1 はパスワードを使用して現在のタイムスタンプを暗号化し、AS-REQ に添付します。サーバーはタイムスタンプを復号化し、許容される時間のずれの範囲内であることを確認します。復号化に失敗すると、パスワードはすぐに拒否されます。それ以外の場合は、AS-REP で TGT が返されます。
- S1 は、パスワードから生成されたキーを使用して TGT の復号化を試みます。復号化に成功すると、パスワードは正しいものとして受け入れられます。
- TGT は、新しく作成された資格情報キャッシュに保存されます。 (
$KRB5CCNAMEを調べることができます 環境変数で ccache を見つけるか、klistを使用します。 その内容を一覧表示します。) - S1 は PAM を使用して認証チェック (構成に依存) を実行し、セッションを開きます。
- If
pam_krb5承認段階で呼び出され、~/.k5loginかどうかをチェックします 存在します。その場合、クライアントの Kerberos プリンシパルをリストする必要があります。それ以外の場合、許可される唯一のプリンシパルはusername@DEFAULT-REALMです .
- If
2 回目のログイン:
- S1 はユーザー名と SSH 認証リクエストを S2 に送信します
- S2 は利用可能な認証メカニズムを返します。そのうちの 1 つは「gssapi-with-mic」です
- S1 は
host/s2.example.com@EXAMPLE.COMのチケットをリクエストします 、TGT を含む TGS-REQ を KDC に送信し、そこからサービス チケットを含む TGS-REP を受信します。 - 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 には受け入れられませんでした。