Linux Crash Course - Managing Users

Today's video is proudly
sponsored by Linode.

Linode has been doing cloud computing

since 2003,

which is actually before Amazon Web

Services was even a thing.

On Linode's platform, you can get your

server up and running

in minutes, and they include all the

popular distributions,

such as Debian, Fedora, Ubuntu,

and—get this—even Arch Linux. And let's

be honest, what could be better than a

Linux-focused cloud server provider that

lets you tell all of your friends,
"I run Arch"?

Linode has multiple server plans

available to make any app

scalable and flexible. You could use it

to host a blog,

a vpn server, a Minecraft server,

and much more. In fact, Linode is the

platform of choice to host the entire

web presence of LearnLinux TV.

In addition, Linode offers
24/7 365 support

regardless of plan size, so you can get

help from a live person when you need it.

New users can get started right now with

one hundred dollars
towards your new account.

And I highly recommend you check them

out, because Linode is

awesome. And now, let's get started with

today's video.

[Music]

[Music]

Hello again, everyone, and welcome back to

Learn Linux TV.

In today's video, we're going to take a

look at user management in Linux, one of

the most important things that you'll

learn how to do,

because, well, you have to keep track of

your users on your Linux servers,

and that's exactly what I'm going to

show you the basics of in this video.

I'll show you how to add users, how to

remove users,

how to set their password, and some other

stuff as well.

So, let's go ahead and get started.

Alright, so here I am on my PopOS system.

This is my ThinkPad X1 Extreme laptop,

but it doesn't really matter which

distribution you're using or what

computer you have.

There will be some variations here and

there, but for the most part,

when it comes to adding and removing

users, it's the same on each distribution.

Now, if I do run across something that I

think might be different from

one distro to another, I'll be sure to

point it out. Let's go ahead and open up

a terminal and get started.

And here's my terminal, complete with a

ridiculously large font.

I just want to make sure that everyone

is able to see the content

and understand what I'm doing. Let's go

ahead and get started.

Just like with most things when it comes

to Linux, there's more than one way that

we can do just about everything,

and adding users is no exception to that.

Especially in my case, considering I'm

using desktop Linux, I don't even need to

use the command line

at all. However, using the command line is

completely universal.

There's many different desktop

environments, and each one is going to

have a different process for adding users,

but each Linux distribution is going to

have access to the user add command,

which is the command that we'll be using

for the majority of this video.

And when it comes to servers, it's very

common that Linux servers won't have a

desktop environment,

another reason to learn the command line.

Anyway, like I mentioned,

the command that we will use to add a

new user to our system

is the useradd command. And considering

that we'll be making
changes to the system,

we'll either need to be logged in as

root, or we can simply use

sudo in order to run this command with

root privileges,

which is required for any command that's

going to make changes to the server.

And, of course, adding a user is making a

system-wide change,

so of course we're going to need root

privileges, or we could just use sudo if

we have that installed,

and most of you should.
After we type useradd,

we type the name of the user that we

actually want to add to the system,

and that will complete the command.

Before we

actually add a new user, let's take a

look at some foundational concepts

first before we get started on that.

And the first thing that I recommend you

do is understand which users you have on

your system already.

What some people do is they will simply

list the contents of the home directory

because, generally speaking, most users

will have his or her own home directory

underneath slash home,
and you can see mine right here.

So, I have a home directory,

and we can glean from this that my user

Jay is on the system.

Now, you probably already knew that

because, well, you can see my username

right here in the prompt,

so you already knew that at least my

user account existed here,

and here it is. But checking the contents

of the home directory

is not really the best way to find out

how many users,

or which users in particular, you have

already on your server.

I mean, from the output here, you'd

probably assume that my user account is

the only user on the system.

But actually, that's not true. What I want

to do right now

is make sure that you're aware of the

existence of a very special file,

and that's the etc password file.

Password is abbreviated,

that's not a typo, that's actually what

the file is named,

but I'll refer to it as etc password,

which is common in the Linux community,

even though it's abbreviated. So, the cat

command is just going to show me the

contents of that file.

And you can see that the text is wrapped

