openssh unix dev - Aug 2020 - Deprecation of scp protocol and improving sftp client

On 2020/08/05 16:17, raf wrote:
> The problem is when, for example, you only have
> scp/sftp access to a remote server, such as your bank,
> and you use WinSCP to transfer transaction files to
> them to be actioned (people do this where I work), and
> the bank hasn't properly protected themselves from this
> "vulnerability". I really hope all banks do take this
> vulnerability into account (e.g. by just supporting
> sftp). It matters a lot for them. But it's an issue for
> the bank / remote server, not an issue for the user who
> doesn't and shouldn't need to know anything about this
> (in the banking case).
It matters for the user too. They need to know whether to use an sftp
or an scp client, and if it's sftp then some things they may want to do
(copying a file *to* a remote server) need a complicated method if using
openssh's sftp client (echo "put foo" | sftp -f - hostname).

On Wed, 2020-08-05 at 08:33 +0100, Stuart Henderson
wrote:
> On 2020/08/05 16:17, raf wrote:
> > The problem is when, for example, you only have
> > scp/sftp access to a remote server, such as your bank,
> > and you use WinSCP to transfer transaction files to
> > them to be actioned (people do this where I work), and
> > the bank hasn't properly protected themselves from this
> > "vulnerability". I really hope all banks do take this
> > vulnerability into account (e.g. by just supporting
> > sftp). It matters a lot for them. But it's an issue for
> > the bank / remote server, not an issue for the user who
> > doesn't and shouldn't need to know anything about this
> > (in the banking case).
> 
> It matters for the user too. They need to know whether to use an sftp
> or an scp client, and if it's sftp then some things they may want to
> do
> (copying a file *to* a remote server) need a complicated method if
> using
> openssh's sftp client (echo "put foo" | sftp -f - hostname).
At this moment, downloading files using sftp works the same as with
scp:

    sftp localhost:/tmp/scp.c /tmp/tmp

Extending sftp to work the same way for uploading files to avoid the
above mess should be also pretty easy and would cover the most common
use cases.

Getting complete feature-parity with scp would be another feat though.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

On Wed, Aug 05, 2020 at 11:03:41AM +0200, Jakub Jelen
wrote:
> At this moment, downloading files using sftp works the same as with
> scp:
>
>    sftp localhost:/tmp/scp.c /tmp/tmp
>
> Extending sftp to work the same way for uploading files to avoid the
> above mess should be also pretty easy and would cover the most common
> use cases.
yes, but in 20 years nobody has gotten around to it. :)
> Getting complete feature-parity with scp would be another feat though.
I don't think many people want *complete* feature parity, and that's 
probably impossible to do without reintroducing the same security issues 
as scp. What would make sftp a viable replacement is simply supporting 
sending and receiving files with optional permission preservation and 
recursion (99.9% of what scp is used for). sftp is most of the way 
there, but if someone can't send a file with a simple sftp invocation 
they'll just keep using scp.