Note that "SFTP" has no single meaning. Depending on the client, it may mean "FTP encrypted with SSL" or "FTP with encryption extensions of one of a couple of types invented independently by FTP server authors over the years" or "SSH File Transfer Protocol" (which is actually the real meaning of the abbreviation, and was in use for several years before secure FTP began to be common).<p>Historically, people tried to convince folks to call it FTPS (for FTP over SSL, which is the most popular form of secured FTP), but that seems to have never taken off. Unfortunate, since SFTP means too many incompatible things.<p>It's stabilized somewhat in recent years, and usually clients will do the right thing--and the most common meaning of SFTP has come to be "FTP encrypted with SSL" (which is actually one of the weaker forms of security for FTP--but it's got some semblance of "standardization", and works in lots of clients and servers, so that makes it superior). And, of course, there is no RFC defining secure FTP, so it's a de facto "standard" which can lead to buggy implementations and a lot of finger pointing--server says client is wrong, client says server is wrong, user says "I give up" and uses FTP, instead.
You know, back in the day, there was an idea called "opportunistic encryption". How it worked was, you would put a FreeBSD box running S/WAN at the edge of your network, and if it detected a similar box at the other end, they would seamlessly encrypt your stream (and if not, just let it straight through). Now, if this idea had gotten the traction it deserved, we could all happily be using telnet, FTP, whatever, rather than <i>everyone</i> having to be aware of encryption, your SA would just sort it once, for everyone, and they'd keep on using familiar tools.
SFTP is its own debacle. It's a handy alternative to "scp" when you don't want to open a second connection to grovel through "find" on the target system, but it's even less firewall-friendly than FTP: you can't enable users to grab files with SFTP without <i>also</i> enabling them to SSH to remote hosts.<p>Most enterprises <i>don't</i> allow outbound SSH through their firewalls, in part because SSH is its own slippery slope: if you're allowing SSH, you're allowing people to build VPN tunnels.<p>The real-world operational problem that FTP solves is upload. There is no download application that HTTP doesn't solve better than FTP. If Apache shipped with a mod_upload with a reasonable configuration system and a simple, workable web interface for specifying what to put where, FTP could be laid to rest.
I'd definitely leave age out of the argument that FTP is bad seeing as how plenty of people use old programming languages, old OSes, and old software for the simple fact that it "just works."
this is a matter of right tool for the job. for important stuff, everything should happen over a secure tunnel (ssl, ssh port tunneling or just using scp.) ftp is good for public file download/drop box where you want to easily support resume.
Well, I'd gladly switch to sftp, but dumb-ass OSX and Windows don't understand it out of the box and most users are unaware of more powerful (and easier to use) alternative OS, which leaves us stuck with this commercialized mediocrity.<p>Why wouldn't we also stop using Apple Finder, FAT, IE6, non-UTF encodings and bunch of other legacy crap? Ohh-ho-ho... so many topics to blog about...
I'd like to use SFTP or scp for everything, but I've discovered that it's considerably slower than regular FTP. I wish that there was a way of encrypting the login but sending everything else via plain FTP for speed.
sftp is not ideal; looks like the author is not aware that ssh (which is what sftp uses) is rather slow on WAN due to buffer issues:<p><a href="http://www.psc.edu/networking/projects/hpn-ssh/" rel="nofollow">http://www.psc.edu/networking/projects/hpn-ssh/</a><p><a href="http://www.psc.edu/networking/projects/hpn-ssh/papers/i2mm-hpn-ssh.ppt" rel="nofollow">http://www.psc.edu/networking/projects/hpn-ssh/papers/i2mm-h...</a>