サーバーに接続できません。リモートサーバーによって接続が閉じられました
ローカルサーバーからリモートサーバーをsshしようとしています。しかし、私がsshコマンドを実行するときはいつでも：
ssh [email protected]
エラーが発生します：
X.x.x.xによって接続が閉じられました
Ssh -v -v -v [email protected]の出力は次のとおりです。
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/mona/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/mona/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/mona/.ssh/id_rsa-cert type -1
debug1: identity file /home/mona/.ssh/id_dsa type -1
debug1: identity file /home/mona/.ssh/id_dsa-cert type -1
debug1: identity file /home/mona/.ssh/id_ecdsa type -1
debug1: identity file /home/mona/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for Host "151.236.220.15" from file "/home/mona/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
Connection closed by x.x.x.x
Id_rsa.pubのコンテンツをknown_hostsキーにロードしました。
Sshログインできません。
誰かがこれで私を助けることができますか？本当に感謝します。
ありがとうございました。
コメントのFredの指摘（そして実際にはreadingエラーメッセージ）に続いて、私は間違っていて、sshは接続していました。元の応答を下部に残し、さらに実行中のsshに接続できないという質問に答えます。
Sshdサーバーが接続を拒否し、OPが正しい場合、auth.logまたはsyslogに何もログインしていない場合に、sshの問題を診断する別の良い方法は、デバッグを有効にして別のポートで実行することです（私は選択しました） 44の任意のポート）。
/full/path/to/sshd -p 44 -d
その後、sshクライアントに接続して、問題のデバッグをさらに進めることができます。
ssh -p 44 [email protected]
ルート（フレッドが彼の回答で指摘したように）は、sshd_configのsshオプションPermitRootLoginオプションを介して制限される可能性のあるユーザーです。また、sshd_configで使用される認証方法の種類によって、ホストへのアクセス方法がさらに制限される可能性があります。
RSAAuthentication
PubkeyAuthentication
RhostsRSAAuthentication
HostbasedAuthentication
ChallengeResponseAuthentication
PasswordAuthentication
KerberosAuthentication
GSSAPIAuthentication
これらのオプションの詳細については、sshd_config（man 5 sshd_config）のマニュアルページを参照してください。 通常ほとんどのsshdにはRSAAuthentication、PubkeyAuthentication、場合によってはPasswordAuthenticationがあります。 RSAAuthenticationはProtocol 1に固有であり、ほとんどのホストはPubkeyAuthenticationを使用するProtocol 2を使用します。どちらもキーファイル（通常は/root/.ssh/authorized_keysにあります）を持つrootに依存していますが、この場所はAuthorizedKeysFileオプションで上書きできます。 sshdでPasswordAuthenticationが有効になっていないようです。
RSAおよびPubkey認証には、キーペアが必要です。生成したもので、クライアントマシンの/home/mona/.ssh/id_rsaと/home/mona/.ssh/id_rsa.pubにあります。これら2つのファイル（/home/mona/.ssh/id_rsa.pubに含まれるキー）のpublic半分は、上記のrootのauthorized_keyファイルに配置する必要があります。
元の回答、sshdプロセスへのリモート接続の失敗を参照
これは、TCPWrappersまたはファイアウォールが初期接続を閉じているように見えます。
auth.log内の/var/logまたはsyslogファイルを確認してください。これらは、どちらが接続をブロックしているかについての手がかりを提供する可能性があります。
TCPwrappersは通常、/etc/hosts.allowファイルを介して実装され、一部のUNIXでは追加または/etc/hosts.denyファイルのみ（つまり、hosts.allowファイルなし）で実装されます。
エントリは通常、次の形式です。
<service> : <access list> : <allow|deny>
OR
<service> : <access list>
使用されているtcpラッパーのタイプによって異なります。これらのファイルの形式は、通常、hosts_accessのマニュアルページman 5 hosts_accessで確認できます。リモートIPアクセスを許可するには、エントリを追加する必要がある場合があります。
sshd : my.ip.address.here : allow
Linuxカーネルを使用するほとんどのディストリビューションは、メインファイアウォールとしてiptablesを使用する傾向がありますが、ipchainsを使用するものもあります。 （私はFreeBSDがNetBSDから移植されたipfwを使用していることを知っています）。サービスプロバイダーは、ファイアウォール、またはこれらの要求をブロックしているサービスの前にファイアウォールを備えたルーターを持っている場合もあります。ホストが使用するファイアウォールについては、調査が必要です。
iptablesファイアウォールルールは、iptables -nvLコマンド（rootとして、またはSudoを介して実行する必要があります）を介して一覧表示できます。 INPUTチェーンは、ホストの着信接続を許可/禁止するために使用されるルールセットです。 SSH接続のインバウンドを許可するルールを追加する必要がある場合があります。
iptables -I INPUT -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from all hosts"
特定のIPからの接続のみを許可するようにすることができます。
iptables -I INPUT -s 10.10.10.10 -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH connections from the 10.10.10.10 Host"
サービスプロバイダーがポート22をブロックしている場合は、2222ファイル（通常はsshd_configにあります）のPortオプションを使用して、サービスを別のポート（ポート/etc/sshが非常に人気があります）に配置する必要があります。
私にも起こりました。問題を診断して修正した方法は次のとおりです。
別のポートでsshdを実行すると（「servicessh」ではなく/ usr/sbinから直接）、いくつかの警告が表示されました。/etc/ssh内のすべてのファイルのアクセス許可をg + wに変更したので、ルートグループ内の別のユーザーとしてそれらを編集できました。悪い動き。 sshdはこれに非常にこだわり、root以外の誰にとっても読み取り専用ではないrsaキーファイルを無視します。権限の変更を元に戻し、再び接続できました。
これは、リモートサーバーのSSHホストキーに問題がある可能性があります。 この質問 および this Appleサポートスレッド （心配しないでください-これはApple固有の問題ではありません）を参照してください。
念のために言っておきますが、sshd_configファイルに#PermitRootLogin yesがある場合とない場合のどちらかで#がありますか？ rootとしてsshするためにそれが必要になるでしょう。そして実際には、rootがサーバーにsshすることを許可しないことをお勧めします（まだ設定されていない場合は、行をPermitRootLogin noに変更します）。全員に通常のアカウントとしてログインさせ、権限が必要な場合はsu rootにします。これにより、誰がログインしてrootになったのかを確認でき、ログインしていないユーザーがrootパスワードを推測するのを防ぐことができます。
サーバーを認証するために、サーバーマシンの公開鍵はクライアントマシンのknown_hostsにある必要があります。これにより、目的のサーバーになりすました不正なサーバーに接続していないことがわかります。初めてサーバーにSSH接続するときに、known_hostsに入るキーを承認するように求められます。その後、サーバー認証が自動的に行われます。
アカウントの公開鍵（.pubファイルから）をサーバーのauthorized_keysに配置します。次に、サーバーに接続すると、クライアントは秘密鍵を使用してメッセージをエンコードし、サーバーに送信します。サーバーは、authorized_keyファイルの対応する公開鍵を使用してメッセージを復号化します。サーバーがそうすることができる場合、それはクライアントが秘密鍵を持っていることを証明し、したがってログインを許可されます。
デバッグデータを読んだところ、サーバーがアカウントの公開鍵を見つけることができなかったことがわかりました。 ssh-copy-idを使用して、公開鍵をサーバーに配置します。