☰

SSH認証にgssapi-keyexまたはgssapi-with-micを使用する（公開鍵は許可されていません）

tag-icon • tag-icon ssh authentication kerberos
SSH認証にgssapi-keyexまたはgssapi-with-micを使用する（公開鍵は許可されていません）

当社はSSH公開鍵認証を無効にしているため、毎回パスワードを手動で入力する必要があります（変更する予定はありません/etc/ssh/sshd_config）。

ただし、認証gssapi-keyexはgssapi-with-mic有効になります（ssh以下のデバッグ出力を参照）。

この場合、自動ログインを使用する方法は？
活用gssapi-keyexおよび/またはgssapi-with-mic認証できますか？

> ssh -v -o PreferredAuthentications=publickey hostxx.domainxx
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to hostxx.domainxx [11.22.33.44] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type -1
debug1: identity file /home/me/.ssh/id_rsa type -1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostxx.domainxx' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (gssapi-keyex,gssapi-with-mic,password).

答え1

おそらく。

  • 標準ログインプロセスを介してまたは手動で（kinitWindows用MIT Kerberos）クライアントシステムからプリンシパルのチケットを取得できますか？
  • サーバーにKerberosプリンシパルがありますか？それともこれを提供できますか？次のようにする必要があります。host/[email protected]
  • GSSAPIクライアントで認証が有効になっていますか？
  • クライアントは、DNS TXTリソースレコードまたはローカルマッピングを介してサーバーがどのゾーンに属しているかを知っていますか？

「はい」と言うとみんな以上、おめでとうございます。お使いいただけますGSSAPIAuthentication。

  • 設定によっては、資格情報の委任を有効にする必要があります。

テストステップ：（
前提：ドメイン= example.com、ゾーン=例.COM）

  1. kinit [email protected]
    • pam_krb5理想的には、これは適切なpam_sss場合は標準ログインプロセスを介して行われます。auth_provider = krb5pam stack
  2. kvno host/[email protected]
    • デバッグ段階です。有効なキャッシュがある場合、またはサポートされているオブジェクトと通信している場合、これsshは自動的に行われます。sshdgssapi-with-micgssapi-keyex
  3. dig _kerberos.example.com txt返す必要があります"EXAMPLE.COM"
    • あるいは、マッピングを[domain_realm]asの一部に保存することもできますが、このアプローチはスケーラビリティが優れています。/etc/krb5.conf.example.com = EXAMPLE.COMdns
  4. ssh -o GSSAPIAuthentication=yes [email protected]
    • サーバーからプリンシパル以外のユーザー名でログインするには、それをマップする場所を知る必要があります。ここでは詳しく説明しません。

答え2

4段階のアプローチは正確です（DNSにはよりエレガントなKerberos SRVレコードがあり、すべてのActive Directoryに存在します）。私はいつもこれを使用しており、主にセキュリティと制御に関する理由で上記の公開鍵アプローチを使用することを常に支持してきました。

つまり、これは対話型ログインのみを提供しますが、ワークステーションにチケットがある場合は準対話型になる可能性があります。 KerberosチケットはSSHプロキシと非常によく似ており、新しい接続はすぐに行われ、タイムアウトがありますが、パスワードは必要ありません。

インタラクティブな一括ログインを取得するには、SSHキーのプライベート部分と同様に、Kerberosアカウントのパスワードをデフォルトで含むkeytabファイルを取得する必要があります。特に、キータブは暗号化またはパスワードで保護されていないため、対応するセキュリティ対策が適用されます。

私はユーザーに個人アカウントのキータブを提供することを非常に消極的にしていますが、特にリモートシステムに資格情報を委任することが重要な場合は、最小限の権限でサービスアカウントを積極的に使用してさまざまなバッチ操作を実行し、pubkeyがこれを達成できますあります。

キータブは、Unixではktutilを使用し、WindowsではKTPASS.EXEを使用して作成できます（後者はAD Kerberosサービスによって使用されます）。 ktutilはHeimdalとMITの2つの形式で存在し、その構文が異なります。関連システムのマンページを読むことが役に立つかもしれません。

関連情報