Deprecation of scp protocol and improving sftp client

[Jakub Jelen]

On Tue, 2020-06-23 at 08:06 +0200, Markus Friedl wrote:
> I had something in mind like this for years, but with slightly
> different steps:
> My naive approach would be to keep the scp user interface and switch
> to the sftp protocol internally. We could add a -M [scp|sftp] option
> to scp and select the internal protocol. Later we switch the default
> from scp to sftp.
> No need to change sshd or write scpd.

Thank you all for comments and initial feedback. It looks like this is
something that many people already had in minds, but for some reasons,
it never happened.

I tried to put together something that now works and passes the scp
testsuite (with both scp and sftp modes):

https://github.com/openssh/openssh-portable/pull/194

What does not work is the extended remote-to-remote through local,
which would require some more low-level protocol tweaks.

Most of the code is taken and adapted from the sftp.c . There are still
a few TODOs, but lets take it as a first iteration/proof of concept.

Considering the automatic fallback to scp, the way how it works now
(executing another ssh in subprocess) it would require going through
the whole key exchange and authentication again, spawning a new ssh
process, which sounds very cumbersome.

Much nicer solution would be using ssh_api to handle commands/subsystem
requests inside a single ssh session, but it would be much more code
and changes that I wanted to avoid in the first iteration (if the
ssh_api is already usable for something like this -- I would have to
check).

So again, comments, suggestions and feedback welcomed. I am not sure if
there is some other mailing list to get more attention from other
OpenBSD developers or this one is fine.

Thanks,
Jakub

> -m
> 
> Am Di., 16. Juni 2020 um 18:48 Uhr schrieb Jakub Jelen <
> jjelen at redhat.com>:
> > Hello all,
> > 
> > I believe we all can agree that scp is ugly protocol carried for
> > ages
> > only for its simplicity of its usage and really no dependencies as
> > it
> > is installed together with every ssh client. But as we have seen
> > recently, its simplicity and flexibility comes with security issues
> > [1], it does not have great performance and there is really no
> > development in there.
> > 
> > Over the years, we still keep recommending people to use sftp
> > instead,
> > but its api is not that flexible and simple to be usable as a drop-
> > in
> > replacement in scripts nor for the occasional ad-hoc transfers of
> > few
> > files from one server to another.
> > 
> > Before I start hacking, I would like to hear some opinions from
> > others,
> > whether this is something planned, welcomed or whether there are
> > some
> > good reasons to keep scp alive.
> > 
> > I have in my mind three things/steps that would make it possible:
> > 
> >  * Update sftp client to be drop-in replacement for scp
> >    (and/or)
> >  * Change scp to use sftp internally
> > 
> >  * Modify sshd to use some compatibility "scpd" to support old
> > clients
> > 
> > and some time later
> > 
> >  * Remove scp or replace it with a symlink
> > 
> > 
> > [1] http://www.openssh.com/txt/release-8.0
> > 
> > Any ideas/comments/suggestions?
> > 
> > 
> > Best regards,
> > --
> > Jakub Jelen
> > Senior Software Engineer
> > Security Technologies
> > Red Hat, Inc.
> > 
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.