RHEL6 上の sssd を使用して、Active Directory Kerberos で認証するようにいくつかの Linux サーバーを構成しました。また、パスワードなしのログインを期待して、GSSAPI 認証も有効にしました。
しかし、Putty (0.63) をパスワードなしで認証することはできないようです。
GSSAPI は、.ssh/config 設定を使用して GSSAPI を有効にし、AD 認証用に構成された Linux システム (openSSH クライアント) 間で機能します。
また、同じ .ssh/config 設定を使用し、kinit コマンドを実行してチケットを取得することで、Cygwin (openSSH クライアント) からも機能します。
また、Samba はすべての Linux システムで共有され、ホーム ディレクトリも含め、パスワードを必要とせずに Windows エクスプローラーから操作できます (GSSAPI がここで機能するかどうかはわかりません)。
この問題を解決するには、どのようなことを試せばいいでしょうか? ほとんどのユーザーは Putty を使用しています。また、私は Windows 管理者ではないので、ドメイン コントローラーで何もできません。私のアカウントには、AD ドメインにサーバーを追加する権限しかありません。
putty 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.
答え1
Active Directory ドメインの一部である Windows マシンでは、ユーザーは Windows にログインするときに Kerberos チケット保証チケットを受け取り、PuTTY 構成の [接続] | [SSH] | [認証] | [GSSAPI] で GSSAPI 認証が有効になっている場合、PuTTY はそれを認証に使用できます (また、Pageant 経由の公開キーなど、GSSAPI の前に試行されるその他の認証方法は、[接続] | [SSH] | [認証] で設定されていないか、無効になっています)。
[チケット委任も必要な場合（例えば、ログイン後にサーバーにKerberosファイルシステムをマウントする場合）、PuTTYでGSSAPI委任も有効になっていることを確認してください。そしてログインしたサーバーは、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 Ticket Manager」の両方が含まれています。これらを使用してチケットを取得すると、PuTTY は Microsoft SSPI ライブラリの代わりに MIT GSSAPI ライブラリを自動的に使用するようになり、すべてが機能するようになります。「MIT Kerberos Ticket Manager」が実行中の場合、PuTTY がチケットを必要とするときに Kerberos パスワードの入力が自動的に求められるため、スタートアップ フォルダからリンクすることをお勧めします。
アップデート：Windows 10バージョン21H1およびWindows Server 2022では、Windows 用 OpenSSH(バージョン 8.1 以降) Windows に組み込まれているクライアントとサーバーは、GSSAPI 認証と委任もサポートするようになりました (つまり、ssh -K)。そのため、必要なものがそれだけであれば、2021 年以降、PuTTY と MIT Kerberos をインストールする必要はなくなりました。
答え2
まず、PuTTYを実行しているWindowsボックスのklist出力に有効なTGTが表示されていることを確認します。次に、PuTTYセッションの設定で、GSSAPI認証を試みるが有効になっていることConnection - SSH - Auth - GSSAPIを確認します。最後に、 でユーザー名で自動的にログインするように設定されていることを確認しますConnection - Data。ユーザー名を明示的に指定するか、ラジオボタンを選択してシステムユーザー名を使用する。
これまでのところ、Kerberos 経由でパスワードなしの SSH ログインを機能させるために必要なことはこれだけです。
答え3
問題は 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[メールアドレス]ユーザー "
使用したリソース: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+ログイン+外部+Kerberos+KDC の使用
https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html
Windows 管理者にこの問題を修正する方法 (壊れているのでしょうか?) についてアドバイスできる方がいらっしゃいましたら、お伝えします。