web-dev-qa-db-ja.com

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

私の会社では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).
sshauthenticationkerberos
15
olibre

多分。

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

上記のallに対して「はい」と言った場合、おめでとうございます。GSSAPIAuthenticationを使用できます。

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

テスト手順：
（仮定：ドメイン= example.com;レルム= EXAMPLE.COM）

  1. kinit [email protected]
    • 理想的には、適切なpam_krb5にpam_sssまたはauth_provider = krb5（pam stackを含む）を含めることにより、標準のログインプロセスで処理されます。
  2. kvno Host/[email protected]
    • これはデバッグ手順です。 sshは、有効なキャッシュがあり、gssapi-with-micまたはgssapi-keyexをサポートするsshdと通信している場合に、これを自動的に行います。
  3. Dig _kerberos.example.com txtは"EXAMPLE.COM" を返す必要があります
    • または、マッピングを[domain_realm]の/etc/krb5.confセクションに.example.com = EXAMPLE.COMとして保存することもできますが、dnsメソッドの方がはるかに優れています。
  4. ssh -o GSSAPIAuthentication=yes [email protected]
    • サーバー上のプリンシパルのユーザー名以外のユーザー名にログインするには、ここでは触れない詳細をマッピングする必要があります。
19
84104

4ステップの方法は正しいです（DNSには、よりエレガントですべてのActive Directoryに存在するKerberos SRVレコードもあります）。私はいつもこれを使用しており、主にセキュリティと制御に関連する理由から、上記のpubkeyメソッドを推奨しています。

とは言っても、ワークステーションでチケットを取得すると、これはインタラクティブなログインのみを提供します。 KerberosチケットはSSHエージェントのように機能します。一度それを取得すると、新しい接続は瞬時に行われ、パスワードは不要です。時間制限はありますが。

インタラクティブなバッチログインを取得するには、SSHキーの秘密の半分のように、Kerberosアカウントのパスワードを本質的に含むキータブファイルを取得する必要があります。セキュリティ上の注意事項が適用されます。特にキータブは暗号化されておらず、パスワードで保護されていないためです。

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

キータブは、UNIXではktutil、WindowsではKTPASS.EXE（後者はAD Kerberosサービスから）を使用して作成できます。 ktutilはHeimdalとMITの2つのフレーバーで存在し、構文が異なることに注意してください。関連するシステムのマンページを読むと役立ちます。

5
mansaxel