My server has been normal use, peacetime use of SECURECRT for management, using Securefx file upload download, and suddenly one day Securefx connection when the problem, Securefx log as follows:
I Securefx version 6.6.1.289 (official Release-november 4, 2010)
I session 00002 successfully established (for) sessions mydomain_218.245.0.54_cd.mydomain.com
I ssh2core version 6.6.0.289
I am connecting to cd.mydomain.com:22 ...
I am changing from state state_not_connected to 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 to the key Exchange method list because it are not supported:gss-g ex-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.
Very puzzled, Google for a half-day also did not solve the problem.
First of all, to ensure that other bizarre problems arise, I will iptables and SELinux are closed, or not.
Check to see if the subsystem sftp/usr/libexec/openssh/sftp-server in the/etc/ssh/sshd_config file has been commented, is not commented, and the file system also has
[ROOT@CD ~]# Ll/usr/libexec/openssh/sftp-server
----------. 1 root 63544 February 2013/usr/libexec/openssh/sftp-server
The explanation should be right.
Then open the SSH dubug mode, edit the/etc/ssh/sshd_config file, the loglevel info to loglevel DEBUG, restart the sshd service
#/etc/init.d/sshd Restart
Use Securefx to view log information when you log on.
There is no log output when viewing # Tail-f/var/log/messages.
View # tail-f/var/log/secure log output as follows, no obvious error message output:
Aug 18:21:59 CD sshd[1307]: Debug1:forked child 1870.
Aug 18:21:59 CD sshd[1870]: Set/proc/self/oom_score_adj to 0
Aug 18:21:59 CD sshd[1870]: Debug1:rexec start in 5 out 5 Newsock 5 Pipe 7 sock 8
Aug 18:21:59 CD sshd[1870]: debug1:inetd sockets after Dupping:3, 3
Aug 18:21:59 CD sshd[1870]: Connection from 171.214.177.214 Port 52174
Aug 18:21:59 CD sshd[1870]: Debug1:client protocol version 2.0; Client software version securefx_6_6_1_289 Securefx
Aug 18:21:59 CD sshd[1870]: Debug1:no match:securefx_6_6_1_289 Securefx
Aug 18:21:59 CD sshd[1870]: debug1:enabling compatibility mode for Protocol 2.0
Aug 18:21:59 CD sshd[1870]: Debug1:local version string ssh-2.0-openssh_5.3
Aug 18:21:59 CD sshd[1871]: debug1:permanently_set_uid:74/74
Aug 18:21:59 CD sshd[1871]: DEBUG1:LIST_HOSTKEY_TYPES:SSH-RSA,SSH-DSS
Aug 18:21:59 CD sshd[1871]: Debug1:ssh2_msg_kexinit sent
Aug 18:21:59 CD sshd[1871]: Debug1:ssh2_msg_kexinit received
Aug 18:21:59 CD sshd[1871]: Debug1:kex:client->server aes256-ctr hmac-sha1 None
Aug 18:21:59 CD sshd[1871]: debug1:kex:server->client aes256-ctr hmac-sha1 None
Aug 18:21:59 CD sshd[1871]: Debug1:ssh2_msg_kex_dh_gex_request received
Aug 18:21:59 CD sshd[1871]: Debug1:ssh2_msg_kex_dh_gex_group sent
Aug 18:21:59 CD sshd[1871]: debug1:expecting ssh2_msg_kex_dh_gex_init
Aug 18:21:59 CD sshd[1871]: Debug1:ssh2_msg_kex_dh_gex_reply sent
Aug 18:21:59 CD sshd[1871]: Debug1:ssh2_msg_newkeys sent
Aug 18:21:59 CD sshd[1871]: debug1:expecting Ssh2_msg_newkeys
Aug 18:21:59 CD sshd[1871]: Debug1:ssh2_msg_newkeys received
Aug 18:21:59 CD sshd[1871]: Debug1:kex Done
Aug 18:21:59 CD sshd[1871]: debug1:userauth-request for user root service Ssh-connection method None
Aug 18:21:59 CD sshd[1871]: Debug1:attempt 0 Failures 0
Aug 18:21:59 CD sshd[1870]: debug1:PAM:initializing for "root"
Aug 18:21:59 CD sshd[1870]: debug1:PAM:setting pam_rhost to "171.214.177.214"
Aug 18:21:59 CD sshd[1870]: debug1:PAM:setting pam_tty to "ssh"
Aug 18:21:59 CD sshd[1871]: debug1:userauth-request for user root service ssh-connection
No solution, continue Google solution Https://www.linuxquestions.org/questions/linux-server-73/can ' t-get-sftp-logging-to-work-931609/ Receive inspiration, will/etc/ssh/sshd_config in the
subsystem Sftp/usr/libexec/openssh/sftp-server
To
subsystem SFTP INTERNAL-SFTP
After restarting the sshd, SFTP is working properly.
But the reason still somehow, looking back, found that/usr/libexec/openssh/sftp-server did not have any permissions:
# Ll/usr/libexec/openssh/sftp-server
----------. 1 root 63544 February 2013/usr/libexec/openssh/sftp-server
The normal situation should be this:
# Ll/usr/libexec/openssh/sftp-server
-rwxr-xr-x. 1 root root 63544 Nov 2013/usr/libexec/openssh/sftp-server
Consulting Master said Stop OpenSSH service RM sftp-server file Normal SCP in the past restart OpenSSH
But I am remote operation, production system, dare not stop openssh service, if not even on the melon, the master suggested that the first such use.
Note:/usr/libexec/openssh/sftp-server does not have any permissions, root users can not delete changes.