here, so what I'm going to do

is just lower the font size a bit.

And as you can see, we have quite a few

users on this system, not just mine, we

have many more.

We see my user right here.

And each user is on their own line.

So for example,

if I was to, again, cap the contents of

the etc password file

and then I pipe it into the WC command,

which stands for

word count, and that's a bonus command, it

wasn't even supposed to be part of the

video, but you're welcome.

Anyway, what I'm going to do is add the

dash L option to the word count command.

What that's going to do is give me the

count of how many lines there are. So, as

you can see from the output, there's 44

users on the system,

so definitely a lot more than the one

you saw earlier when I listed the

contents of slash home.

And in this file, every user on the

system has its own line in this file.

The first column shows the name of the

user, and then there's other columns that

follow after that.

I'll go over this file in a little bit

more detail later on,

but at this point in the video, I want to

make sure that you're aware of this file,

that you're aware that it exists,

and that you're aware of what its

purpose is. Its purpose is
to contain a listing

and the options that are associated with

the user accounts on your server.

But either way, it's just a good idea to

know whether or not
the user is on the system

already, and by checking the
contents of this file,

we can determine that. Now, one of the

things I'm going to do

is cap this out again that
I'm going to grep,

so that way, the only line of output that

it's going to produce

is just the one line that contains my

user account.

And what I want to point you to is this

number right here

where it shows 1,000. Now, again, I'll go

over this file in more detail later,

but I think it's a good idea to understand

what this number is.

That number refers to the user ID, a.k.a.

UID. Every user has his or her

own UID. As you can see here, the UID of

my user is 1000.

Most distributions of Linux actually ask

you to create a user account during the

installation process,

and that first user is, well,
pretty much almost

always given the UID of 1000.

I'll talk more about UIDs a bit later,

but that's just another thing that I

wanted you to be aware of.

Anyway, let's go back to the
useradd command.

After all, that's why we're here in the

first place. We want to know how to add

and remove users. And the
useradd command,

as the name would imply, is the command

that we would use

to add a user to the system. I'm logged

in as Jay,

so I can't really use this command, like

I mentioned earlier, without sudo,

or just logging in as root, so I'm going

to add sudo to the command,

and then at the end, I'm going to give it

the name of a user I want to create.

So I'm going to tell it to create a user

with the name of foxmulder.

So for all of you X-Files fans out there,

yes, that was an easter egg. And the

X-Files was

actually my favorite sci-fi series

growing up. I loved watching that every

Sunday night.

Great times. Anyway, what I'm going to do

right now is press

enter, and now it's asking
me for my password,

my user password, to verify that I have

access to the sudo command.

And it didn't say anything, but it also

doesn't appear to have failed, either.

So if I cap the contents of etc

password again,

let's see what happens. And as you can

see, the very last

line in this file shows that
that user was created.

Now, if you recall, the UID for my user

was UID 100.

For foxmulder, that user got UID 1001.

Now, something to keep in mind is

that when you add a user
to a Linux system,

it's going to assign the next available

UID to that user.

Now, my user already had
assigned the UID of 1000,

so that UID is no longer available. When I

created the account foxmulder,

it just incremented it by one. 1001,

that's the UID that it was provided, as

you can see here.

Now, you'll notice from the output that

there's some UIDs here that are much

lower than 1000.
For example, 122, 121, and so on.

On most distributions of Linux, normal

user accounts,

basically, user accounts that are

associated with interactive logins, or

basically user IDs that are going to be

used by a human,

those are given UIDs 1000 and above.

UIDs below 1000 are considered
system accounts.

And I'll talk a little bit more about

system accounts in a few minutes, but I

just wanted you to be aware of that

distinction. We have

user accounts, we also have
system user accounts.

And the useradd command by default adds

normal user accounts.

Now, I added a user for foxmulder. We did

that with the previous command that we

entered. Let's also list the contents of

the home directory

and see whether or not that user has a

home directory underneath slash home.

And it doesn't. Why is that?

Now, depending on your distribution,
it might

have actually created a home directory for

that user. On my end,

it didn't. This is one thing that

actually does differ

