openssh bugs - Nov 2006 - [Bug 1258] sftp-server run although Subsystem disabled

http://bugzilla.mindrot.org/show_bug.cgi?id=1258

           Summary: sftp-server run although Subsystem disabled
           Product: Portable OpenSSH
           Version: 4.3p1
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sftp-server
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: fplatel at free.fr


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 at 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.
==================================================



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1258





------- Comment #1 from fplatel at free.fr  2006-11-09 00:03 -------
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.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1258





------- Comment #2 from dtucker at zip.com.au  2006-11-09 09:11 -------
(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). 




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1258





------- Comment #3 from fplatel at free.fr  2006-11-09 15:53 -------
OK thank you for this clarification, so you can close the case as it's
not really a bug.
Fabrice




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1258


djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #4 from djm at mindrot.org  2006-11-10 02:48 -------
Thanks




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.