パスワードプロンプトなしでsshがハングします— rootまたは他のアカウントで動作します

sshキーベースのログインが正常に機能していました。その後、コンピューターのホスト名を変更すると、キーベースのログインが機能しなくなりました。理にかなっているようだ。キーはおそらく私の古いホスト名に依存していました。そのため、すべてのキーと〜/ .ssh /内のすべてのファイルを削除し、それらを再生成しました（そして、接続するサーバーのauthorized_keysを変更しました）

今、私がsshをしようとするたびに、パスワードプロンプトなしでハングします。どこにsshしようとしても、キーベースのログインが設定されていないサーバーでもです。.ssh / configには何もありません。

さらに、ルートに「su-」すると、sshは完全に動作します。問題ありません。これはユーザーアカウントでのみ発生します。

以下はsshからのデバッグ情報です

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1、OpenSSL 0.9.8k 2009年3月25日
debug1：構成データの読み取り/Users/myname/.ssh/config
debug1：設定データ/ usr / etc / ssh_configの読み取り
......
debug1：ホスト「myremoteserver.com」は既知であり、RSAホストキーと一致します。
debug1：/Users/myname/.ssh/known_hosts:1にキーが見つかりました
debug2：ビットセット：512/1024
debug1：ssh_rsa_verify：署名が正しい
debug2：kex_derive_keys
debug2：set_newkeys：モード1
debug1：SSH2_MSG_NEWKEYSが送信されました
debug1：SSH2_MSG_NEWKEYSが必要です
debug2：set_newkeys：モード0
debug1：SSH2_MSG_NEWKEYSを受信しました
debug1：SSH2_MSG_SERVICE_REQUESTが送信されました
debug2：service_accept：ssh-userauth
debug1：SSH2_MSG_SERVICE_ACCEPTを受信しました

そして、それはちょうどここにハングします.....

次に、ハングする最後の近くのdtruss（straceに似ていますがOSX用）の出力を示します。sudo dtruss ssh -vv mylogin@myremoteserver.com

select（0x4、0x508200、0x0、0x0、0x0）= 1 0
read（0x3、 "$ \ 222 \ 351 {L \ 363 \ 261 \ 25063sN \ 216 \ 300 @ q7 \ 203 \ 276b \ 257 \ 354 \ 337 \ 356 \ 260！{\ 342 \ 017 \ 271 = \ 222、 \ 245 \ 347t \ 006 \ 225 \ 257 \ 333; \ 204 \ 020] \ 242 \ 005z＃\ 0 "、0x2000）= 48 0
write（0x2、 "debug2：service_accept：ssh-userauth \ r \ n \ 0"、0x26）= 38 0
connect（0x4、0xBFFFEEA2、0x6A）= 0 0
write（0x4、 "\ 0"、0x4）= 4 0
write（0x4、 "\ v5 \ 004 \ 0"、0x1）= 1 0
read（0x4、 "\ 0"、0x4）= -1 Err＃4

roが何かを読み込もうとしているようで、これに固執しています。誰かが提案やアイデアを持っているなら、私は非常に感謝します！

sshクライアントがアカウントでハングし、他のアカウント（root）ではハングしない理由は、おそらくssh-agentに何か問題があるためです。ssh-agentが実行されていないか、その構成が何らかの形で間違っていることが原因です。

それを確認するには、次を試してください。

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

パスフレーズをssh_keyに入力するように求められた場合、ssh-agentに問題があることを意味します。

この関連する質問に関する私の投稿も参照してください。

リバースDNSに興味がありますか？

基本的に、クライアントはサーバー上で逆DNSを実行します。逆も同様です。

私はテストを提案します：

/ etc / ssh / sshd_configを編集し、「UseDNS」が「no」に設定されていることを確認して、サーバー上のDNSルックアップを無効にします。

「service ssh reload」（またはsshデーモンが構成を再読み取りする原因となるもの）を実行してから、再試行してください。

偶然にも、長い時間を経てようやくプロンプトを表示することはありませんか？

確認できるもう1つのことは、サーバー上の/ etc / hostsの内容を調べて、そこに問題がないことを確認することです。

〜/ .sshディレクトリーおよびその中のファイルの許可を確認してください。デフォルトのumaskは許容範囲が広すぎる可能性があり、ファイルを再作成したときに、誤って誤ったアクセス権を与えた可能性があります。私はこれに何度か火傷を負いました。私がこれまでに使用したsshクライアント（またはサーバー）のどれも、これに関する有用なエラーメッセージを与えませんでした...

クライアント（およびサーバー）に空きディスク領域がありますか？

df -h

同様の問題がありました。

ssh domain.ip:user.name

このようなログイン名を強制することで問題を回避できるようです。

ssh -v domain.ip -l user.name

私にとっては、Snow Leopardにアップグレードすることで問題は解決しました。そのため、OSXのバグに関連していたと思います。

保存されたキーが原因である場合、known_hostsファイルの〜/ .sshディレクトリから削除できるはずです。エントリを見つけて削除すると、再度プロンプトが表示されます。

一方、ホストが記録されているものと一致しない場合、警告を発する必要があります。

OS Xでホスト名検索が失敗するように動作する問題がありました。接続の待機時間が長すぎるか、プロンプトが表示されたときに接続が切断される前にパスワードを入力するのに約10秒かかったため、接続がタイムアウトしました。問題のホストをホストファイルに追加することを提案しているにもかかわらず、私は追跡できませんでした。これは単なる「OS XのDNSルックアップの不具合」であり、他の誰かがこの問題を抱えて解決した場合、私はそれを知りたいと思っています。

サーバーのログを確認してください。通常は/var/log/auth.log（Debian / Ubuntu）または/var/log/secure（RedHat / CentOS）にあります。通常、接続に関する問題はすべてログに記録されます。

/ etc / hostnameが改行で終了していることを確認してください。