sftp Vs scp

Corinna Vinschen vinschen at redhat.com
Thu Jan 24 23:28:12 AEDT 2019

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

More information about the openssh-unix-dev mailing list