openssh unix dev - May 2001 - Strange interaction of sftp and protocol version 1

As I read the manpage, you need to enable Subsystems to have the server 
support them. 

     [...]
     Subsystem
             Configures an external subsystem (e.g., file transfer daemon).
             Arguments should be a subsystem name and a command to execute up?
             on subsystem request.  The command sftp-server(8) implements the
             ``sftp'' file transfer subsystem.  By default no subsystems
are
             defined.  Note that this option applies to protocol version 2 on?
             ly.
     [...]

Are both of the following statements meant to be true?
	- Subsystems must be defined for the server to support them
	- Protocol version 1 does not support subystems

For Linux, I need the following to enable sftp:

    Subsystem      sftp    /usr/libexec/openssh/sftp-server

However, if I comment out/remove this line and restart sshd, I can still
start sftp when using Protocol version 1. 

  [gordonr at icedvovo]$ sftp timtam
  Connecting to timtam...
  Password: 
  Request for subsystem 'sftp' failed on channel 0
  Connection closed

This is fine - no DSA key, so fallback to password, then fail as sftp is
not enabled.

  [gordonr at icedvovo]$ sftp -1 timtam
  Connecting to timtam...
  Enter passphrase for RSA key 'gordonr at xxxxx': 
  sftp> 

OK, we have an RSA key, which works and then sftp starts and works.

Is this the correct behaviour?

Client and server are openssh-2.5.2p2-1.7.2

Gordon
--
  Gordon Rowell                         gordonr at e-smith.com
  http://www.e-smith.org (development)  http://www.e-smith.com (corporate)
  e-smith, inc. 1500-150 Metcalfe St, Ottawa, ON K2P 1P1 Canada

On Mon, 21 May 2001, Gordon Rowell wrote:
> Are both of the following statements meant to be true?
> 	- Subsystems must be defined for the server to support them
> 	- Protocol version 1 does not support subystems
yes.
> For Linux, I need the following to enable sftp:
>
>     Subsystem      sftp    /usr/libexec/openssh/sftp-server
>
> However, if I comment out/remove this line and restart sshd, I can still
> start sftp when using Protocol version 1.
>
>   [gordonr at icedvovo]$ sftp timtam
>   Connecting to timtam...
>   Password:
>   Request for subsystem 'sftp' failed on channel 0
>   Connection closed
>
> This is fine - no DSA key, so fallback to password, then fail as sftp is
> not enabled.
>
>   [gordonr at icedvovo]$ sftp -1 timtam
>   Connecting to timtam...
>   Enter passphrase for RSA key 'gordonr at xxxxx':
>   sftp>
>
> OK, we have an RSA key, which works and then sftp starts and works.
>
> Is this the correct behaviour?
Yes, in this case the sftp client will try to activate sftp by doing a
"ssh remotehost /path/to/sftp". This is less robust than a subsystem.

If your goal is to prevent sftp access, then delete or rename the
sftp binary. Recognise though that allowing ssh access is going to
implicitly allow file transfer in almost all cases anyway.

-d

-- 
| Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor
man's
| http://www.mindrot.org          /   distributed filesystem'' - Dan
Geer

On Mon, May 21, 2001 at 10:09:10PM +1000, Gordon Rowell
wrote:
> Are both of the following statements meant to be true?
> 	- Subsystems must be defined for the server to support them
yes.
> 	- Protocol version 1 does not support subystems
yes.
> For Linux, I need the following to enable sftp:
> 
>     Subsystem      sftp    /usr/libexec/openssh/sftp-server
yes.
> However, if I comment out/remove this line and restart sshd, I can still
> start sftp when using Protocol version 1. 
yes.
>   [gordonr at icedvovo]$ sftp timtam
>   Connecting to timtam...
>   Password: 
>   Request for subsystem 'sftp' failed on channel 0
>   Connection closed
yes, correct.
> This is fine - no DSA key, so fallback to password, then fail as sftp is
> not enabled.
> 
>   [gordonr at icedvovo]$ sftp -1 timtam
>   Connecting to timtam...
>   Enter passphrase for RSA key 'gordonr at xxxxx': 
>   sftp> 
> 
> OK, we have an RSA key, which works and then sftp starts and works.
> 
> Is this the correct behaviour?
yes.

with protocol 1 we do not use subsystems but try to execute sftp-server
with
	ssh host /path/to/sftp-server

you can do nothing to restrict this. it's just like
	ssh host date
	ssh host ls

if you remove the subsystem definition you can still use sftp with protocol v2:

	sftp -s server /path/to/sftp-server

the 'Subsystem sftp' declaration is just an additional level of
indirection: the client user does not need to know the exact location
of the sftp-server

-m

On Mon, May 21, 2001 at 10:27:36PM +1000, Damien Miller <djm at
mindrot.org> wrote:
> [...]
> If your goal is to prevent sftp access, then delete or rename the
> sftp binary. 
No such goal, just a surprising result (to me) that allowing protocol 
version 1 enabled sftp regardless of the configuration.

Which raises the issue that the default path to subsystems is 
/usr/libexec, whereas they are installed in (under Linux at least) in
/usr/libexec/openssh 

Is that intentional or is sftp meant to work "out of the box" for V1?
> Recognise though that allowing ssh access is going to
> implicitly allow file transfer in almost all cases anyway.
Sure.

Thanks,

Gordon
--
  Gordon Rowell                         gordonr at e-smith.com
  http://www.e-smith.org (development)  http://www.e-smith.com (corporate)
  e-smith, inc. 1500-150 Metcalfe St, Ottawa, ON K2P 1P1 Canada