from one distribution to another. Each

distribution is going to set their own

defaults for the useradd command.

So on your end, it might have created a

home directory. On my end, well,

I wasn't so fortunate. So, let's take a

quick detour here,

and what I'm going to do is point you to

another file,

and that file is the
etc default useradd file.

Now, I'm not going to go over this

particular file in too much detail,

but basically, what it does is sets the

defaults for useradd

Each distribution is free to supply

their own version

of this particular file, so as you can

see here, we have

SHELL=/bin/sh.

If you want to use a different default

shell, then you'll change it right here.

But basically, this file just sets the

defaults. And again,

it's going to be different from one

distribution to another,

and it's entirely possible that on your

distribution, you may not even have this

file at all.

Now, all I want at this point is for you

to be aware that this file exists.

What you might think that I'm going to

recommend is that you customize this

file with the defaults that you prefer,

but I'm not going to do that. Instead, I

recommend that you be explicit.

Say what you mean, and mean what you say.

So even if your distribution did create

a home directory here,

I still recommend that you tell the

useradd command

specifically that you want a home

directory. Now, on your end,

that might be redundant. If it already

created a home directory for the user

that you created,

then why should you bother and add a

redundant option to tell it to create a

home directory when it already did?

Now, it's a good idea to
basically be explicit

when it comes to Linux.
Include all the options.

That's especially true when you're

writing scripts, because you want your

scripts to be portable.

Maybe you have a script that you want to

run on multiple distributions.

If that's the case, you'll probably want

the same output every time
that script runs.

So, if you are using the useradd command

as part of a script,

you'll probably want to add all the

appropriate options to ensure

that all the user accounts that you

create are always created the same way.

And I recommend that you be explicit, not

just when you're creating scripts,

but basically just get in the habit of

always doing that.

So what I want to do is re-add the user,

but I want to add the user with a home

directory this time.

But that requires another detour, because

the user already exists.

I could create another user, but what I'm

going to do instead is take this

opportunity to show you how to remove a

user account.

So, to remove a user account, you can use

the userdel command,

the user delete command,
however you want

to say it.

We'll need to use sudo, and then we give

it the name of the user
that we want to delete.

But be very careful here. When you run a

command like this on a Linux system, the

Linux system is going to
make the assumption

that you know what you're doing, so just

make sure that you're
typing the username

that's actually the user you want to

delete. Just be very careful.

So, we created a user earlier
named foxmulder.

I'm going to delete that user account.

Maybe Mulder got abducted by aliens or

something, I don't know,

but we're going to remove them from the

system. And that's it.

Now, that user didn't even have a home

directory to begin with,

but the thing is, though, if that user did

have a home directory,

they would probably still have a home

directory here because of the

user delete command.

That doesn't delete the home directory

for the user when you delete a
user, by default.

Just keep that in mind. We'll return to

that in a few minutes. But anyway...

We can see here that that particular

user account is gone.

So let's go ahead and add that user back

to the system,

and at the same time, make sure that a

home directory is also
created for that user

when we create the user itself.

And this is the command right here that

we used earlier, so what I'm going to do

is add the dash m option.

I'll press enter.

No output, just like last time,
but the difference,

at least in my case, is that the user

actually has a home directory right now.

We see that right here.

The line is wrapped a bit, you get the

idea. That user does indeed have a home

directory. We added the dash m option,

which is what you see here, that

specifically tells useradd that we want

a home directory

when we create this user.

So, let's talk about removing the user

again, but this time,

also removing the home directory as well.

And again, we see that user does indeed

have a home directory.

And earlier, when we removed this account

the first time...

...this is the command that we used right

here. So, to remove a home directory,

we add the dash r option to this command.

That's going to, like I mentioned,

remove the user account, and also their

home directory.

Now, before I actually press enter here,

I do want to mention that

before you start removing a home

directory for a user,

for example, if you are working at a

company, you'll want to make sure that

you should remove their home directory

before you actually do it.

For example, if an employee
leaves the company,

that employee's supervisor might need

access to their files in order to finish

any projects that they might have been

working on.

But if you delete their files, well, they

can't do that.

