The fact that scp has been carried for ages is part of its value proposition. It’s going to work. Much as I am fond of my dd/cat/tar/smoke signal hacks, scp is the standard. A bit of a tangent: There is a security hole in scp, ssh, TLS, basically everything running over IP. As transfer sizes have increased significantly, the identity of a certain population of files being moved is increasingly obvious due to byte count, compressed or otherwise. No, you don’t get to pad every transfer out to the maximum possible size, or delay transfers until you can aggregate payloads. Yes, somebody thought of that. There are limits. On Tue, Jun 16, 2020 at 9:47 AM Jakub Jelen <jjelen@xxxxxxxxxx> wrote: > 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@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
