Using sftp

[dos2unix]

When I first started using Linux... back in the stone age. You installed sftp servers on everything.
It was really the most practical way to transfer files over the network at the time. Otherwise you set up a web server
and make download links for the files you wanted to transfer. That got old in a hurry.

If I remember a lot of ftp/sftp servers were proftpd, vsftpd, and cerebus ftp. I think there were probably a few others.
ssl wasn't really much of a thing yet, ftp was much more popular than sftp. ssh/scp didn't really exist for the most part.

For a long time, probably about 15 years or so. I only used scp. It was a bit of hassle to use and didn't have all the features of sftp, but
it was included in ssh, and I didn't have to setup a ftp server. Around 2007 or so ther was big security hole in vsftp and proftpd, so we quit
using them in favor of scp.

Funny how things go in circles sometimes. I think it was back in 2021, not so long ago really, some security holes were found in scp.
A lot of this was related more to openSSL, rather than ssh/scp directly. TLS start taking over the world about that time.

When ssh 9. was released, it started including sftp capability. For some distro's it was enabled by default. For other distro's you had to
manually enable it.

This is probably already enabled in your disto, but if not, edit the following file.
/etc/ssh/sshd_config

Add or uncomment the following line

Subsystem sftp /usr/lib/openssh/sftp-server

then restart ssh.

systemctl restart ssh

The major disadvantage of scp, was you had to know the path and name of the file to download in advance. You couldn't login
and use the "cd" and "ls" commands with scp.
Example:

scp username@hostname:/path/to/myfile.txt .

Using sftp is slightly different, and usually easier. You use GET to download

sftp username@hostname
ls
cd /home/user/Downloads
get myFavorteDistro-latest.iso

To upload is similar except you use "put" to upload.

sftp username@hostname
ls
cd /home/user/Downloads
put mySecondFavorteDistro-latest.iso

If you've been using scp, not to worry... in reality if you have ssh 9.x or newer installed, you're really using sftp in the background.
scp username@hostname:/path/to/file . equals sftp username@hostname get /path/to/filename
The scp commands really just wraps sftp in the background.

 

[KGIII]

For the longest time, security certificates were expensive (for public things, you could always have your own certificates in-house). We had to pay quite a bit and so the web was much less secure. You visited 'http' sites and everything was sent in clear-text. Even some payment providers used 'http' as well. Everything was sent in clear text and anyone along the route could intercept it.

Then, we had Let's Encrypt. They gave out free certificates. It took a while for people to start trusting them, but it did mean that the customary certificate providers came down in price. They'd continue coming down in price and they're now in the $50 range for extended verification - down from hundreds of dollars. I think some still charge just over $100 for an EV. (An EV also verified business information, like a physical address and phone numbers. An SSL is also a part of that.)

But, Let's Encrypt offered basic SSL services meaning that web traffic was sent when it was encrypted - using 'https' instead of 'http'. These days, Let's Encrypt is all over the place and trivial to install (and automate) in the various control panels (like Plesk and cPanel).

However, that's fairly recent. Let's Encrypt didn't get started until 2012 and it took several years for it to really catch on and a few more years to make it into the various control panels in an automated form. For a while, you'd use the LE data and import it manually (if you wanted and knew how).

But, my point is...

For the longest time, sites used FTP. Not 'SFTP', which meant that everything, including your password to authenticate with the server, was sent in plain text. Anyone who could intercept the traffic could see your password and the text could be read. This was known as a "MITM" attack - meaning "Man In The Middle", because anyone who could intercept the data (viewing it as it went past or intercepting and passing it along) could read the data in plain text...

Your passwords to the various sites were all sent in plain text.

These days, certificates are everywhere. You'll get a warning if the site doesn't have an up-to-date certificate installed. Your browser may refuse to let you visit a site if there's a malformed certificate or no certificate. You can sometimes tell it to override that, but that depends on your settings. You may have 'HTTPS Only' enabled.

There's also HSTS which is mostly another subject, but you can look it up. My sites use that. My sites will not let you in unless my certificates are in order. But, it's all automated these days. It has probably been about 5 years since I've had to manually configure a certificate or to manually renew a certificate.

Anyhow, it took a while. It took browsers a while to make it mandatory. That browser push also helped more people decide to start using a security certificate. So, now most of the public web is using https instead. And this is a good thing...

Here's the thing...

The whole 'https' standard was created in 1994...

I'd say that the tipping point was 2020 - where the overwhelming majority of sites used https...

