Issues with SFTP

[Dan Kaminsky]

> oh, can you educate us on the history of sftp and rcp/scp?

If you like.

Best I can tell, Tatu put together the entire ssh package to replace the
Berkeley R* series of tools(rlogin, rsh, rcp, etc)  The r, or remote series
of tools, existed to change the context of a generally local command --
login, sh, cp -- as directly as possible into a remote command.  So pipes
were redirected, syntaxes were mildly updated to include hosts as well as
paths, and so on.

The security was very difficult to configure and wasn't meaningful anyway.
So Tatu built s* equivalents for almost the entire r* series -- command line
compatible to the point that you could (and still can!) symlink rcp to scp
and all tools thinking they were shelling out to rcp would just work.

(Interestingly enough, there is no s* equivalent to rexec.  I'm not sure if
that's right or so very wrong.)

ssh was successful because it transparently mapped to workflows users
already knew how to work with, and did so using reasonably straightforward
methods.  That it handled security much more reliably than the r* series
could just sealed the deal.

scp was the tool distributed with ssh to handle file transfers.  For various
reasons, it wasn't sufficient for most workflows -- and since FTP wouldn't
tunnel over the port forwards ssh supported, the choice was between learning
a new, less efficient workflow or being insecure.

People chose insecurity, like they usually will.

> SCP wasn't very usable, so it wasn't used, so security suffered
> :because FTP refused to die.
>
> really?

Really.  Compare how much needs to be typed by the user in the FTP example
vs. in the SSH example.  Note the multiple apps required, the amount of
redundancy, even the degree of punctuation syntax needed.

Dan at EFFUGAS ~
$ ftp -i
ftp> open 10.0.1.11
Name (10.0.1.11:Dan): temp
Password:
ftp> ls
ftp> mkdir foo
ftp> cd foo
ftp> mput mid1.pdf
ftp> get mid2.pdf
ftp> mget *
ftp> quit

to:

$ ssh temp at 10.0.1.11 ls
temp at 10.0.1.11's password:
$ ssh temp at 10.0.1.11 mkdir foo
temp at 10.0.1.11's password:
$ scp mid1.pdf temp at 10.0.1.11:foo
temp at 10.0.1.11's password:
$ scp temp at 10.0.1.11:foo/mid2.pdf .
temp at 10.0.1.11's password:
$ scp temp at 10.0.1.11:foo/* .
temp at 10.0.1.11's password:

FTP keeps state in the user interface and implements a pretty complete file
transfer interface -- get, put, list, mget/mput, often resume.  SCP does
(m)get/put, nothing more, and loses state in between each command.

FTP does better for most workflows.  Just how it is.

If you don't like SFTP, don't use it.  I don't like SCP, and won't even
document the use of SFTP -- I do everything with cat and tar and whatnot
because they're most likely to work.

> SFTP was born, and has a chance to wipe out
> :FTP.  You wanna tell me SFTP should be less usable than Windows95
ftp.exe?
> ::-)
>
> actually, HTTP is the FTP successor.  everyone knows that.

Suuuuure, HTTP is the FTP successor.  Go ask every web designer you know how
they upload their website to the server. :-)

HTTP is great for getting files statelessly, it's awkward as hell for
putting files, and it's completely silent on listing available files,
changing file modes, and so on.  Don't get me wrong -- I like the
protocol -- but a replacement for FTP it aint.  WebDAV tried to be
HTTP-doing-FTP, and would have succeeded had MS written a filesystem
redirector.  They didn't, so it failed completely.

--Dan