Commenting out subsystem directive has no effect. #Subsystem sftp /usr/lib/openssh/sftp-server sftp-server is still functional. That's on debian squeeze. I'm open to do more tests, but need instructions.
Have you SIGHUPed or restarted sshd? the config file is only read at startup on after a HUP.
Yes, sure. I restart sshd on every file change.
Can't replicate. I'm pretty sure you are failing to correctly restart sshd.
or editing a config other than the one the daemon is reading. This can happen if you build openssh yourself without telling it to use /etc for its configs (the default is /usr/local/etc/).
Created attachment 2038 [details] Debug output
Here is what I did. 1. Ensured that no other sshd is running: # pgrep -fl sshd 2. Run sshd with debug output # /usr/sbin/sshd -dd Full log is attached. Few lines there is most important. debug2: load_server_config: filename /etc/ssh/sshd_config and after I initiate sftp connection: subsystem request for sftp subsystem request for sftp failed, subsystem not found but, In fact I got directory listing. Can sftp be compiled in by debian developers?
The lines after the subsystem is refused are: 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 It looks like the client is requesting a command execution session, i.e. executing sftp-server directly. You client looks like it is PuTTY, so it might do that implicitly. sshd is doing what you asked - refusing the subsystem but if you are going to allow shell access, there are plenty of ways to achieve exactly the same effect as it.
Client is filezilla, but I got your point. Indeed, it seems that client is smart enough to emulate sftp session. I removed executable bit from sftp-server binary and connection failed.
close resolved bugs now that openssh-5.9 has been released