sftp Vs scp
Josh Soref
jsoref at gmail.com
Thu Jan 24 23:41:07 AEDT 2019
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
>
More information about the openssh-unix-dev
mailing list