Putty Kerberos / GSSAPI認証

RHEL6でsssdを使用してActive Directory Kerberosで認証するようにいくつかのLinuxサーバーを構成しました。パスワードなしのログインを期待してGSSAPI認証も有効にしました。

しかし、パスワードなしでPutty（0.63）を認証するようには思えません。

GSSAPIは、AD認証用に構成されたLinuxシステム（openSSHクライアント）間で動作し、.ssh / config設定を使用してGSSAPIを有効にします。

Cygwin（openSSHクライアント）からも機能し、同じ.ssh / config設定を使用し、kinitコマンドを実行してチケットを取得します。

また、SambaはすべてのLinuxシステムで共有します。これには、ホームディレクトリーがWindowsエクスプローラーからパスワードなしで機能します（GSSAPIがそこで機能するかどうかはわかりません）。

これをトラブルシューティングするにはどうすればよいですか？私のユーザーのほとんどはパテを使用しています。また、私はWindows管理者ではないため、ドメインコントローラーで何もできません。私のアカウントには、ADドメインにサーバーを追加する権限しかありません。

パテSSHパケットロギングをオンにしました。私はこの種の興味深いものを見つけました、この情報をどうするかまだわかりません：

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.

Active Directoryドメインの一部であるWindowsマシンでは、ユーザーはWindowsにログインしたときにKerberosチケット認可チケットを受け取り、PuTTYは、GSSAPI認証がPuTTY Configuration Connection | SSH | Auth | GSSAPIで有効になっている場合、認証に使用できます。 （Pageant経由の公開鍵など、GSSAPIの前に試行する他の認証方法は、Connection | SSH | Authで設定または無効化されていません）。

[あなたはまた、GSSAPIの代表団はまた、パテで有効になっている、ことを確認してください、（ログイン後、サーバー上のKerberos対応ファイルシステムをマウントするために、例えば）チケット委任を必要とする場合と、あなたは、ログイン先のサーバは次のように委任]タブで、Active Directoryにマークされています「すべてのサービスへの委任に対してこのコンピュータを信頼する（Kerberosのみ）」。デフォルトではありません。ADの後者の信頼設定は、奇妙なことに、委任がPuTTYなどのWindowsクライアントから機能するためにのみ必要です。Linuxの「ssh -K」クライアントには必要ありません。]

Active Directoryドメインの一部ではない自己管理型（個人用）Windowsマシンでも、PuTTYを介してKerberos / GSSAPI認証（およびチケットの委任）を使用できますが、自分でチケットを取得する必要があります。残念ながら、Windows 7には（手動でチケットをリクエストするための）kinitプログラムと同等のものがインストールされていません。また、チケットがない場合でも、PuTTYはKerberosパスワードの入力を求めません。したがって、Windows用のMIT Kerberosをインストールする必要があります。パッケージには、通常のkinit / klist / kdestroyコマンドラインツールと、便利なGUIツール「MIT Kerberosチケットマネージャー」の両方が含まれています。これらを使用してチケットを取得すると、PuTTYはMicrosoft SSPIライブラリの代わりにMIT GSSAPIライブラリを自動的に使用し、すべて機能するはずです。「MIT Kerberosチケットマネージャー」が実行されている場合、PuTTYでチケットが必要になると、Kerberosパスワードの入力が自動的に求められるため、スタートアップフォルダーからリンクすることをお勧めします。

まず、PuTTYを実行しているWindowsボックスのklist出力が有効なTGTを示していることを再確認します。次に、PuTTYセッションの構成で、でGSSAPI認証の試行が有効になっていることを確認しConnection - SSH - Auth - GSSAPIます。最後に、で自動的にユーザー名でログインするように設定されていることを確認してくださいConnection - Data。ユーザー名を明示的に指定するか、[ システムユーザー名を使用する ]のラジオボタンを選択できます。

歴史的に、パスワードなしのSSHログインをKerberos経由で機能させるために必要なことはこれだけです。

問題は、Windows Kerberosセットアップにありました。私たちのActive Directoryはファンキーに設定されていると思いますが、私がWindows管理者ではないことは本当にわかりません。

しかし、Windows 7 CLIでksetupを使用して手動でKerberosを構成することで問題を修正しました。

リモートワークステーションを再起動した後、PCにログインできませんでした。これは、元の構成ではレルムドメインのTLD部分が常に存在しないため（domain \ user）、手動で構成した後、完全なレルムドメイン名（domain.TLD \ user）を反映するようにログインドメインを変更する必要があったためです。認証に時間がかかるようですが、Windows PCにログインできました。

変更前は、ksetupの出力にはデフォルトのレルムしか表示されず、小文字でした。

「nslookup -type = SRV _kerberos._tcp.domain.TLD」を使用して、レルムのすべてのkdcサーバーを取得しました。

フラグは設定していません。

マップされたユーザー名を設定しました "ksetup / mapuser user@domain.TLD user"

私が使用したリソース：https : //wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

誰かがWindows管理者にどのようにこれを修正できるかについて提案できる提案がある場合（それは壊れていますか？）私はそれを渡します。