So, for 36 years you were probably using FTP instead of SFTP and you were sending everything, including your emails and passwords, in plain text. Anyone along the route could intercept your traffic. We 'assumed' the various servers were reasonably secure, but people hacked into them on a regular basis. Anyone who could gain access could just sit back to collect the data and then process it later to find usernames, email addresses, passwords, etc...

As @dos2unix said above, using SFTP was the stone age. Yet, much of the public-facing internet used FTP well into the recent past. For a very long time, much of what you did online was not encrypted - even though the tools to do so had been invented a long time ago.

 

[osprey]

The first remote shell for fetching files used here was rsh which was part of the rlogin suite. The rsh-server needed to be installed on both machines and the system was run and configured within the inetd or xinetd software. The scp and ssh suite replaced it.

The debian manpage on rsh is dated at 2003 here: https://manpages.debian.org/bookworm/rsh-redone-client/rsh.1.en.html, but rsh was a part of unix and BSD since about the mid 1980s I've read though that's well before my time.

The ftp protocol is still used, but not much at all for the sites that used to be accessed from
here. Lots of ftp sites have closed up. One which still runs is:

ftp ftp.funet.fi

It's an archive with lots of linux and public files from the Finnish Uni.

Another ftp site still extant which may be of interest is the O'Reilly publishing house:

ftp ftp.oreilly.com

It has quite a listing of free material. O'Reilly publications on linux have been quite extensive.

 

[KGIII]

Lots of ftp sites have closed up.

Good point. Your post reminded me of something I didn't mention.

We used to use FTP quite a bit more often back then, as well. You'd often have to go to an FTP server to get software. Then, there were 'FTP dumps' full of questionably legal software along with the tools to bypass any restrictions said software might have.

But, even legitimately, you'd go to an FTP server to download files. I recall downloading some Linux .iso files via FTP back in the day. The protocol was used quite a bit for downloading stuff. Often, they were just open to the public. You didn't need any credentials to access the FTP server. So, you'd visit an interesting example.com and decide that you were curious, so you'd visit ftp.example.com just to see what they had stored in there - and it was open to the public quite often.

Sometimes... You'd not even need any elevated permissions at all... You'd have read, write, and execute permissions because the person setting it up didn't know better, and security was an afterthought back then.

Yup... That's right...

In some cases, you could access ftp.example.com and find the right path (often www or html, but most often public_html) and have access to the contents of their website. You could open and edit index.html and do so much more...

If you were more curious, you could look in the cgi_bin directory (PHP wasn't yet an option, though it did catch on pretty quickly, as far as technology goes) and muck about with the bits and bobs that made a site do things besides showing plain text and images. Sometimes, even those people who knew nothing about security and everything would be wide open.

Some folks liken those days to the 'Wild West'. I suppose, as is often the case in history, it was a bit like the TV and dime-store novel 'Wild West', deserving of quotes. See, the Wild West had more laws than we had at the time. You could break into a computer and they hadn't even written a law to make doing so a criminal matter.

I could go on, but I've digressed a bit beyond the FTP part of it. I'm sure many of the older folks here used to explore the 'net as much as I did, perhaps even more. I was an early adopter, long before it was world wide or even the 'internet'. It was an era of education and curiosity, and of adventure and discovery.

 

[Trml]

There is another acronym in the mix, FTPS - ftp with tls (RFC4217). Like FTP it uses two ports, control and data channel - higher throughput. In my recollection this was the protocol popular/professional ftp servers implemented first to secure transfers. Since crypto performance was an issue, some did not activate data channel encryption with it (crypto only on the control channel), particularly on intra-site dedicated backbone links.
Nowadays that's different of course as you have detailed. But still, Google for example uses a proprietary protocol (PSP) for the data-centre backbone. It encrypts/decrypts directly in the network hardware to reduce CPU overhead.

SFTP always implies the SSH protocols are used - different RFCs (4250-54), e.g. RFC4253 is the dedicated "SSH TLS" protocol. Noteworthy may be too that the mentioned sftp-server implementation is maintained by openssh.

I always find it crazy what sort of vulnerabilities are researched, found and fixed with openssh. E.g. a sidechannel vulnerability was found that enabled keystroke timing attacks only a few years ago. The attack monitors an established ssh connection and determine when an actual keyboard is used (e.g. operator issuing "su -" via ssh connection, then interrupt and try to mess with it). OpenSSH added a feature with 9.5 to mitigate the attack (ObscureKeystrokeTiming). A couple releases on, another CVE (2024-39894) found an issue with that obfuscation, again fixed in 9.8. It surely is tops of best tested internet servers worldwide.