Bug 1258

Summary: sftp-server run although Subsystem disabled
Product: Portable OpenSSH Reporter: Fabrice PLATEL <fplatel>
Component: sftp-serverAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED INVALID    
Severity: normal    
Priority: P2    
Version: 4.3p1   
Hardware: Other   
OS: All   

Description Fabrice PLATEL 2006-11-08 23:57:09 AEDT 
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.
===================================================
Comment 1 Fabrice PLATEL 2006-11-09 00:03:05 AEDT 
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.
Comment 2 Darren Tucker 2006-11-09 09:11:48 AEDT 
(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).
Comment 3 Fabrice PLATEL 2006-11-09 15:53:53 AEDT 
OK thank you for this clarification, so you can close the case as it's not really a bug.
Fabrice
Comment 4 Damien Miller 2006-11-10 02:48:54 AEDT 
Thanks
Comment 5 Damien Miller 2008-04-04 09:57:07 AEDT 
Close resolved bugs after release.