sshがパスワードなしでハングするプロンプト-rootまたは他のアカウントで機能します
Sshキーベースのログインが正常に機能していました。次に、コンピュータのホスト名を変更すると、キーベースのログインが機能しなくなりました。理にかなっているようです。キーはおそらく私の古いホスト名に依存していました。したがって、すべてのキーと〜/ .ssh /内のすべてのファイルを削除し、それらを再生成しました（そして接続するサーバーのauthorized_keysを変更しました）
さて、sshを実行しようとすると、パスワードプロンプトなしでハングアップします。どこにsshを実行しようとしても、キーベースのログインが設定されていないサーバーでも同様です。 .ssh/configには何もありません。
さらに、ルートに「su-」すると、sshは完全に機能します。全く問題ありません。これは私のユーザーアカウントでのみ発生します。
以下はsshからのデバッグ情報です
ssh -vv [email protected] OpenSSH_5.2p1、OpenSSL 0.9.8k 25 Mar 2009 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：mode 1 debug1：SSH2_MSG_NEWKEYS sent debug1：expecting SSH2_MSG_NEWKEYS debug2：set_newkeys：mode 0 debug1：SSH2_MSG_NEWKEY .____。] debug1：SSH2_MSG_SERVICE_REQUEST sent debug2：service_accept：ssh-userauth debug1：SSH2_MSG_SERVICE_ACCEPT received
そして、それはちょうどここにぶら下がっています.....
これがハングする終わり近くのdtruss（straceのようなOSXの場合）の出力です：Sudo dtruss ssh -vv [email protected]
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が何かを読み込もうとしているようで、これにかかっています。誰か提案やアイデアがあれば、私はとても感謝しています！
私にとって、Snow Leopardにアップグレードすることで問題は解決しました。つまり、OSXのバグに関係していると思います。
Sshクライアントが自分のアカウントではハングするが他のアカウント（root）ではハングしない理由は、おそらくssh-agentに問題があるためです。 ssh-agentが実行されていないか、その構成が何らかの形で間違っています。
それを確認するために、以下を試すことができます：
unset SSH_AUTH_SOCK
ssh [email protected]
パスフレーズをssh_keyに入力するように求められた場合は、ssh-agentに問題があることを意味します。
この関連質問 に関する私の投稿も参照してください。
リバースDNSに興味がありますか？
基本的に、クライアントはサーバーで逆DNSを実行しているか、その逆です。
私はテストを提案します：
/ etc/ssh/sshd_configを編集し、「UseDNS」が「no」に設定されていることを確認して、サーバーのDNSルックアップを無効にします。
「service ssh reload」（またはsshデーモンが設定を再読み込みする原因となるもの）を実行してから、再試行してください。
ちなみに、久々に久しぶりにプロンプトを出すのは思いもよらないですね。
チェックする可能性のあるもう1つのことは、サーバー上の/ etc/hostsの内容を調べて、何も問題がないことを確認することです。
クライアント（およびサーバー）に空きディスク領域がありますか？
df -h
同様の問題がありました。
ssh domain.ip:user.name
このようにログイン名を強制することで問題を回避できるようです。
ssh -v domain.ip -l user.name
〜/ .sshディレクトリとその中のファイルの権限を確認します。デフォルトのumaskは許容度が高すぎる可能性があります。また、ファイルを再作成したときに、誤ってそれらに誤った許可を与えた可能性があります。私はこれによって数回私をやけどしました。私がこれまでに使ったsshクライアント（またはサーバー）のどれも、これについて有用なエラーメッセージを出しませんでした...
サーバーのログを確認してください。通常は/var/log/auth.log（Debian/Ubuntu）または/var/log/secure（RedHat/CentOS）。接続に関する問題は通常、そこに記録されます。
/ etc/hostnameが改行で終了していることを確認してください。
保存されたキーが原因である場合は、known_hostsファイルの〜/ .sshディレクトリからそのキーを削除できるはずです。エントリを見つけて削除すると、もう一度プロンプトが表示されます。
一方、ホストが記録されたものと一致しない場合、警告が表示されます。
OS Xでホスト名検索が失敗したように動作する問題がありました。接続が長い間待機していてタイムアウトになるか、プロンプトが表示されたときに接続が切断される前にパスワードを入力するのに約10秒かかります。問題のホストをホストファイルに追加するよう提案されているにもかかわらず、私はそれを追跡できませんでした。それは単なる「OS XのDNSルックアップの不具合」だったと思いますが、それは許容されると予想されていました...誰か他の人がこの問題を抱えてそれを解決した場合、それについて知りたいと思います。