Deprecation of scp protocol and improving sftp client

[Blumenthal, Uri - 0553 - MITLL]

scp may be an ugly protocol, but it works, works nicely from a command line, and is quite convenient. FTP (and, presumably, sftp) is not nearly as convenient.

Why do you think your recommendation to "use sftp instead" keeps falling on the deaf ear? Usability, perhaps?

Perhaps it's time to stop preaching to people about what they should use, but instead - if you really want a change - design, implement, and release a new tool that would combine the usability of scp with the security you want to see? 
SFTP did not seem to make that cut. Next option?



On 6/16/20, 13:14, "openssh-unix-dev on behalf of Stuart Henderson" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of stu at spacehopper.org> wrote:

    On 2020/06/16 18:41, Jakub Jelen 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.

    I've tried to switch to sftp several times, the thing that always
    stops me is not being able to copy from local->remote directly
    on the command line.

    > 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)

    This would seem a good starting point. It would allow using
    "alias scp=sftp" for interactive shells (muscle memory / easier
    typing) and makes it possible to convert scripts across one by one
    from scp to sftp without unexpectedly breaking anything.

    >  * Change scp to use sftp internally

    Then you either have no fallback for scp with very old servers, or a
    mess of either/or code to cope with both protocols. And it would seem
    more complex to change the protocol code than the UI code.

    > 
    >  * 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200616/aeec019c/attachment-0001.p7s>