我的服務器一直正常使用，平時使用secureCRT進行管理，使用secureFX進行文件的上傳下載，突然有一天secureFX連接的時候出問題了，secureFX的日志如下:
i SecureFX 版本 6.6.1.289 (Official Release - November 4, 2010)
i 會話 00002 成功建立(為) session mydomain_218.245.0.54_cd.mydomain.com
i SSH2Core version 6.6.0.289
i 正在連接到 cd.mydomain.com:22 ...
i 正在從狀態 STATE_NOT_CONNECTED 更改為 STATE_EXPECT_KEX_INIT
i Using protocol SSH2
i RECV : Remote Identifier = 'SSH-2.0-OpenSSH_5.3'
i CAP : Remote can re-key
i CAP : Remote sends language in password change requests
i CAP : Remote sends algorithm name in PK_OK packets
i CAP : Remote sends algorithm name in public key packets
i CAP : Remote sends algorithm name in signatures
i CAP : Remote sends error text in open failure packets
i CAP : Remote sends name in service accept packets
i CAP : Remote includes port number in x11 open packets
i CAP : Remote uses 160 bit keys for SHA1 MAC
i CAP : Remote supports new diffie-hellman group exchange messages
i CAP : Remote correctly handles unknown SFTP extensions
i CAP : Remote correctly encodes OID for gssapi
i CAP : Remote correctly uses connected addresses in forwarded-tcpip requests
i The following key exchange method has been filtered from the key exchange method list because it is not supported: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==
i SEND : KEXINIT
i RECV : Read kexinit
i Available Remote Kex Methods = diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
i Channel Closed.
很是不解，Google了半天也沒解決問題。
首先為了確保其他稀奇古怪的問題出現，我將iptables和selinux都關閉，還是不行。
查看/etc/ssh/sshd_config文件中的 Subsystem sftp /usr/libexec/openssh/sftp-server 有沒有被注釋，經查是沒有被注釋的，而且文件系統里也有
[root@cd ~]# ll /usr/libexec/openssh/sftp-server
----------. 1 root root 63544 2月 22 2013 /usr/libexec/openssh/sftp-server
說明應該是對的。
然后開啟了ssh的dubug模式，編輯/etc/ssh/sshd_config文件，將LogLevel INFO改為LogLevel DEBUG，重啟了sshd服務
# /etc/init.d/sshd restart
再使用secureFX登錄時查看日志信息，
查看# tail -f /var/log/messages 時沒有日志輸出，
查看# tail -f /var/log/secure 時日志輸出如下，未見明顯的錯誤信息輸出：
Aug 12 18:21:59 cd sshd[1307]: debug1: Forked child 1870.
Aug 12 18:21:59 cd sshd[1870]: Set /proc/self/oom_score_adj to 0
Aug 12 18:21:59 cd sshd[1870]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Aug 12 18:21:59 cd sshd[1870]: debug1: inetd sockets after dupping: 3, 3
Aug 12 18:21:59 cd sshd[1870]: Connection from 171.214.177.214 port 52174
Aug 12 18:21:59 cd sshd[1870]: debug1: Client protocol version 2.0; client software version SecureFX_6_6_1_289 SecureFX
Aug 12 18:21:59 cd sshd[1870]: debug1: no match: SecureFX_6_6_1_289 SecureFX
Aug 12 18:21:59 cd sshd[1870]: debug1: Enabling compatibility mode for protocol 2.0
Aug 12 18:21:59 cd sshd[1870]: debug1: Local version string SSH-2.0-OpenSSH_5.3
Aug 12 18:21:59 cd sshd[1871]: debug1: permanently_set_uid: 74/74
Aug 12 18:21:59 cd sshd[1871]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Aug 12 18:21:59 cd sshd[1871]: debug1: SSH2_MSG_KEXINIT sent
Aug 12 18:21:59 cd sshd[1871]: debug1: SSH2_MSG_KEXINIT received
Aug 12 18:21:59 cd sshd[1871]: debug1: kex: client->server aes256-ctr hmac-sha1 none
Aug 12 18:21:59 cd sshd[1871]: debug1: kex: server->client aes256-ctr hmac-sha1 none
Aug 12 18:21:59 cd sshd[1871]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Aug 12 18:21:59 cd sshd[1871]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Aug 12 18:21:59 cd sshd[1871]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Aug 12 18:21:59 cd sshd[1871]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Aug 12 18:21:59 cd sshd[1871]: debug1: SSH2_MSG_NEWKEYS sent
Aug 12 18:21:59 cd sshd[1871]: debug1: expecting SSH2_MSG_NEWKEYS
Aug 12 18:21:59 cd sshd[1871]: debug1: SSH2_MSG_NEWKEYS received
Aug 12 18:21:59 cd sshd[1871]: debug1: KEX done
Aug 12 18:21:59 cd sshd[1871]: debug1: userauth-request for user root service ssh-connection method none
Aug 12 18:21:59 cd sshd[1871]: debug1: attempt 0 failures 0
Aug 12 18:21:59 cd sshd[1870]: debug1: PAM: initializing for "root"
Aug 12 18:21:59 cd sshd[1870]: debug1: PAM: setting PAM_RHOST to "171.214.177.214"
Aug 12 18:21:59 cd sshd[1870]: debug1: PAM: setting PAM_TTY to "ssh"
Aug 12 18:21:59 cd sshd[1871]: debug1: userauth-request for user root service ssh-connection
無解，繼續Google解決辦法 https://www.linuxquestions.org/questions/linux-server-73/can't-get-sftp-logging-to-work-931609/ 收到啟發，將 /etc/ssh/sshd_config 中的
Subsystem sftp /usr/libexec/openssh/sftp-server
改為
Subsystem sftp internal-sftp
重啟sshd后，sftp正常工作了。
但是原因仍然不知為何，回頭看看，發現 /usr/libexec/openssh/sftp-server 沒有任何權限：
# ll /usr/libexec/openssh/sftp-server
----------. 1 root root 63544 2月 22 2013 /usr/libexec/openssh/sftp-server
正常情況應該是這樣：
# ll /usr/libexec/openssh/sftp-server
-rwxr-xr-x. 1 root root 63544 Nov 23 2013 /usr/libexec/openssh/sftp-server
咨詢大師說 停止openssh 服務 rm sftp-server文件 正常的scp 過去 再啟動openssh
但是我是遠程操作，生產系統，不敢停止openssh服務，萬一連不上就瓜了，大師建議那就先這樣用着。
Note：/usr/libexec/openssh/sftp-server沒任何權限，root用戶都沒法刪除修改。