Deprecation of scp protocol and improving sftp client

[Andreas Schneider]

On Tuesday, 16 June 2020 20:47:24 CEST Colin Watson wrote:
> On Tue, Jun 16, 2020 at 06:41:09PM +0200, Jakub Jelen wrote:
> >  * Change scp to use sftp internally
> 
> As an existence proof, pscp (from PuTTY) does exactly this; it tries the
> sftp protocol and falls back to the scp protocol if that fails, and it
> has -scp or -sftp options to force one or the other.  I've long meant to
> get round to putting something similar for OpenSSH, but never got far
> enough to really be worth mentioning.  (Of course it would still need to
> retain scp "source" and "sink" modes if invoked with -f or -t, to retain
> compatibility, since those are used on the server when an scp client
> connects; but there's no particular obstacle to that.)

You can easily detect the sink mode on connect and redirect to a scpd server 
implementation. There is no need to make it more complex than it is.

We have sftp server implementation around for long enough that the `scp` 
command can use the protocol.

Also if you have a scpd. You can reject the scp protocol completely by a 
config option.

> >  * Modify sshd to use some compatibility "scpd" to support old clients
> 
> This should be unnecessary.  When an scp client connects to an scp
> server, it passes the -f (source) or -t (sink) flag as appropriate;
> neither is part of the documented user-facing interface to scp.  I don't
> see any particular reason why scp (the program) couldn't continue to
> speak the scp protocol when invoked with -f/-t, but speak the sftp
> protocol when invoked in the normal way.

The scp command should only handle the client side, for the server you should 
have a server only implementation which could be disabled. Some people are not 
interested in the scp protocol if sftp can do the job. One security hole less 
:-)


	Andreas

-- 
Andreas Schneider                 asn at cryptomilk.org
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D