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@xxxxxxxxxx>: > > 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 > -- 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
