Welcome to ITProTV, I'm your host Don Pezet.
[CROSSTALK]
[MUSIC]
>> You're watching ITProTV.
>> Hello and thank you for choosing ITProTV,
helping you learn wherever you go.
I'm your host, Zach Memos, as we continue on becoming a Linux server administrator.
We're gonna configuring an FTP server.
That sounds great, doesn't it, and
the person who's gonna let us know how to do that is Don Pezet.
Don, good morning sir.
>> Thanks for having me back Zach.
Yeah, in this episode we're gonna look at the file transfer protocol, or FTP.
It is a increasingly less popular way [LAUGH] of transferring files, but
you certainly can't beat it for ease of use.
So I wanted to walk through an example of how to get that setup.
So right here in this episode we're gonna see how to get FTP put in place.
How we can file that up and use it to be able to transfer files between our servers
and get things up and going.
And for a lot of you,
you may have moved on to other protocols that are a little more secure.
We'll tackle that in another episode as well, but for right now,
just focusing on quick and easy file transfers in FTP.
>> So now that you've got my curiosity going,
what does it take to get an FTP server up and running?
>> All right, well this is another one like, in the olden days [LAUGH].
>> Olden days again, back then.
>> Most Linux distros included a little package called XI Net,
and it included an FTP server.
And it was all kind of rolled in, but
one of the big problems with FTP is that it transfers data in plain text.
So if anybody's monitoring the network, they can intercept that data, and
now everything's compromised, so that's bad.
So as a result, most people moved on to other file transfer technologies, but
FTP still has a place.
We still use it for a lot of things, there's a lot of systems that require it,
and if you've already encrypted your data, you can ship it across FTP, and
it doesn't matter that FTP doesn't do encryption.
From that standpoint, it's actually a very efficient protocol that is supported by
every operating system that's out there, by Linux, Mac OS, Windows, and if we wanna
get it stood up, on most mono distros, we're gonna have to install an FTP server.
It's not gonna be there by default.
I've been using a Red Hat server for most of this series, and in the Red Hat world,
they really only support one FTP server, and that is the VSFTPD.
So it stands for the Very Secure File Transfer Protocol Demon and
I think it's a bit of a oxymoron that it's a very secure FTP server,
cuz you can only make it so secure.
But it does have some nice features to it and so we're gonna see getting that
installed, and what we need to do to get it configured.
Like most services getting it installed is really not that big of a deal.
So I'll go here on my server, and I'm gonna go ahead and
just bump up to a root shell real quick with pseudo -s.
And I will do a yum install vsftp, and that's gonna reach out,
and find that package, and get that installed.
VSFTPD is not just on Red Hat, obviously Centos and Fedora have it,
Ubuntu, Debian they've got it as well, it's a very common FTP server.
There are other ones that are out there that you're welcome to use, but
this one's considered the best right now.
So, I'll go ahead and say yes to getting installed.
Notice that massive size, 169k.
FTP is very, very old, and so it doesn't take a whole lot to get it up and running,
and doing it's job.
>> [LAUGH] >> FTP was designed in the late
1970s,- >> Wow.
>> And so here we are 40 years later.
>> It was the olden days.
>> It really was.
>> [LAUGH] >> And we still make use of it.
It is efficient for what it does, even though it's not very feature rich.
So, now that it's installed, it's there.
I usually wanna go one step further, and that is,
if I'm gonna set this up I need a way to test it, like a client to connect.
And so I'll typically install one,
and it used to be that you always had an FTP client built right into your disk row.
So, you can just type FTP and connect.
But see I don't have that anymore so, because they don't package FTP so much,
they don't package the FTP client so much either.
So I can choose to install one if I want.
There's a few different ones that are out there.
I know the Red Hat guys, they all love LFTP.
I'm not exactly sure why, but they do.
It's something about it that makes them happy.
There’s GFTP, which is good if you have a GUI.
I'm loaded into a server so I can't use that one.
I'm just gonna use the good, old, classic FTP.
So if you do a package search for a package just called FTP,
it's not an FTP server, it's just an FTP client.
And that will let you test this out and make sure it works, and
if you don't like it, you can always just remove it when your done.
See how it had no dependencies?
It's just that client all by itself, so- >> Just basic, yeah.
>> So really easy to add and remove, and
it's a blazing 61kilobytes in [LAUGH] size too.
>> [LAUGH] >> So this is small stuff to get it
installed, but now I've got it, and I can start up the FTP service.
So I can come in and say systemctl enable vsftpd.service,
and that'll enable it, and then I just need to start it.
Remember, the enable command says I wanna start this service anytime I boot up,
and the start command tells it I wanna start it right now,
cuz I don't wanna reboot, and so now the SFTPD is up, it's running.
I got my client, I could try and connect, but
we do still have a bit more that we need to get kinda working.
But once that's there, yeah, like if I were to try and connect right now I'd
just do ftp 127.0.0.1, I can see, I connect to the server, I get the prompt.
Here's vsftpd version 3.0.2 and now I need to log in.
But I'm testing this locally.
Like with a lot of things I need to allow this through my firewall so
users will be able to connect, and so I need to get that added.
So I'll do a quick Firewall-cmd --add
-service=ftp --permanent so
that it writes that to disk.
And then I'll run it again without permanent, so
that it takes effect right away, and that's gonna open it up on the network so
that users can ftp in, and get things set up.
Now I might not wanna do that right away, cuz there might be some other
configuration I wanna do first before I open it up.
But that's what opens it up on the firewall, and
now network users can connect to the FTP server.
>> So now that it's running, and you just kind of alluded to that,
how do we configure it?
>> Okay, so like a lot of services, we've got a config file that we can reach into
and we can modify a lot of the behavior of the FTP server.
The main configuration for it is in /etc/vsftpd,
that folder right there, and if you take a look in that folder you'll
see there's not a whole heck of a lot in here.
FTP users and user list, I'll explain those a little bit later, those are for
restricting access.
Then there's vsftpd.com, which is the file that actually has the configuration.
That's what we want to modify, and then lastly,
there's a script for migrating old FTP configurations into VSFTPD.
That was important when VSFTPD first came out and became popularized, but
most people don't need that anymore.
This was well over ten years ago.
So I'm gonna go and edit that main file,
the /etc/vsftpd/vsftpd.com, and in that file,
like a lot of these, you'll see where it's really well documented.
It kind of explains what each of the settings are, and
I can just go through and tweak those.
But you might have noticed there's a lot of settings.
There's a ton of options in here, and each of these have a default value, and
those default values might match what you want, but a lot of times they don't.
A lot of times they don't line up with what it is that you're trying to achieve.
So you need to go through and customize this to meet your needs.
Let me show you a couple of ones that I normally work with,
right here at the very beginning, the first one, allow anonymous FTP.
This is enabled by default, so anonymous users are allowed to connect.
Now when they connect, what are they allowed to do?
Well, right down a little bit further we'll see right enable=YES.
Right which is allowing right access.
So, anonymous users could connect, and
anonymous users could start uploading data in the system.
And so that may not be something that I want.
I need to tweak this.
If this is gonna be a private FTP server,
I might want to require a username and password.
And I would want to set allow anonymous enable equals no and turn that off right?
>> [LAUGH] >> And they give you a warning,
that if you just comment it out, the default is yes.
All these values in here are the default values.
So, I need to override that and sometimes I like to leave it in
here and comment out the default line and add my own line.
That way I can remember what the default was.
So now when I look at it I can see I set it to no but the default was yes.
So I can kind of remember that.
We've got local enable equals yes.
And that means do I want my local users to be able to access the system?
These are the users that are defined in slash etc slash pass wd.
That's how the local uniques users.
If I'm going to require authentication, anonymous enable equals no.
So if I require authentication, where do the user names and passwords come from?
Well, they come from your local users, the slash ATC,
slash pass WD file and we need to enable that.
If I set this to no, I'm not allowing anonymous, and
I'm not allowing my users, I just made a server that doesn't work.
But if I wanna force the server to be anonymous,
maybe I only want anonymous people to connect.
I would say anonymous enable equals yes, and local enable equals no.
And that way my users can't provide their own credentials and
start running around the server.
Okay so again,
we have to kind of tailor this to meet the needs of what we're trying to achieve.
Same thing goes down here for this right enable.
By default, it's going to obey the access control lists in the file system
If a user is authenticated.
If a user is anonymous, that creates a bit of a problem, right?
And there might be permissions on the file system for the other group and so
they get access to that.
But I might want to just completely block rights for
the whole server regardless of ACLs.
And so we can change that right here with write enable.
After that the rest of these options are not ones that we normally
have to manipulate too much.
You will notice this option here for anonymous uploads.
So we can enable the ability for
anonymous uploads that would be like an anonymous user writing into the system.
If I leave right enable yes, and then I set a non-upload enable to no,
then that will effectively make it where authenticated users can write but
anonymous users can't.
So we can kind of find that right mixture that makes what we needed.
And notice that upload is talking about files specifically,
make directory is a separate entry.
If I wanna create folders,
you're not really uploading a folder, you're making it there on the server.
So those are a few other things.
The other setting I want to point out is I believe way down here towards the bottom
lets jump down here, and its the listen command and
what we'll find is right here, listen.
Notice how it says when the listen directive is enabled vsftpd runs in
standalone mode And listens on IPv4 sockets.
So right now it's set to no, what does that mean?
Well, it means that vsftpd is running as a service.
So I started it as a service.
And it's going to attach to whatever interfaces the service tells it to.
But if I change this to listen yes, then I can come through and I can start to
specify a listen address which they don't actually show an example of in here.
But it would look like this.
If I changed this to listen yes I can then come in and say,
listen_address= and then I could specify particular IP addresses.
>> Mm-hm. >> And if I have five network adapters,
maybe I only wanna listen on one particular network adapter.
So I could punch it in.
Like that and so now it's going to be tied to that.
Otherwise, if I leave it in the default with this listen no,
it doesn't mean it's not listening.
Obviously I was able to connect to it a moment ago.
It just means that it's going to bond to every adapter and
listen in on every particular resource that's available.
That's another setting that we can kind of manipulate and change right there.
A few different basic configuration changes to get in place but once those
are done, now I've got the server functioning the way I want it to function.
And we should be good to go, right?
So really I guess all I changed here is I turned off anonymous users and
I'm allowing local users to authenticate.
So that's kinda how mine is setup.
Again, yours will be setup however it is that you want it to be.
>> That's awesome.
So when users connect, what data do they see sir.
>> All right so
when a user's gonna connect, well first off I just made some changes.
And I forgot to restart the server.
So let me restart that service again real quick.
I'll do a system ctl restart vsftpd.service.
And so we'll let that restart real quick, there we go.
Anytime you change the config file you need to restart the service so
that'll happen, which means you're kicking users out.
So be aware of that.
There's not really a way to gracefully restart vsftp.
But now if a user connects what are they gonna see?
Well, if they were anonymous users they are gonna see something a little
bit different when they connect.
When a user logs in what they're going to see is the /var/ftp folder.
So /var/ftp, that is considered the home folder for FTP.
And in Inside of that you'll see a folder called Pub.
And that's cuz youre the Public folder.
And so normally, the Public folder will have anonymous access and
then a regular user when they log in they would see Pub but
they would also be able to see their home directory so they can browse them.
An anonymous user wouldnt see users home directories but
a user would and I didn't actually turn on the home directory option,
because FTP's not really secure, so we don't usually wanna use it for that.
But you might've noticed that option when I was in the config file.
Let me go back into the config file, and kinda hunt for it here.
We'll see right here, whether we want it to allow local users to log in.
And see how it says that we have to set that SD Linux option for
FTP home directory that we have to allow that access, that it will actually try and
provide that access to their home directory and give them that.
And a anonymous user wouldn't see that.
Now, I've disabled anonymous users in my system.
So if I were to FTP in right now and authenticate with my user account, right?
I go and log in, I get a successful log in.
And if I do a PWD, see where I'm at?
Slash home slash deposet.
I'm not in slash var, slash FTP.
That's what an anonymous user would see.
An authenticated user will see their home directory.
And here I am in my home directory.
If I had a documents folder or pictures or
whatever I'd see all that stuff right here.
And then I could always switch out into another directory like /var/ftp.
And I'll see it right there.
And there's the pub folder and I have access.
But really because I authenticated with my user account
I have access to whatever I would normally have access to, right?
I can browse into /etc, I can browse all over the file system
>> Mm-hm.
>> And if I have access in the file system, then I have access in FTP as well.
And because it's non-secure, that's where the real risk of this starts to come in,
is if I start pulling files they're being transferred in plain text.
So that's why a lot of people will disable this.
But at this point I am connected and I can see it.
If I was an anonymous user though?
I would just see /var/ftp and what's inside of it.
I would see the pub folder and then the other things inside of it If you've
ever connected to a Internet FTP server, you're probably familiar with that.
You see that pub folder and other things.
So, for example, here, you know what, let me do,
here I will FTP to one of the universities here.
I'll do usf.edu.
So, I'm going to retail to their server,
and I'm going to log in as an anonymous user, all right?
And they usually executed their email address simple password.
What I connect, I can see some folders and there's that prompt folder, right?
And I don't see a hole I'm in there slash var slash ftp.
>> Right.
>> And that I can go in to pub, and
I start to see the things that they've shared out at the end of the resource
Sources like that so that's the way that works and the users get their access.
There are some things that we can kind of manipulate and change that,
but for the most part that's kind of the behavior that we want for FTP.
If you're anonymous you get this particular set of files we're going to
make available, if you're a regular user,
you get the same access you'd have if you were sitting down at the machine.
>> So is there a way after all this to monitor people's access?
>> Yeah and you know if you're allowing users to login,
you probably want to be able to monitor to keep track,
because if somebody starts poking around the file system looking for
stuff they shouldn't be looking for, you want to keep a record of that.
Logging for this is I believe it's turned off by default.
Let's go and check.
I'm going to go back into the configuration file.
So /etc/vsftpd/vsftpd.com.
And in here's a little entry for transfer logs.
It's actually called x for log if I can find it,
I would scroll right past it, right here.
See how it says activate logging of uploads and downloads, x for
log enable equals yes.
I was wrong, it is turned on by default.
The logging is on.
Double check that though because I've seen systems where it is off by default.
You need to turn it on before the users get in otherwise it defeats the purpose.
That'll turn on transfer logging, so
now any time a user accesses a file, it'll get logged.
If they upload something, it'll get logged.
And right down beneath that, it tells us where it's going to store that.
/var/log/extralog.
Right, and so that's where the transfer log is going be stored, and so
we can browse in there.
There's a few other options in here that'll let us tweak the format
of that file.
Because there's a few different ways it can be stored, but
otherwise it's going to log that data in there.
And I doubt I have anything, because I haven't actually transferred anything yet.
But let's take a look at my log file and see if it's got anything in it.
Yeah, it's empty.
I haven't actually transferred any files, right?
But if I start to transfer files, they'll get logged in there and
now I can keep a record of who accessed what and when.
So it's a nice little documented trail right there in /var/log /xferlog.
>> So is this also a way to tell how many users are actually in FTP?
>> You could, yeah, you would actually,
well you won't see somebody if they just logged in or sitting there.
Right? >> Right.
>> If they were just kinda like browsing
through the file systems. >> So they have to be active?
>> Right, in transference, we would know that.
Otherwise, if you want to see how many people are connected, do a netstat.
Netstat -an and it will show every connection that you got.
>> There you go.
>> Port 21.
Remember that FTP actually uses two ports, port 20 and port 21.
You connect on 21 and it does data transfers on 20.
We can just look for how many connections we have on 21, and
that will tell you how many people are connected to the servers.
There are a few different ways to get that data, but
that information is all right out there.
>> So the next step, is there a way to restrict who is in the server?
>> Yeah, yeah, you know so with local users turned on like I've got,
right now anybody, who has a local user could connect.
So if I take a look at /etc/pastwd,
I don't have a bunch of users created do I?
Just D Pazet, of course these are all defaults, but
if I had 50 users, all 50 would be able to use FTP and I might not want that.
So there's a few ways to kind of restrict this.
And so we can go in and kind of change that behavior if we want.
Inside of the configuration file, let me get back to that,
[COUGH] there was an entry In here that referred to a user list.
And let me just find it and that’s not it.
There should be an entry in here that refers to the user list.
And it’s not in here.
All right we'll have to add it.
So there’s an extra entry that we can add.
>> [LAUGH] >> I thought it was in here.
But we can tack on to this.
That lets us manipulate who's allowed to access the system.
And so I'm going to add an entry in here that says user_list equals, and
then in the user list, I'm sorry, it's userlist_enable equals,
and then I can set it to either yes or no, all right.
And I am screwing this one up.
Its user underscore, sorry,
user [LAUGH] user list underscore enable equals yes, there we go.
>> That’s it. >> That’s the setting supposed to be
there, which means I searched for it wrong.
I thought it was in here.
There it is. Way down at the bottom.
>> [LAUGH] Initially you said it was down there.
>> Sorry about that guys.
All the way down at the bottom.
User list enabled equals yes.
So it was already set.
I didn't have to scroll that up.
This setting right here is telling it that we have a file called a user list, and
the user list is dictating who I want to be allowed to access the system.
Well, it's kind of funny, because there's two different settings here.
It can be yes or no.
And if it's set to yes then what's going to happen.
Actually what's going to happen is I'm going to screw the system up,
because I've got two different userlist entries now.
So let me get rid of the one that I added.
So I'll just get rid of that one.
So right now userlist is set to yes.
And what that means is that whenever somebody connects,
it's going to take a look at /etc/vsftpd/user_list,
it's going to take a look at that file.
And if I look at that file, it's not very spectacular, because it should be empty.
And it's not empty, actually.
So when I pull up that user list,
this is a list of users that are not being allowed access.
These are users that are being blocked.
See root, bin, daemon, adm, these are service accounts, right?
Service accounts we don't want to be able to log in.
My user account, D Pezet, is not in this list.
So I'm not being blocked, so this is blocking people from accessing the system.
And notice the two different settings here.
User list deny equals no, or user list deny equals yes, right?
Deny equals yes is the default.
And that means, anybody in this list gets denied, everybody else gets allowed.
So right now, anybody I add to that past WD file is going to be allowed.
If I want the opposite behavior, if I want to block everybody, and
only approve specific people, than I would set userlist_deny to equal no.
And then what would happen is this list would
just be the people I want to allow, right?
So it's a different behavior.
I'm kind of reversing it.
So you need to think about your goal.
Do you want most of your users to be able to log in or
are you setting it up just for you to use?
Maybe I want FTP to run on this server just for me to use.
So I would set userlist_deny to null, and I would change this list to
just have my username in it, just D Pezet and that's it.
And now I would be able to use it, everybody else would be denied.
So that's one way that we can go in and we can kind of restrict this.
It's got two different modes though, and that gets a little confusing.
So there is some risk with this if you mis-configure it,
you could configure it the wrong way and that could kind of mess things up right.
So, there was another file,
you might have noticed this FTP users file right here, okay?
The FTP users file overrides that user list and
you can put people inside of the FTP users file, and
these people will always be blocked regardless of the status of the user list.
One of the user list is enabled or disabled, whether it user list deny is yes
or no, these people always be blocked and if you look Here's the service accounts.
I actually expected user list to be empty because I knew that FTP users is
populated.
So these are people that are expressly not allowed to log in.
So I've kind of got it written down in configuration here.
I don't need the other people in my user list file like I've got.
But this allows us to restrict that access and
make sure, you don't want your root user logging in.
Because their password's gonna be sent in plain text and
that would be really bad, right?
These other people are services.
You don't want services logging in, that doesn't make sense,
they shouldn't do that.
So these are just an increased attack surface.
So let's just block them all right here, and
it stops people from being able to access the system and use those accounts.
So that's another way that we can do that.
One more thing that's worth pointing out here is remember that when I logged in as
myself I had access to the whole file system.
So anything that I had permission to in the file system I had permission
to in FTP.
Well I can actually leverage SE Linux to control what access I have.
And there's a few ways that we can leverage that.
But inside of the VSFTPD configuration file.
If you go in there there's an option in there about CH root.
And let me just find it here.
Here it is, C.H root local user equals yes, C.H root list enabled equals yes.
These different settings right here and what these are doing is saying when
somebody FTPs in we can change their root instead of their root for
the file system being Slash, I could make it where /home/dpezet was my root,
and so when I logged in, that's all I would see.
I wouldn't be able to navigate outside of that file system.
I would just be stuck right there in my home directory.
And so by enabling chroot local user yes,
by taking away that little hash mark, I can do that.
I can tie people just right to that one folder and
now I don't have to worry about them roaming the file system and
worry about checking the transfer logs and all that.
Because they're just tied to their home directory.
So that's another way that we can kind of restrict the file system.
And I said SELinux.
SELinux does play a part in this, but this setting will actually work
even without SELinux, so you don't have to have it.
But if you do SE Linux will actually help to enforce that home directory lock down.
And so they kind of work together.
So it's another neat way that we can kind of restrict things and
get that tied together.
>> Don, does SE Linux interfere with VFSTP?
>> It does, so here it's kind of working together supporting us.
But it will actually interfere with people's access to the rest of the file
system because the VSFTP demon it's only got access to so much stuff right.
For regular users it's not a problem because it's running under the regular
user context but for anonymous users, SE Linux can cause a lot of trouble right?
If you look at slash var slash ftp, if I were to look at
the SE Linux context of that folder, right?
Look at the context for it.
It's public_content_t.
That context right there, okay?
Anonymous users will only be able to access folders
that have the public_content_t context type.
If it doesn't have that SE Linux will block them.
So if I wanna give my anonymous users access to some other folder,
I'll need to change the security context.
And remember we can do that with chcon.
You can say chcon -r to make it recursive.
And then we can point that at a folder.
We can say -t public_content_t to tell it the context type that we wanna change to.
And then after that we just tell it whatever the path is
that we're trying to authorize.
And that's going to allow anonymous users to be able to get into that path as well.
If you're not using anonymous user like I turned it off on mine
then I effectively don't have to worry about SE Linux.
It's not really going to mess with anything that I've got.
But if I'm doing anonymous users it does become a bit of a problem and
that's what we'll have to sort through.
>> Don I've been wanting to ask this question for a while.
Can we use encryption in VFSTP?
>> So yes the short answer is yes right?
>> But.
[LAUGH] >> But we had that question in the chat
room there Stanley was asking does FTP always send the password in the clear.
And the answer is normally yes.
By default FTP is sending everything in plain text including your passwords, and
that's bad.
So in the early days, they tried to come up with a solution for it.
And the solution they came up with was let's stick SSL onto FTP, right.
And so they created FTPS or file transfer protocol/secure software layer.
And FTPS was really just using our web security standards on top of FTP.
And you might have noticed the option as I was scrolling through the config file.
I kind of went fast.
But if we hunt in here wow the option doesn't even show up.
All right so I'm not seeing the option but you can come in here and add.
I'll just go down to the bottom and show you what it would look like.
We can come in here and we can add and
say SSL underscore enable = yes.
And then after that we would follow it up with a series of other commands that would
tell it where to find the certificate file, and whether we require the SSL, and
so on we could specify these other things.
All right and that would create a more secure version of VSFTP.
Now you might ask yourself why is that option not here?
>> Why is this option not here?
[LAUGH] >> And
the short answer is that FTTPS is very uncommon.
It is not supported by many clients.
So if you have clients like Filezilla?
It doesn't have FTPS support.
And Filezilla is probably one of the most popular FTP clients out there.
So, it's not very widely supported and is not very efficient, it's not great.
It's great for web pages, the SSL is great for web pages because it's small content.
With FTP it could be large data sets and it's just not very efficient so
it didn't catch on and it kinda died out so
much to the point that the sample config is not even here in this file right.
So instead FTPS was very rapidly replaced with SFTP.
SFTP is secure file transfer protocol And SFTP is actually using two things.
It uses SSH to build a tunnel, and then it uses FTP to transfer files on top of it.
And really it kind of works inline with another protocol called SCP,
Secure Copy Protocol.
Those both use SSH.
So SSH is taking care of the encryption.
It's very efficient at it and builds a nice secure communication,
does certificate based authentication.
And then you're able to move your file transfer over and it's very secure.
So the short answer is yes we could make VSFPT do encryption but
the long answer is you don't want to do that.
You don't want to do that because it's not widely supported and
you're gonna have a hard time finding clients that can connect to it.
So instead if you wanna do a secure connection, you wanna do SFPT instead.
And we're gonna tackle that in a separate episode, actually the next episode we film
I'll show you how to set up an SFPT server and that's kinda the way of the future.
Now, you might ask yourself- >> [LAUGH]
>> If that's the way of the future,
why did we just waste all this time talking about regular old FTP?
And the answer to that is,
secure file transfer protocol requires a username and a password.
Or a certificate.
So there is no anonymous authentication with SFTP, you can't do that.
If I have files that I want to make available to anonymous users.
If I'm a software company and I want people to be able to download content,
having an anonymous public access FTP server is one of the most efficient and
widely supported ways to do it.
And that's how we see FTP servers used the most today.
Dell has all of their drivers available for download via an FTP site.
Microsoft had all their security patches via an FTP site.
Now they've got it all behind their wall.
But a lot of vendors still do that, they make things
publicly available via an FTP site so you can get them and quickly transfer them.
Secure FTP requires authentication.
That's not good for anonymous connectivity like that.
You could create a shared username and password, but
now other people could attack that.
And find a way to decrypt that data, cuz there's a shared account, right?
So that defeats the whole purpose.
So if we want secure personal communications, SFTP is the way to go.
If we want public anonymous communications,
regular FTP is the way to go.
So that's kind of the deciding factor there, but we'll cover both,
we'll cover FSTP in a follow up episode.
>> That's because Don you're amazing, and you are so very through,
configuring an FTP Server.
Anything else you would like to add?
>> The main thing is once this is up and running you just need to monitor it,
keep track of it and just make sure you pay attention to that user list,
updating permissions and privileges.
After that it pretty much just runs itself.
>> Thanks Don, becoming a Linux server administrator,
there are lots of videos in this series, make sure you watch each and
every episode, you'll be very glad that you did.
And thank you for watching ITProTV, remember a good IT pro is always learning.
I'm Zach Memos.
>> And I'm Don Pezet.
>> And we'll see you soon.
[MUSIC]
>> Thank you for watching ITPro.TV.