I have found the same strange behaviour on Openssh3.8p1 on AIX and LINUX and also on OpenSSH4.1p1 and OpenSSH4.3p2 on AIX5.3 (don't have a linux server with openssh >3.8). The problem I found is : once I have de-activated sftp subsystem by commenting the "Subsystem" line at the end of the sshd_config file and restarted the sshd daemon, I can't connect with SFTP command-line client, so this is the normal behaviour... but when I connect with filezilla in SFTP mode I can connect and browse/download/upload, I can see in the syslog trace of sshd that the sftp subsystem was not found : Nov 8 16:19:15 AIX43P2 sshd[12922]: subsystem request for sftp Nov 8 16:19:15 AIX43P2 sshd[12922]: subsystem request for sftp failed, subsystem not found But the filezilla session is not disconnected, I can also see that a "sftp-server" has been spawn on my AIX (or LINUX) server. Here is a trace of the sshd daemon when I connect with Filezilla : =================================================== debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: monitor_read: checking request 10 debug3: mm_request_receive_expect entering: type 11 debug3: inside auth_password debug3: mm_request_receive entering debug3: AIX/authenticate result 0, msg debug3: AIX SYSTEM attribute compat debug3: AIX/setauthdb set registry 'files' debug3: AIX/passwdexpired returned 0 msg debug3: aix_restoreauthdb: restoring old registry '' debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 11 Accepted password for root from 192.168.0.113 port 4088 ssh2 debug3: mm_auth_password: user authenticated debug1: monitor_child_preauth: root has been authenticated by privileged process Accepted password for root from 192.168.0.113 port 4088 ssh2 debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 24 debug3: mm_send_keystate: Sending new keys: 2004a018 20049ee8 debug3: mm_request_receive entering debug3: mm_newkeys_to_blob: converting 2004a018 debug3: mm_newkeys_to_blob: converting 20049ee8 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_send_keystate: Finished sending state debug3: mm_newkeys_from_blob: 2004a6e8(139) debug2: mac_init: found hmac-sha1 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 2004a6e8(139) debug2: mac_init: found hmac-sha1 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 5 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request subsystem reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req subsystem subsystem request for sftp subsystem request for sftp failed, subsystem not found debug1: server_input_channel_req: channel 0 request exec reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req exec debug2: fd 8 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug2: fd 10 setting O_NONBLOCK debug2: channel 0: read 67 from efd 10 debug2: channel 0: rwin 16384 elen 67 euse 1 debug2: channel 0: sent ext data 67 debug2: channel 0: read 15 from efd 10 debug2: channel 0: rwin 16317 elen 15 euse 1 debug2: channel 0: sent ext data 15 debug2: channel 0: read 327 from efd 10 debug2: channel 0: rwin 16302 elen 327 euse 1 debug2: channel 0: sent ext data 327 debug2: channel 0: read 211 from efd 10 debug2: channel 0: rwin 15975 elen 211 euse 1 debug2: channel 0: sent ext data 211 debug2: channel 0: request keepalive@openssh.com confirm 1 ==>>> HERE I DISCONNECT THE SFTP CLIENT SESSION <<<=== Read error from remote host 192.168.0.113: A connection with a remote socket was reset by that socket. ===================================================
It seems like it is related to the fact that the command sftp-server is in the PATH : I have made the same test on a 3.4p1 openssh sshd server on linux and at first I found its behaviour was normal because I couldn't connect either with sftp command line client or filezilla in SFTP mode... but after that I just have copied sftp-server binary from the default location (which is not on the PATH) to /usr/sbin which is on the PATH, and I could connect with Filezilla again.
(In reply to comment #0) [...] > subsystem request for sftp > subsystem request for sftp failed, subsystem not found > debug1: server_input_channel_req: channel 0 request > exec reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req exec This indicates that after the subsystem request fails, the client sends a normal exec request (basically running the equivalent of "ssh server sftp-server". You can work around this by, eg, removing execute permission from sftp-server (or maybe making a "sftp" group, chgrp'ing sftp-server and making it owner and group execute only) but be aware that this does not stop people transfering files via other means (or even copying up another sftp-server binary as it's just a normal user-level process and doesn't require any privileges).
OK thank you for this clarification, so you can close the case as it's not really a bug. Fabrice
Thanks
Close resolved bugs after release.