ssh連接失敗，排錯經驗
原文 http://www.cnblogs.com/starof/p/4709805.html
主題 SSH
一、場景描述
ssh連接服務器，發現連接失敗，但是對應服務器的ip能夠ping通。
場景：
[root@yl-web ~]# ssh [email protected]_exchange_identification: read: Connection reset by peer[root@yl-web ~]# ping 10.1.101.35PING 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 ms64 bytes from 10.1.101.35: icmp_seq=2 ttl=64 time=0.722 ms64 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]_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013debug1: 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/0debug1: identity file /root/.ssh/id_rsa type -1debug1: identity file /root/.ssh/id_rsa-cert type -1debug1: identity file /root/.ssh/id_dsa type -1debug1: identity file /root/.ssh/id_dsa-cert type -1debug1: identity file /root/.ssh/id_ecdsa type -1debug1: identity file /root/.ssh/id_ecdsa-cert type -1debug1: identity file /root/.ssh/id_ed25519 type -1debug1: identity file /root/.ssh/id_ed25519-cert type -1debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_6.6.1ssh_exchange_identification: read: Connection reset by peer
2、連接服務器
現在看起來是服務器出問題了，雖然不能ssh到服務器，但一般來說主機會提供一些方法比去讓你連接，比如通過物理終端連進去，具體情況具體對待了，總之就是要連接到服務器上。
3、寫一個排錯彎路，但也是有用的
如果有 debug1: Connection refused by tcp wrapper 之類的log可參考這一步。
就是說你的客戶端ip可能被服務器給禁掉了，fail2ban或者其他的程序可能把你的客戶端ip扔到/etc/hosts.deny中了。
通過vi /etc/hosts.allow查看
加上一行sshd: ALL。
然後重啓ssh。
#service sshd restart
如果問題真的出在ip被禁，這樣重啓之後應該就ok了。
客戶端重新ssh試一下：
[root@yl-web ~]# ssh -v [email protected]_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013debug1: Reading configuration data /etc/ssh/ssh_configdebug1: /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 refusedssh: connect to host 10.1.101.35 port 22: Connection refused
說明我的問題不在這裏。
4、兩條有用的命令
在服務器上執行下面命令可以顯示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 0drwx--x--x. 2 root root 6 May 13 03:41 sshd
修改權限：
改好權限後重啓sshd服務【service sshd restart】。客戶端再ssh就ok，大功告成了。
5、命令簡介
至此問題已解決，但是 /usr/sbin/sshd -d 又是什麼意思呢？
# man sshd看一下這兩個參數。
-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鏈接。
三、題外話
雖然問題解決了，回想一下爲什麼會出這個問題？因爲我昨天在解決一個日誌權限的問題時，暴力的將每層目錄權限都設置成777，想試探一下是否是目錄讀寫權限的問題，然後再縮小權限，結果影響到了ssh登錄。
想想解決一個問題若不能知道原理，很容易放大問題，甚至出現新bug。寫代碼需謹慎，排錯需謹慎，知其然不知其所以然很重要。