News: 1587969009

Good. FTP doesn't require that either the file source or destination be the control client.

Control client C can coordinate a transfer from server A to server B

Nor you need to give someone who doesn't need them SSH credentials. There is far less they can do with FTP only ones.

Yeah, but most servers don't allow it these days. For some reason allowing people to get a server to send data to a random port on another server was being abused.

It used to be good for bounce scans - proxying a port scan through the FTP server to scan IPs behind the firewall.

Okay, there's less you can do directly with an FTP password - but anyone capturing network traffic can read it, and if it's also the user's login password then you're stuffed. And most FTP servers (proftpd, wu-ftpd and pure-ftpd for example) by default require that a user has a valid login shell.

And that's not even considering all the goodies you often find by logging into a FTP server as "anonymous".

The things you need to do to *properly* configure FTP are not significantly simpler than setting up SFTP and at least if you use SFTP you don't have to worry about people sniffing credentials.

The reason people still use it is simple. Because it just works. Without any fannying around.

When I was working as a web developer I frequently heard this argument between developers who were for/against it in terms of deploying sites or even using it in a development environment to get their files from their local machine to a web server.

One classic was when there was a really heated argument and one dev said to another, "FTP is outdated bullshit, you should have your files on GitHub then do X, Y, Z and deploy them over ssh". The other dev replied "yeah, but we have to get this live immediately and I've just done it in the time you've been ranting". Both had a valid point.

If I remember Notepad++ has a plug in which allowed you to read and write files to FTP servers as if they where local storage. Always a useful bit for when you run everything live rather than ore-compile.

That said, this was good when there's only a couple of you, any more and proper deploy procedures need to be in place for everyone's sanity (and for finger pointing when an enevitable blamestorm happens. Any dev who's not cocked up either hasn't been working long enough, hard enough or is stubborn enough not to notice). The trick is making sure you don't screw up badly.

@Sgt_Oddball absolutely right. I should have said this was years ago and it was literally a couple of developers in a small office. I wouldn't advocate using FTP for web development now even in that scenario. But...

Although "proper" deployment processes have their advantages they often just create work elsewhere. Then try to claim that they are extremely efficient. The point that the FTP loving dev was making was that he could get something live pretty quickly because he didn't have to faff around with steps X, Y and Z that his opponent was suggesting. In my opinion that's one of the reasons FTP is still widely used.

Absolutely - and not just in industry but in the consumer space.

Good look setting up a github/x/y/z to some bog-standard cPanel or Plesk hosting (unless the admins have been uncommonly generous and enabled the appropriate plugins). I actually do do this with a hugo site - commit files to a private repo, which triggers a Github Action to rebuild the site and then... FTPs the Public directory onto the hosting.

But fundamentally, your options are login and use the web-based file manager or FTP(S) in. It's so easy your dad can use it.

If you maintain your own servers and can configure your workflow just how you like it (or use cloud services with the latest workflow options) then great. For many consumers and indeed SMBs, FTP is the lowest/simplest common denominator, regardless of whether it's used directly or at the end of an automated testing/build pipeline.

Along with RDP, which we're all told is prehistoric and "nobody uses RDP anymore" - oh yes they do!

What he did with FTP, could have been done just as easily with thousands of other file copy methods too..

SMB, NFS, SCP, RCP, RSYNC etc.

We used to use UltraEdit years ago, when I was in a support and development team (before DevfOps became a thing!), it also had built in FTP and SSH etc.

At peak we were a team of 6, all sat in one bay, all on desktops (early 2000s, no laptops or option to WFH). Change control was basically "Anyone doing anything with file x on box y at the moment?", If none said yes, "okay, I'm deploying change 'z' ,should be live in two mins".

Although I did eventually set up a cron job that automatically took hourly snapshots of all configurable files, only backing up those that changed, and created a diff log, so we could see in one place what changed, where and when.

Was also quite handy being able to have things like log files open in a tab on your local machine, without having to open a terminal.

I used to use with openoffice.

Clearly a gateway drug that will lead to much harder substances like K8.

I used to run as desktop RHEL3.x back in the day and lots of things I did right was using konqueror and fish to access all the boxen.

Would be nice if FTP would be updated to support modern enterprise file transfer requirements yet still easy enough to setup on any TCP/IP enabled device. I use FTP across my LAN to transfer files between all my Linux, Android and Windows devices. A breeze to setup and I can turn the servers off an on easily.

It does, there is FTPS which is FTP over SSL...

The problem is NAT.

FTP uses separate ports for data transfer and control, and the benefit here is that you can remotely initiate transfers between 2 servers without the data having to touch your client (especially useful when you have slow or asymmetric connections)...

But this doesnt play well with firewalls or nat, the firewall doesn't know which ports to open or which address to translate them too. There are kludges for plain FTP where the firewall will watch for FTP control traffic and intercept the requests, but this won't work if the control channel is encrypted.

There are also techniques like bounce scanning, where you can make an ftp server connect to arbitrary host/port combinations as a slow form of port scanning, so you can see what's reachable from the perspective of the FTP server.