web-dev-qa-db-ja.com

奇妙なSSHの問題-単一のホストで名前によるログインが許可されない

キーの再生成から、単一のクライアントではアクセスできないように見えるSSHホストのドメイン（Centrify）の「離脱」と再参加まで、すべてを行ったので、誰でもこれを説明できますか。 1つを除いて、他のすべてのクライアントはこのホストにアクセスできます。ただし、奇妙なことに、IPアドレスを使用すると、クライアントからホストにSSHで接続できます。

$ ssh ddecker@Host
Connection closed by 10.0.0.250
$ ssh [email protected]
Password:
[ddecker@Host ~]$

これについて私が持っているのは、ホストの/ var/log/messages内だけです。ホスト名を使用しようとすると、次のようになります。

fatal: accept_ctx died [preauth]

/etc/krb5.keytabを削除しようとしましたが、Centrifyが起動しません。だから私はそれを元に戻しました。クライアントはIP経由でしか接続できないため、他のすべてのクライアントが名前で接続できる理由について、何が起こっているのか本当にわかりません。

更新＃1：

ssh -v ddecker@Hostの出力は次のとおりです。

debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to Host [10.0.0.250] port 22.
debug1: Connection established.
debug1: identity file /home/ddecker/.ssh/id_rsa type 1
debug1: identity file /home/ddecker/.ssh/id_rsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_dsa type -1
debug1: identity file /home/ddecker/.ssh/id_dsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==
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: Doing group exchange

debug1: Calling gss_init_sec_context
debug1: Delegating credentials
Connection closed by 10.0.0.250
networkingdomain-name-systemsshpublic-key
2
drewrockshard

AD/KerberosCentrifyのデバッグは常に煩わしいものです。

/usr/share/centrifydc/bin/addebug onを使用してサーバーでCentrifyデバッグを有効にすることをお勧めします。これにより非常に大きなログファイルが作成される可能性があり、有効にしたままにしておくとボリュームがいっぱいになる可能性があることに注意してください。

SPNとKVNOを確認してください

サーバーのローカルキータブから原則とKVNOのリストを取得します。これには、KerberosクライアントユーティリティRPMパッケージがLinuxサーバーにインストールされている必要がある場合があります（yum install krb5-workstation）。

klist -kte

ADによって決定されたKerberosKVNOと比較してください。別のCentrifyenebales Linuxシステムから:(アクティブなKerberosログインセッションを「kinit」で開始する必要があります。有効なkerberosチケット付与チケットがあるかどうかをklistで確認してください））別のホストから実行するのが最善です。 .SSHはhostsプリンシパルを使用します。

kvno Host/hostname
kvno Host/hostname.domain.name

上記の2つのコマンドが異なるKVNOを返し、同じ原理のklistで見つかった場合、通常、UNIXサーバー上のローカルkeytabファイルをリセットする必要があります。 ADのKDCと同期していない場合のローカルキータブのリセットは、関係するホストのコマンドラインから実行され、root権限が必要です。

adkeytab -r -u <username>

または、上記の特権ADユーザーの代わりにローカルコンピューターアカウントの資格情報を使用します

adkeytab -r -m
1
HBruijn

この症状は、1人のクライアントでKerberosが壊れていることを示しています。 IP経由でsshを実行する場合、通常、Kerberosは関与しません。

1つのクライアントでKerberosが破損する最も一般的な原因は、そのクライアントで時刻が同期していないことです。 Kerberosでは、関係するすべてのホストのシステムクロックがほぼ同期している必要があります。

/bin/date

クライアントとサーバーの両方で、互いに数秒以内にある必要があります。

1
Fred the Magic Wonder Dog

それで、彼らは私にいくつかの推薦をしてくれたすべてのおかげで。しかし、私は結局問題を見つけました。基本的にSSHキーを各サーバーにコピーする単純なexpectスクリプトを作成しました。これは、単純なファイルによってサーバーが何であるかを認識します。

したがって、エラーは何も見られませんでしたが、この1つのホストでは、SSHキーと競合する「known_hosts」エントリがあり、基本的に接続が切断されるだけでした。私はknown_hostsファイルを削除し（私が本当にしなければならなかったのは、known_hosts内の1つのアイテムを削除することだけでした）、接続を再試行しました-そしてアクセスが許可されました。

簡単な修正ですが、エラーは私を助けたり、明らかな修正を示したりしませんでした。

ありがとう！

0
drewrockshard