Perhaps more importantly, a lot of

companies out there,

they have requirements for how long to

retain their employees' data,

and if you're actually working in a

company, it's extremely

important that you ask HR, or whoever it

is you ask there,

what the retention policy is for

employee data.

You'll want to make sure that you are in

compliance with any
policies that might exist.

Maybe a company might have a policy

where they have to retain

user records for a few years. If you

delete a user account with their home

directory, then you are not in compliance.

Now, if your company does not have a

policy when it comes to user data

retention, or data retention in general,

it's actually one of those things that

should definitely be drafted.

Let somebody know. Anyway, I'm going to

press enter.

We can ignore this message right here

about the mail spool.

That's beyond the scope of this video.

That is a normal message, though, so

nothing to be concerned with.

We can check the contents of the home

directory again, and that home directory

is in fact gone.

Another thing that I want to show you

guys is how to set a password for a user,

because when we added
the foxmulder user, it

didn't even ask us what we wanted the

password to be for that user.

In fact, the user had no password at all.

Now, what I'm going to do

is just add the user back to the system.

I'm going to add it with
the home directory,

so nothing different.

I'll just press enter.

User has a home directory, and the user

is on the system.

So, let's take a look at how we set a

password for the user.

And to set a password for a user, or even

change our own password, for that matter,

we have a dedicated command,

the passwd command.

Now, if I entered this
by itself right now,

it's going to assume that I want to

change the password for the user

that I'm currently logged in with. So if

you had a user, for example, that came to

you and said

"How do I change my password?", you would

ask them to run the passwd command.

You don't even need to get involved,

they can change their own password.

There's nothing for you as the

administrator to do in this regard,

other than to know that the passwd

command exists.

And I'm going to actually use it right

now. I'm going to make it
fail on purpose, though,

and the reason why is because I don't

want to change my password right now.

But the first thing that it does is it

asks you for your current password,

which I've entered, and then it asks you

for your new password. What do you want

your new password to be...?

...which I've entered.
And then you enter it again.

And it's telling me that the passwords

don't match, and that was intentional.

If the passwords did match, then the

password I chose right then and there

would become my password.

So that's how you change the password

for the user that you're logged in with.

But actually, I brought that up in

regards to setting a password for

another user.

So, for example, if you have someone

that's going to start logging into your

Linux server,

you can set a temporary password for

them and then ask them to change it.

In a future video, we'll be going over

password expiration,

but we're going to omit that right now

just to keep things simple.

So, to change a password for another user,

you can type sudo,

because in order to change a password

for another user, you do need root

privileges, or

at least access to sudo in order to be

able to do that.

Then, you can run passwd, and then the

name of the user that you want to change

the password for,

or in this case, you want to set the

password. So I'll type the name of the

user right here.

Now, notice that it didn't ask me for the

user's current password.

You might think that the reason why it

didn't ask me was because the user

didn't even have a password. We didn't

even set a password.

But if you have access to sudo or the

root user, it's never going to ask you

for the user's current password.

I mean, root is pretty much like God mode,

if you've ever played Doom, for example.

It's the all-powerful account
that can do basically

everything, so root doesn't need to know

the password of the user

to change or set the password.

So even if the user

already had a password, it doesn't care.

You're setting the password,

and anyone that has access to root has

permission to set a password
for another user.

So I'm going to type it in right now.

And again.

And it said password updated successfully.

So, I was able to add a password for the

foxmulder user.

Now, let's go ahead and see an example of

creating a system user.

A system user is very useful when you

are doing any kind of automation.

For example, maybe you have an

accounting department

and you need to run a financial report

for them every week.

That sounds tedious to me, and to be

honest with you,

doing a financial report, that doesn't

really excite me. And if you're like me,

you'll probably want to automate that

report so you'll never be
bothered to do it.

But if you're going to automate something,

like a process or some sort of task,

then it makes sense to not use your user

account for it.,

create a system user. And actually, you

can use a system user with Cron

to run a scheduled job, which is the best

way to do it.

Now, I'll be covering Cron in a future

video in this series.

Go ahead and check the playlist to see

if it's already there, but for now,

