Bug 1899

Summary:

Cannot disable sftp-server

Product:

Portable OpenSSH

Reporter:

Gary Golden <mail>

Component:

sshd

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED INVALID

Severity:

normal

CC:

djm, dtucker

Priority:

Version:

5.5p1

Hardware:

All

OS:

Linux

Attachments:

Description	Flags
Debug output	none

Description Gary Golden 2011-05-04 14:24:24 AEST

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.

Comment 1 Darren Tucker 2011-05-04 16:10:33 AEST

Have you SIGHUPed or restarted sshd?  the config file is only read at startup on after a HUP.

Comment 2 Gary Golden 2011-05-04 16:30:42 AEST

Yes, sure. I restart sshd on every file change.

Comment 3 Damien Miller 2011-05-05 16:29:10 AEST

Can't replicate. I'm pretty sure you are failing to correctly restart sshd.

Comment 4 Darren Tucker 2011-05-05 17:16:42 AEST

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/).

Comment 5 Gary Golden 2011-05-05 17:56:06 AEST

Created attachment 2038 [details]
Debug output

Comment 6 Gary Golden 2011-05-05 17:56:27 AEST

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?

Comment 7 Damien Miller 2011-05-05 22:41:36 AEST

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.

Comment 8 Gary Golden 2011-05-05 22:52:06 AEST

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.

Comment 9 Damien Miller 2011-09-06 15:32:54 AEST

close resolved bugs now that openssh-5.9 has been released