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).

多分。

• 標準ログインプロセスの一部として、または手動で（kinitMIT Kerberos for Windows）クライアントシステムでプリンシパルのチケットを取得できますか？
• サーバーにKerberosプリンシパルがありますか、それを提供できますか？形式であるべきhost/server.example.com@EXAMPLE.COMです。
• されたGSSAPI認証は、クライアント上で有効？
• クライアントは、DNS TXTリソースレコードまたはローカルマッピングによって、サーバーが属するレルムを知っていますか？

上記すべてに「はい」と言ったら、おめでとうございます、を使用できますGSSAPIAuthentication。

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

テスト手順：（
仮定：domain = example.com; realm = EXAMPLE.COM）

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

4ステップの方法は正しいです（DNSにはさらに洗練され、すべてのActive Directoryに存在するKerberos SRVレコードもあります）。私はこれを常に使用しており、主にセキュリティおよび制御関連の理由で、上記のpubkeyメソッドを提唱しています。

ただし、これは対話型ログインのみを提供しますが、ワークステーションでチケットを取得すると準対話型になります。Kerberosチケットは、SSHエージェントによく似ています。一度それを手に入れると、新しい接続は即座にパスワードが不要になります。時間制限はありますが。

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

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

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