just keep in mind that system users are

useful when you want something to run in

the background,

and it's not something that's associated

to any one person.

So let's go ahead and add a system user

right now.

So again, it's sudo and then useradd,

and we're going to use dash r,

and that dash r option

actually allows us to designate

that we want to create a
system user specifically,

not a normal user. And what I'm going to

do is call the system user sysuser.

Just like that. I'll press enter,

and what I'm going to do is cap the

contents of etc password again,

and I'm going to grep for sysuser,

because I only want to see that one line.

And we see it right here.

Now, notice that the UID

is 998. It doesn't start with 1000.

Earlier, when we created a user, that user

was assigned UID

1001, but this user was

actually assigned a UID

of less than 1000, and that's

generally the case.

Normal user accounts will be provided a

UID of 1000 or greater,

and then system users will generally be

provided a UID

of less than 1000. And that

distinction doesn't really matter

so much, other than you can deduce that a

user is most likely a system user based

on the UID.

In my case, I'm using a desktop

distribution of Linux,

and most of the time, desktop

distributions will not show a system

user on the login screen.

Now, that does vary from one distribution

to another,

but generally speaking, most

distributions will not show UIDs on

the login screen

that are under 1000. That's important

because if it did show UIDs that are

under 1000, then in my case,

there would be probably around 44

user accounts shown on the login screen,

and that's very messy. But anyway,

at this point, I just want you to be

aware of the dash r option,

and just keep in mind that that

allows you to create a system user,

and a system user, again, is a user that

generally doesn't log

in interactively, and is used for things

that are going to run in the background,

schedule tasks, processes,
things like that.

Now, that actually completes the main

part of this video. The whole goal was to

show you the basics of user management,

and I've already showed you how to add a

user, how to remove a user

and some options with the useradd

command. Now, of course,
you could just type

man and then useradd, and then you get a

bunch of options here

as far as some of the additional things

that you can do with that command.

But as far as the basics are concerned,

which was the actual purpose of this

entire video, we're covered there. But I'm

not going to end the video

just yet. There's one more thing that I

want to show you guys.

And as I promised earlier in the video,

I told you that I would go over the

contents of the etc password file to

help you guys understand it better.

Let's go ahead and do that right now.

Now, as you recall,

the etc password file, that contains a

listing of all the users on the system.

There's quite a few lines there, so what

I'm going to do is
lower the font size a bit,

just to make sure you can see everything.

Hopefully that's not too small.

We have several different columns on

each line, and each column is separated

by a colon.

Now, the first column is the username.

No surprise there.

The second column, which is this one

right here,

that just refers to the password,

actually, it's a little bit more

complicated than that,

but it essentially means that we have an

encrypted password in use here.

And nowadays,
we don't really use any other

kind of password. We always use hashed

passwords, which is what this refers to.

It just means that the password for this

user is hashed,

it's not shown here. In some ways, that's

a carryover from the olden days, which is

why I'm not going to go into too much

detail on that,

but you'll probably almost, if not always,

see an X

in that field. Continuing, we have the UID

right here, as I talked about earlier.

The next field is the group ID.

I've already explained what a UID is

earlier in the video,

and a GID, or group ID,

is essentially the same thing

but for groups. I'll be covering groups

in a separate video,

so don't worry about that right now.

This field here,

that is the user information field, and

you might see that referred to as the

gecos field,

G-E-C-O-S, so it looks like that.

But I like to refer to it as the user

information field,

and it's most commonly used for the

first and last name, as you see here.

That user information field is

completely optional. It's perfectly fine

to go ahead and skip it, and you'll

actually see it skipped

in other user accounts and other lines.

You'll see, like, two colons together,

that just means that that information

isn't there, it's blank.

Continuing on, we have the home directory

for the user. In my case,

slash home slash j,

that's where my home directory is.

So, it's essentially telling the Linux

system where to find the home directory

for that user.

The last column here,

that refers to the shell

that is designated for that user. When a

user logs in, their shell is activated.

In my case, slash bin slash bash,

that's the shell

that I'm going to be using when I log in.

So, for example, if I type

