SSH：ピアによる接続のリセット
別のネットワーク上にSolaris 10サーバーがあります。 pingしてtelnetで接続できますが、sshが接続しません。 PuTTYログには何も関心がありません（両方ともssh v2と交渉します）。
"Event Log: Network error: Software caused connection abort".
sshは確実に実行されています。
svcs -a | grep ssh
online 12:12:04 svc:/network/ssh:default
サーバーの/ var/adm/messages（匿名）からの抜粋です。
Jun 8 19:51:05 ******* sshd[26391]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer
ただし、ボックスにtelnetで接続すると、ローカルでsshにログインできます。そのネットワーク上の他の（Solaris以外の）マシンにsshすることもできるので、ネットワークの問題だとは思わない（ただし、数百マイル離れているので、確信が持てない）。
サーバーのファイアウォールが無効になっているため、問題ありません
root@******** # svcs -a | grep -i ipf
disabled Apr_27 svc:/network/ipfilter:default
私がチェックを開始する必要があるアイデアはありますか？
pdate：以下のフィードバックに基づいて、sshdをデバッグモードで実行しました。クライアントの出力は次のとおりです。
$ ssh -vvv root@machine -p 32222
OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008
debug2: ssh_connect: needpriv 0
debug1: Connecting to machine [X.X.X.X] port 32222.
debug1: Connection established.
debug1: identity file /home/lawrencj/.ssh/identity type -1
debug1: identity file /home/lawrencj/.ssh/id_rsa type -1
debug1: identity file /home/lawrencj/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
そして、ここにサーバー出力があります：
root@machine # /usr/lib/ssh/sshd -d -p 32222
debug1: sshd version Sun_SSH_1.1
debug1: read PEM private key done: type RSA
debug1: private Host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private Host key: #1 type 2 DSA
debug1: Bind to port 32222 on ::.
Server listening on :: port 32222.
debug1: Bind to port 32222 on 0.0.0.0.
Server listening on 0.0.0.0 port 32222.
debug1: Server will not fork when running in debugging mode.
Connection from 1.2.3.4 port 2652
debug1: Client protocol version 2.0; client software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x4584c(0x0)
この行は有望な候補のようです：
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
鍵ベースの認証を使用している場合は、サーバー上の.ssh/authorized_keysファイルを確認してください。同じ問題があり、アクセスを設定した人が改行を入れてキーを貼り付けていました。改行を削除すると問題が解決しましたが、authorized_keysファイルを邪魔にならないように移動するか、パスワード認証を選択することでテストできますまず、同じ問題が発生するかどうかを確認します。
ssh -o PreferredAuthentications=password username@hostname
GSSAPIを完全に無効にしてみます。
GSSAPIAuthentication no
Sshd_confの許可ユーザーリストに含まれていますか？
これは興味深いです、私は同じ問題を抱えています。私だけがローカルネットワークからsshできますが、vpnを使用しているときはできません。
5月11日18:03:10 servername sshd [14733]：[ID 800047 auth.crit]致命的：ソケットからの読み取りに失敗しました：接続がピアによってリセットされました
私はパスワードの入力を求められることはありません。セッションはすぐに終了します。
sshdを-dフラグを使用して実行し、元のsshdを実行したままにする場合は、-pフラグを使用して別のポートを指定することにより、さらに有用なデバッグ情報を取得できる場合があります。 ssh -vクライアントでそれを実行します。
更新：問題は認証ではなくネットワークに関連しているようです。会話の両側で接続がリセットされたことがわかります。問題の原因となっている中間ネットワークノード（ファイアウォールなど）があるかどうかを関連ネットワークチームに確認することができます。
これは、TCPラッパー（hosts.deny）によって引き起こされる時間の99％です。おそらくそこでIPアドレスを許可する必要があります。
/etc/hosts.deny
これがlocalhostから機能する理由は、おそらく127.0.0.1がそこで（または/etc/hosts.allowを介して）許可されているためです。
Sshdは接続を処理するためにforkします（デバッグ実行時でも）。システムの認証メカニズムとやり取りしようとするや否や、子供は静かに死んでいくように思えます。これは、通常、UID、GIDをチェックし、PAMを実行する時期です。サーバーはLDAPまたはNIS +を使用していますか？
適切に機能しているサーバーでデバッグを実行し、次に何が起こるかを確認することをお勧めします（vimdiffまたはdiffを使用）。
最近、非常によく似た問題が発生しました。グループのメンバーが多すぎる（すべてのメンバーの長さが約500〜600文字）場合です。それはLinux上でしたが。
デバッグのためにサーバーを実行しているときは、詳細情報を取得するために-ddd（トリプルデバッグ）を指定してください。
SSHv2がネゴシエートされていると言うので、私はキー交換の問題に何か関係があるのではないかと疑っていました。
まだそれに関する良い説明は見つかりませんでした。 これは1つのPuTTY参照があります ですが。
サーバーでパケットキャプチャを試行して、SSH通信が停止する場所を確認する必要があります。
「ssh -v "クライアントに表示されるエラーを確認します。
宛先ホストは別のネットワークにあると言います。そして、「サーバーのファイアウォールが無効になっています」。
ネットワークと宛先ネットワークの間にファイアウォールまたはあらゆる種類のパケットフィルタリングデバイスがありますか。
2つのネットワークの間にあるものを確認するには、tracerouteを実行する価値があります。
また、送信中にパケットが失われていないことを確認してください。 pingを使用した簡単なテストは、ネットワークの問題があるかどうかを判断するのに役立ちます。
私は同じ症状で同様の問題を解決しました：切断後：
debug1: SSH2_MSG_KEXINIT sent.
2つのポート22と「別の非公開ポート」でsshサーバーを実行しています。ポート22を使用して接続できましたが、ホストキー交換の前に上記の突然の切断で他のポートを使用できませんでした。
ポート22のsshdがrootとして実行されていることがわかりましたが、sshd他のポートでは、ユーザーubuntuとして実行されていました。明らかに、ubuntuユーザーは/ var/log/auth.logに示されているように、プライベートホストキーを読み取ることができません。
error: Could not load Host key: /etc/ssh/ssh_Host_rsa_key
error: Could not load Host key: /etc/ssh/ssh_Host_dsa_key
fatal: No supported key exchange algorithms
コマンド 'Sudo netstat -nap | grep ssh 'は、ポート22と他のポート（編集済み）に対して2つの異なるプロセスを返しました。
$ Sudo netstat -nap | grep ssh
tcp 0 0 0.0.0.0:other port 0.0.0.0:* LISTEN 17620/sshd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 31160/sshd
tcp6 0 0 :::other port :::* LISTEN 17620/sshd
tcp6 0 0 :::22 :::* LISTEN 31160/sshd
ポート22のsshサーバーがプロセス＃31160を使用するのに対し、他のポートはポート＃17620を使用することを示します。
そして 'ps -eaf | grep ssh 'は、1つのプロセスがrootとして実行されている一方で、もう1つのプロセスがubuntuとして実行されていることを示しました（編集）。
$ ps -eaf | grep ssh
ubuntu 17620 1 0 Apr25 ? 00:00:00 /usr/sbin/sshd
root 31160 1 0 08:35 ? 00:00:00 /usr/sbin/sshd
この問題を解決するために、ubuntuとして実行されているプロセスを強制終了し（kill 17620）、コマンド 'Sudo/etc /を使用してsshサーバーを再起動する必要がありましたinit.d/ssh restart '。
これがどのように発生したかはわかりませんが、問題を再現しようとした後、root以外でsshdを再起動しようとした可能性があります。動作しますが、新しいポートはubuntuユーザーによってホストされています。
$ /etc/init.d/ssh restart
Could not load Host key: /etc/ssh/ssh_Host_rsa_key
Could not load Host key: /etc/ssh/ssh_Host_dsa_key
* Restarting OpenBSD Secure Shell server sshd
start-stop-daemon: warning: failed to kill 31884: Operation not permitted
Could not load Host key: /etc/ssh/ssh_Host_rsa_key
Could not load Host key: /etc/ssh/ssh_Host_dsa_key
これが私が行ったことである場合、これらのエラーメッセージを無視したために噛まれました。それでも、ubuntuを実行しているsshdを強制終了しないとサーバーを正しく再起動できないため、これはバグと見なすことができます。
不思議に思う人のために、ポート22ではなく別のポートを使用して、すべてのサーバーのポート22でのほとんどの接続試行を防止し、ファイアウォールを使用してポート22をブロックします。これは簡単ですが機能し、任意のIPアドレスから接続できます。