ssh接続に失敗し、経験を間違えた

この記事は以下のとおりです.http://www.cnblogs.com/starof/p/4709805.html
一、シーンの説明
sshはサーバに接続し,接続に失敗したが,対応するサーバのipはpingに通じる.
シーン:

[root@yl-web ~]# ssh [email protected]
ssh_exchange_identification: read: Connection reset by peer
[root@yl-web ~]# ping 10.1.101.35
PING 10.1.101.35 (10.1.101.35) 56(84) bytes of data.
64 bytes from 10.1.101.35: icmp_seq=1 ttl=64 time=0.587 ms
64 bytes from 10.1.101.35: icmp_seq=2 ttl=64 time=0.722 ms
64 bytes from 10.1.101.35: icmp_seq=3 ttl=64 time=0.475 ms

pingはネットワーク層のプロトコルであり、表面ネットワークは3層で通じているだけである.
sshはアプリケーション層プロトコルですが、具体的にはホストから原因を探します.
二、列を間違える
1、ssh -v
ssh-vで問題のあるサーバに接続すると、比較的詳細なデバッグ情報が画面に出力され、どのステップで問題が発生したかを判断するのに役立ちます.
主にクライアントかサーバかの問題です.クライアントの問題であれば、logに書き込みがあるはずです.何か役に立つ情報がない場合は、サーバ側に問題がある可能性があります.

[root@yl-web ~]# ssh -v [email protected]
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to 10.1.101.35 [10.1.101.35] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
ssh_exchange_identification: read: Connection reset by peer

2、接続サーバー
サーバに問題が発生しているように見えますが、sshはサーバに接続できませんが、一般的にホストは物理端末で接続するよりも、具体的にはサーバに接続する方法を提供します.
3、道を間違えて書くのも役に立ちますdebug1: Connection refused by tcp wrapperなどのlogがあれば、このステップを参照してください.
つまり、クライアントipはサーバによって禁止されている可能性があります.fail 2 banまたは他のプログラムは、クライアントipを/etc/hosts.denyに投げつける可能性があります.
vi/etc/hosts.allowで表示
行sshd:ALLを追加します.
その後sshを再起動します.

#service sshd restart

問題が本当にipで禁止されている場合は、再起動してからokになるはずです.
クライアントがもう一度sshしてみます.

[root@yl-web ~]# ssh -v [email protected]
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to 10.1.101.35 [10.1.101.35] port 22.
debug1: connect to address 10.1.101.35 port 22: Connection refused
ssh: connect to host 10.1.101.35 port 22: Connection refused

私の問題がここにないことを説明します.
4、2つの役に立つコマンド
サーバ上で次のコマンドを実行すると、sshのすべてのlogを表示できます.
centosシステムは次のとおりです.

#service sshd stop
#/usr/sbin/sshd -d

ubuntuの場合、コマンドはsudo service ssh stopです. , sudo /usr/sbin/sshd -d .
問題が発生しました. /var/empty/sshd must be owned by root and not group or world-writable.
権限の問題です.確認してください.
私の権限は777になりましたが、sshdというディレクトリは
通常、このディレクトリの権限は次のとおりです.

[root@yl-web ~]# ll /var/empty/
total 0
drwx--x--x. 2 root root 6 May 13 03:41 sshd

 権限の変更:
権限を変更してsshdサービス【サービスsshd restart】を再起動します.クライアントはさらにsshでokになり、大成功しました.
5、コマンドの概要
これで問題は解決しましたが、/usr/sbin/sshd-dとはどういう意味ですか.
#man sshdこの2つのパラメータを見てみましょう.

     -D      When this option is specified, sshd will not detach and does not become a daemon.  This allows easy monitoring of sshd.

     -d      Debug mode.  The server sends verbose debug output to standard error, and does not put itself in the background.  The server also will not fork and will only process one connection.  This
             option is only intended for debugging for the server.  Multiple -d options increase the debugging level.  Maximum is 3.

 -dはdebugモードであり、サーバは詳細なdebug情報を画面に出力し、サーバはsshリンクを1つしか持たない.
三、余談
問題は解決したが、なぜこの問題が発生したのか思い出してみよう.私は昨日、ログ権限の問題を解決する際に、各階層のディレクトリ権限を777に暴力的に設定し、ディレクトリの読み書き権限の問題かどうかを探ってから権限を縮小した結果、sshログインに影響を及ぼしたからです.
一つの問題を解決するには原理が分からないと、問題を拡大しやすく、新しいバグも発生します.コードを書くには慎重で、間違いを書くには慎重で、その理由を知らないことが重要です.
参照先:
Connection Reset By Peer
 
本文の著者starofは、知識自体が変化しているため、著者も絶えず学習し成長しており、文章の内容も不定期に更新されている.http://www.cnblogs.com/starof/p/4709805.html問題があったら、私と討論して、一緒に進歩することを歓迎します.