echo then dollar sign and then shell in

all caps,

you can see that my shell is

slash bin slash bash,

and that was set right here. And again,

this is the shell that's going to start

up as soon as I log in.

Now, you will see other things here

instead of slash bin slash

sh or bin bash.

For example, user s bin no login.

And you'll see other variations of this

as well. User s bin no login means, well,

that user is not going to be able to log

in. And when it comes to system users,

we really don't want them to log in.

And generally speaking,

system users are not associated to a

human being,

so there's no reason for them to

interactively log in, and they don't have

to log in

in order to run reports, run command,

scripts, or anything like that.

Often, people will use system accounts to

automate things, like I mentioned earlier,

and that's essentially all this is.

User s bin no login

means, basically, what it says. When that

user tries to log in, even if you did set

a password for that user,

they'll be denied. It's going to attempt

to run user s bin no login,

which is basically going to
deny the login.

Now, let's go ahead and take a look at

the etc shadow file.

Now, real quick...

...you'll recall that I mentioned that we

have an X right here for most, if not all

the users,

and that X refers to the fact that that

user has a hashed password.

It's almost always going to be the case.

We really don't want to store the user's

password in plain text in the

etc password file,

we would rather hash it and store it

somewhere else.

So, if we take a look at the
etc shadow file...

Now, as an aside, you will need sudo in

order to view this file, unlike the etc

password file.

As you can see, I was able to run cat

etc password with no sudo at all,

but I can't get away with that when it

comes to etc shadow.

So, I will add sudo.

Now, just like with the etc password file,

with the etc shadow file, we have a

bunch of different columns on each line,

and each column is separated
by a single colon.

On the left, we have the username.

And that's the username right here.

And to make it a little bit easier,

I'm going to grep for my user account here

just to get it down to one line. Makes it

a little bit easier. But in the first

column, again, we have the username.

In the second column, which is actually

ridiculously long,

we have the actual hash for the password.

Now, this isn't my actual password,

it's just a hash of my password.

That's an important distinction.

So, moving on, we have this field
right here,

and that number refers to the number of

days since the Unix epoch that the

password was last changed.

For those that aren't already aware, the

Unix epoch is January 1st

of 1970. Therefore, we could read that

column as a password
having last been changed

that many days after the Unix epoch.

So in this case, 18,807 days.

The fourth column tells us how many days

are required to pass

before the user will be able to change

their password again. In this example,

the user can change their password,
well, anytime,

and they can do that because the number

of days is set to zero.

Zero means any time.

This column right here refers to how

many days until a password change is

required. In this case 99,999 days

since the unix epoch will pass
until I'm required

to change my password. So, I guess it may

as well be infinite.

In a future video, we'll explore user

password expiration,

so don't worry about that too much right

now. So here we have number seven,

and this field refers to how many days

until the user will be reminded to

change their password.

So, in this case, if the user's password

is going to expire within seven days,

it's going to show them a message on the

shell. But, well, I mean,

there's quite a few days

until this password is going to expire,

so even though it shows 7, I'm probably

never going to see that message.

Now, here we have several columns
that are not

set at all. So, the next field would have

showed us how many days

until the user password is going to be

locked. I never actually set a time for

the password to be locked,
so that's not set.

We also have a field that would normally

show us how many days until the account

is disabled,

but that's not set either. Now, I went

over the last fields here fairly quickly,

and that's because you really don't need

to memorize that. I mean, you can

if you want to, but we have a dedicated

command that we would use

to lock a user account, to set a password

expiration and things like that,

and more importantly,

a dedicated command we can use to check

that information

without having to remember those fields,

so I wouldn't worry about it too much.

We'll get to that when we cover password

expiration in a future video.

So, there you go. There's actually

additional concepts that we could have

gone over in this video when it comes to

user management,

but I decided to save those for future

videos. Again,

check the playlist for this series,

because other videos on user management

might already exist, and if they don't, I

will create those for you very soon.

Make sure you subscribe so you'll be the

first to see those videos as soon as

they're out.

Regardless, thank you so much for

watching. I really appreciate it,

and I'll see you next time.

[Music]