Deprecation of scp protocol and improving sftp client

[Markus Friedl]

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.

-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