On Jan 24 03:47, Malcolm wrote:> Quoting Chris High <highc at us.ibm.com>: > > > caught my eye. Do you see any 'advantage' to using sftp with an untrusted > > server? If so, any thoughts about making an easy way to disable scp both > > client and server side when doing an installation? > > SFTP allows file resume, while scp does not. If this isn't the case, I'm > welcome to be corrected. > > scp's command line interface is intuitive and reasonably sensible, especially > as a follow-on to ncftp/friends like interfaces, a la local->remote/remote-local. > > Problem is, scp doesn't let you resume interrupting up/downloads. So we have > to use the nasty/non-CLI-friendly sftp thing, which doesn't (seem) to support > fairly straightforward mechanisms (user at hostname:/file/pathname/object <-> > local object sort of stuff. > > There are too many arbitrary "issues" between the sftp/scp/ftps > implementations to sort for end-users for them to pick outside of which one > "gets the job done". > > I wish there was a way for either sftp to get scp-like interfaces, or scp to > get all of the functionality of sftp, so the 'other' can die the ignominious > death it deserves.What's missing in sftp is a drop in replacement mode for copying to the remote server, i.e. this should work out of the box: $ sftp -rp local_dir server:path But, alas: ssh: Could not resolve hostname local_dir: Name or service not known If sftp had this mode, I would alias scp=sftp and be done with it. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20190124/9d88f046/attachment.asc>
Would rsync qualify as an scp replacement? It supports resumes via --partial On Thu, Jan 24, 2019, 7:29 AM Corinna Vinschen <vinschen at redhat.com wrote:> On Jan 24 03:47, Malcolm wrote: > > Quoting Chris High <highc at us.ibm.com>: > > > > > caught my eye. Do you see any 'advantage' to using sftp with an > untrusted > > > server? If so, any thoughts about making an easy way to disable scp > both > > > client and server side when doing an installation? > > > > SFTP allows file resume, while scp does not. If this isn't the case, I'm > > welcome to be corrected. > > > > scp's command line interface is intuitive and reasonably sensible, > especially > > as a follow-on to ncftp/friends like interfaces, a la > local->remote/remote-local. > > > > Problem is, scp doesn't let you resume interrupting up/downloads. So we > have > > to use the nasty/non-CLI-friendly sftp thing, which doesn't (seem) to > support > > fairly straightforward mechanisms (user at hostname:/file/pathname/object > <-> > > local object sort of stuff. > > > > There are too many arbitrary "issues" between the sftp/scp/ftps > > implementations to sort for end-users for them to pick outside of which > one > > "gets the job done". > > > > I wish there was a way for either sftp to get scp-like interfaces, or > scp to > > get all of the functionality of sftp, so the 'other' can die the > ignominious > > death it deserves. > > What's missing in sftp is a drop in replacement mode for copying to > the remote server, i.e. this should work out of the box: > > $ sftp -rp local_dir server:path > > But, alas: > > ssh: Could not resolve hostname local_dir: Name or service not known > > If sftp had this mode, I would alias scp=sftp and be done with it. > > > Corinna > > -- > Corinna Vinschen > Cygwin Maintainer > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
On Jan 24 07:41, Josh Soref wrote:> Would rsync qualify as an scp replacement? It supports resumes via --partialFor me it's a muscle memory thingy. Before even thinking of using sftp or rsync, my fingers already typed `scp -rp '. Corinna> > On Thu, Jan 24, 2019, 7:29 AM Corinna Vinschen <vinschen at redhat.com wrote: > > > On Jan 24 03:47, Malcolm wrote: > > > Quoting Chris High <highc at us.ibm.com>: > > > > > > > caught my eye. Do you see any 'advantage' to using sftp with an > > untrusted > > > > server? If so, any thoughts about making an easy way to disable scp > > both > > > > client and server side when doing an installation? > > > > > > SFTP allows file resume, while scp does not. If this isn't the case, I'm > > > welcome to be corrected. > > > > > > scp's command line interface is intuitive and reasonably sensible, > > especially > > > as a follow-on to ncftp/friends like interfaces, a la > > local->remote/remote-local. > > > > > > Problem is, scp doesn't let you resume interrupting up/downloads. So we > > have > > > to use the nasty/non-CLI-friendly sftp thing, which doesn't (seem) to > > support > > > fairly straightforward mechanisms (user at hostname:/file/pathname/object > > <-> > > > local object sort of stuff. > > > > > > There are too many arbitrary "issues" between the sftp/scp/ftps > > > implementations to sort for end-users for them to pick outside of which > > one > > > "gets the job done". > > > > > > I wish there was a way for either sftp to get scp-like interfaces, or > > scp to > > > get all of the functionality of sftp, so the 'other' can die the > > ignominious > > > death it deserves. > > > > What's missing in sftp is a drop in replacement mode for copying to > > the remote server, i.e. this should work out of the box: > > > > $ sftp -rp local_dir server:path > > > > But, alas: > > > > ssh: Could not resolve hostname local_dir: Name or service not known > > > > If sftp had this mode, I would alias scp=sftp and be done with it. > > > > > > Corinna > > > > -- > > Corinna Vinschen > > Cygwin Maintainer > > Red Hat > > _______________________________________________ > > 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-- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20190124/1cacf2e8/attachment.asc>
Corinna Vinschen wrote on 1/24/19 6:28 AM:> What's missing in sftp is a drop in replacement mode for copying to > the remote server, i.e. this should work out of the box: > > $ sftp -rp local_dir server:path > > But, alas: > > ssh: Could not resolve hostname local_dir: Name or service not known > > If sftp had this mode, I would alias scp=sftp and be done with it. >If memory serves the argument was "if we are calling it an ftp client then it should act like an ftp client."? And sadly most ftp clients don't provide a command-line push UI which is why I abandoned my patch. I know Damien Miller about a year or so later asked if I had the patch still, but by that point I had already left the project due to time constrains and deleted all my local code.? So maybe if presented again with something more "ftpish" it could be accepted: sftp -rp -U /path/to/transfer? [user@]server:path Description: -U??? upload a local file or directory (if -r is used) to the remotely server and path. Damien, Darren?? Does that seem like a reasonable thing that may be accepted upstream for sftp? I know it isn't a "UI replacement" but it at least provides a more complete UI for phasing people off of scp. Ben
I almost never use bare 'scp' or 'sftp' anymore; I start with either 'rsync' or, if 'rsync' is not present and not installable on one end or the other, the "tar-over-bare-ssh" approach: ``` tar cf - localpath | ssh remote.host 'cd remotepath && tar xvf -' ``` I'd be in favor of one of the following: 1. 'scp' goes away, and support for file transfer via CLI is added to 'sftp'. 2. 'scp' goes away, and support for file transfer via CLI is changed to, "use rsync or something-over-bare-ssh instead, good luck". 3. 'scp' stays, but becomes the CLI for SFTP, and the SCP protocol breaks. 4. 'scp' goes away, and a new 's'-command[*] is created that does file transfer via CLI, possibly using SFTP. The old proprietary SSHv2 did #4, with the new command called 'scp2', and a long tail for the transition while 'scp' and 'scp2' coexisted. ____________________ [*]: For example, "sput", "scpx", or for fun, "Secure Copying Remote Artifacts Program" = "scrap". -- jim knoble> On Jan 24, 2019, at 10:27, Ben Lindstrom <mouring at offwriting.org> wrote: > > Corinna Vinschen wrote on 1/24/19 6:28 AM: >> What's missing in sftp is a drop in replacement mode for copying to >> the remote server, i.e. this should work out of the box: >> >> $ sftp -rp local_dir server:path >> >> But, alas: >> >> ssh: Could not resolve hostname local_dir: Name or service not known >> >> If sftp had this mode, I would alias scp=sftp and be done with it. >> > If memory serves the argument was "if we are calling it an ftp client then it should act like an ftp client." And sadly most ftp clients don't provide a command-line push UI which is why I abandoned my patch. > > I know Damien Miller about a year or so later asked if I had the patch still, but by that point I had already left the project due to time constrains and deleted all my local code. So maybe if presented again with something more "ftpish" it could be accepted: > > sftp -rp -U /path/to/transfer [user@]server:path > > Description: > > -U upload a local file or directory (if -r is used) to the remotely server and path. > > > Damien, Darren? Does that seem like a reasonable thing that may be accepted upstream for sftp? > > I know it isn't a "UI replacement" but it at least provides a more complete UI for phasing people off of scp. > > Ben > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On Thu, 2019-01-24 at 12:27 -0600, Ben Lindstrom wrote:> I know it isn't a "UI replacement" but it at least provides a more > complete UI for phasing people off of scp.I don't think this is an ideal solution... OpenSSH should be "overall" secure (that's what it's meant for), and especially not be a collection of tools/algos/etc. of which some(!) are safe to user and others not (with the user having to know which). This is, why upstream took the wise decision to eventually drop things like SSHv1 support and remove others (questionable algos) from being used by default. So with respect to scp (the tool) I see only the following reasonable ways: - make it securely usable with the SCP protocol (and IMO this should mean the general assumption that a remote server might be hostile) - let it use another protocol with which it can be made secure, at the same time disabling the "accidental" use of an unsafe SCP protocol, e.g. by moving all that in another client tool like not-so-scp ;-) or by having a switch like --use-legacy-not-so-secure-scp-protocol (names are subject to debate :D) - tossing scp altogether (of course, one could still try to fix the legacy SCP protocol as much as possible) Since it (scp) is used in probably millions of places in scripts and by users completely unaware of these issues, there should be really a hard break if it cannot be secured, cause these people assume it's secure. Therefore I think it's not enough to just provide a more convenient command line interface to sftp (as scp would be still there with issues) ? and yes, I personally would really hate having to write that more character ;-) If it's possible to just use SFTP behind scp,? great,? maybe that even allows for more features to come up in the future. Cheers, Chris.