When it comes to a server, users are very important—without users to serve, then there’s no real need for a server in the first place. The subject of user management itself within the world of IT is in and of itself quite vast. Entire books have been written on individual methods of authentication, and entire technologies (such as Lightweight Directory Access Protocol, or LDAP) exist around it. In this chapter, we’ll look at managing users that exist locally on our server, and the groups that help define what they are able to do.

Since Ubuntu Server is a distribution of Linux, it adopts the Unix style of managing user accounts, groups, and permissions. Although our focus is on Ubuntu, many of the same commands around user management that you’ll learn in this chapter will apply to other platforms as well. There are commands that allow you to add, remove, and change users, as well as commands that allow you to alter permissions.

Users in the context of a server refer to who (or what) is able to use the server. For example, you may have an accountant named Susan, or an IT administrator named Haneef, who both need to access the server. Perhaps Susan only needs access to a file share directory for accounting-related files, and Haneef might have more access to the server as a system administrator. The user accounts we create on our server will represent the actual people that will use it.

Groups allow us to segregate access to specific files and directories. As we’ll learn later, files and directories have user and group assignments. When combined with permissions, we’ll be able to manage what our users are able to do with our server.

Users aren’t always people, though. We also have system users on our server that applications and running processes might use for background or automated tasks. An example of this might be a backup job, and you may have a backup user that runs a task in the background to facilitate some sort of file copy task that copies important files to another place. You don’t have to worry about system-related users for now, just know that they exist. You’ll see more examples of this as we go through the book.

More advanced organizations may have a central login server, such as Active Directory (AD) or standard LDAP. There are others aside from those, as well. In this book, we won’t cover those technologies, but just keep in mind that central authentication servers are a possibility for your organization, should you choose to explore them.

The most powerful user of all, though, is root. This special user gives us the most control, but as you’ll see in the next section, that comes with risks.

In the last chapter, we set up our very own Ubuntu Server installation. During the installation process, we were instructed to create a user account to act as a system administrator. So, at this point, we should have at least two users on our server. We have the aforementioned administrative user, as well as root. We can certainly create additional user accounts with varying levels of access (and we will do so in this chapter), but before we get to that, some discussion is in order regarding the administrator account you created, as well as the root user that was created for you.

The root user account exists on all Linux distributions and is the most powerful user account on the planet. The root user account can be used to do anything within your server, and I do mean anything. Want to create files and directories virtually anywhere on the filesystem? Want to install software? These processes are easily performed with root. The root account can even be used to destroy your entire installation with one typo or ill-conceived command: if you instruct root to delete all the files on your entire hard disk, it won’t hesitate to do so. It’s always assumed on a Linux system that if you are using root, you are doing so because you know what you are doing. So, there’s often not so much as a confirmation prompt while executing any command as root. It will simply do as instructed, for better or worse.

It’s for this reason that every Linux distribution I’ve ever used has stated, or at least highly recommended, that you create a standard user during the installation process. It’s generally recommended in the Linux community for an administrator to have their own account and then switch to root whenever a task comes up that requires root privileges to complete. This approach is less likely to destroy your server with an accidental typo or bad command. Some administrators will strictly use root at all times without any issue, but again, it’s recommended to use root only when you have to.

Most distributions ask you to create a root password during installation in order to protect that account. Even Debian (on which Ubuntu is based) has you set a root password during installation. Ubuntu just decides to do things a little bit differently. The reason for this is that, unlike many other distributions, Ubuntu defaults to locking out the root account altogether. There’s nothing stopping you from enabling root, or switching to the root user after you log in. Being disabled by default just means the root account isn’t as easily accessible as it normally would be. I’ll cover how to enable this account later in this chapter, should you feel the need to do so.

An exception to this rule is that some VPS providers, such as Linode, will enable the root account even on their Ubuntu servers. Sometimes, the root password will be randomly generated and emailed to you. However, you should still create a user for yourself with administrative access regardless.

Instead of using root outright, Ubuntu (as well as its server version) recommends the use of sudo. Specifically, sudo enables you to run individual commands with elevated privileges instead of being logged in as root all the time.

Using sudo to run privileged commands

I’ll go over how to manage sudo later on in this chapter, but for now, just keep in mind that the purpose of sudo is to enable you to use your user account to do things that normally only root would be able to do. For example, as a normal user, you cannot issue a command such as the following to install a software package (don’t worry about the apt command for now, as we’ll cover that in Chapter 3, Managing Software Packages):

apt install tmux

Instead, you’ll receive an error:

E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

But if you prefix the command with sudo (assuming your user account has access to it), the command will work just fine:

sudo apt install tmux

When you use sudo, you’ll be asked for your user’s password for confirmation, and then the command will execute. Subsequent commands prefixed with sudo may not prompt for your password, as it will cache your password for a short period of time until it times out or the terminal is closed. Understanding this should clarify the usefulness of the user account you created during installation. I referred to this user as an administrative account earlier, but it’s really just a user account that is able to utilize sudo. Ubuntu Server automatically gives the first user account you create during installation access to sudo.

The intent is that you’ll use that account to administer the system, rather than root. When you create additional user accounts, they will not have access to sudo by default, unless you explicitly grant it to them.

Creating users in Ubuntu can be done with one of two commands: adduser and useradd. This can be a little confusing at first, because both of these commands do the same thing (in different ways) and are named very similarly. I’ll go over the useradd command first and then I’ll explain how adduser differs. You may even prefer the latter, but we’ll get to that in a moment.

Using useradd

First, here’s an example of the useradd command in action:

sudo useradd -d /home/jdoe -m jdoe

With this command, I created a user named jdoe. With the -d option, I’m clarifying that I would like a home directory created for this user, and following that, I called out /home/jdoe as the user’s home directory. The -m flag tells the system that I would like the home directory to be created during the process; otherwise, I would’ve had to create the directory myself. Finally, I called out the username for my new user (in this case, jdoe).

As we go along in this book, there will be commands that require root privileges in order to execute. The preceding command was an example of this. For commands that require such permissions, I’ll prefix the commands with sudo. When you see these, it just means that root privileges are required to run the command. For these, you can also log in as root (if root is enabled) or switch to root to execute these commands as well. However, as I mentioned before, using sudo instead of using the root account is strongly encouraged.

Now, list the storage of /home using the following command:

ls -l /home

You should see a folder listed there for our new user:

Figure 2.1: Listing the contents of /home after our first user was created

What about creating our user’s password? We may have been asked for our current user’s password due to using sudo, but we weren’t asked for a password for the new user. To create a password for the user, we can use the passwd command. The passwd command defaults to allowing you to change the password for the user you’re currently logged in as, but it also allows you to set a password for any other user if you run it as root or with sudo. If you enter passwd by itself, the command will first ask you for your current password, then your new password, and then it will ask you to confirm your new password again. If you prefix the command with sudo and then specify a different user account, you can set the password for any user you wish. An example of the output of this process is as follows:

Figure 2.2: Changing the password of a user

As you can see in the previous screenshot, you won’t see any asterisks or any kind of output when you type a password using the passwd command. This is normal. Although you won’t see any visual indication of input, your input is being recognized.

Now we have a new user and we were able to set a password for that user. The jdoe user will now be able to access the system with the password we’ve chosen. This user won’t have access to sudo by default, but we’ll cover how to change this later on in the chapter.

Using adduser

Earlier, I mentioned the adduser command as another way of creating a user. The difference (and convenience) of this command should become apparent immediately once you’ve used it. Go ahead and give it a try; execute adduser along with a username for a user you wish to create. An example run of this process is as follows:

Figure 2.3: Creating a user with the adduser command

In the preceding process, I executed sudo adduser dscully (commands that modify users require sudo or root) and then I was asked a series of questions regarding how I wanted the user to be created. I was asked for the password (twice), Full Name, Room Number, Work Phone, and Home Phone. In the Other field, I entered the comment Trust no one, which is a great mindset to adopt while managing users. The latter prompts prior to the final confirmation were all optional: I didn’t have to enter Full Name, Room Number, and so on. I could’ve pressed Enter to skip those prompts if I wanted to. The only things that are really required are the username and the password.

From the output, we can see that the adduser command performed quite a bit of work for us. The command defaulted to using /home/dscully as the home directory for the user, the account was given the next available User ID (UID) and Group ID (GID) of 1002, and it also copied files from /etc/skel into our new user’s home directory. In fact, both the adduser and useradd commands copy files from /etc/skel, but adduser is more verbose regarding the actions it performs.

Don’t worry if you don’t understand what UID, GID, and /etc/skel are yet. We’ll work through those concepts soon.

In a nutshell, the adduser command is much more convenient in the sense that it prompts you for various options while it creates the user without requiring that you memorize command-line options. It also gives you detailed information about what it has done. At this point, you may be wondering why someone would want to use useradd at all, considering how much more convenient adduser seems to be. Unfortunately, adduser is not available on all distributions of Linux. It’s best to familiarize yourself with useradd in case you find yourself on a Linux system that’s not Ubuntu.

It may be interesting for you to see what exactly the adduser command is. It’s not even a binary program—it’s a shell script. A shell script is simply a text file that can be executed as a program. You don’t have to worry too much about scripting now, as we will cover it in Chapter 6, Boosting Your Command-line Efficiency. In the case of adduser, it’s a script written in Perl, which is a programming language that is sometimes used for administrative tasks. Since it’s not binary, you can even open it in a text editor in order to view all the code that it executes behind the scenes. However, make sure you don’t open the file in a text editor with root privileges, to ensure that you don’t accidentally save changes to the file and break the script. The following command will open adduser in a text editor on an Ubuntu Server system:

nano /usr/sbin/adduser

Use your up/down arrows as well as the Page Up and Page Down keys to scroll through the file. When you’re finished, press Ctrl + x on your keyboard to exit the text editor. If the editor prompts you to save changes, don’t do so. Anyway, those of you with keen eyes will likely notice that the adduser script is calling useradd to perform its actual work. So either way, you’re either directly or indirectly using useradd.

Now that we know how to create users, it will be useful to understand how to remove them as well.

Removing users

Removing or disabling an account is very important when a user no longer needs to access a system, as unmanaged accounts often become a security risk. To remove a user account, we’ll use the userdel command.

Before removing an account, though, there is one very important question you should ask yourself. Will you (or another person) need access to the user’s files? Most companies have retention policies in place that detail what should happen to a user’s data when they leave the organization. Sometimes, these files are copied into an archive for long-term storage. Often, a manager, coworker, or new hire will need access to the former user’s files, perhaps to continue working on a project where they left off. It’s important to understand this policy ahead of managing users. If you don’t have a policy in place that outlines retention requirements for files when users resign, you should probably work with your management team and create one.

By default, the userdel command does not remove the contents of the user’s home directory. Here, we use the following command to remove dscully from the system:

sudo userdel dscully

We can see that the files for the dscully user still exist by entering the following command:

ls -l /home

The preceding commands will result in the following outputs:

Figure 2.4: The home directory for the user dscully still exists, even though we removed the user

With the /home directory for dscully still existing, we’re able to move the contents of this directory anywhere we would like to. If we had a directory called /store/file_archive, for example, we could easily move the files there:

sudo mv /home/dscully /store/file_archive

Of course, it’s up to you to create the directory where your long-term storage will ultimately be, but you get the idea.

If you weren’t already aware, you can create a new directory with the mkdir command. You can create a directory within any other directory that your logged-in user has access to. The following command will create the file_archive directory I mentioned in the preceding example:

sudo mkdir -p /store/file_archive

The -p flag simply creates the parent directory if it didn’t already exist.

If you do actually want to remove a user’s home directory at the same time that you remove an account, just add the -r option. This will eliminate the user and their data in one shot:

sudo userdel -r dscully

To remove the /home directory for the user after the account was already removed (if you didn’t use the -r parameter the first time), use the rm -r command to get rid of it, as you would any other directory:

sudo rm -r /home/dscully

It probably goes without saying, but the rm command can be extremely dangerous. If you’re logged in as root or using sudo while using rm, you can easily destroy your entire installed system if you’re not careful. DO NOT run this command, but as a hypothetical example, the following command (while seemingly innocent at first glance) will likely completely destroy your entire filesystem:

sudo rm -r / home/dscully

Notice the typo: I accidentally typed a space after the first forward slash. I literally accidentally told my system to remove the contents of the entire filesystem. If that command were executed, the server probably wouldn’t even boot the next time we attempted to start it. All user and program data would be wiped out. If there was ever any single reason for us to be protective over the root account, the rm command is most certainly it!

At this point, we understand how to add and remove users. In the next section, we’ll look deeper into passwords.

Now that we know how to create (and delete) user accounts on our server, we are well on our way to being able to manage our users. But where exactly is this information stored? We know that users store their personal files in /home, but is there some kind of database somewhere that keeps track of which user accounts are on our system? Actually, user account information is stored in two special text files:

• /etc/passwd
• /etc/shadow

You can display the contents of each of those two files with the following commands. Note that any user can look at the contents of /etc/passwd, while only root has access to /etc/shadow:

cat /etc/passwd 
sudo cat /etc/shadow

Go ahead and take a look at these two files (just don’t make any changes), and I will help you understand them.

Understanding the /etc/passwd file

First, let’s go over the /etc/passwd file. What follows is some example output from this file on my test server. For brevity, I have limited the output to the last eight lines:

Figure 2.5: Example /etc/passwd file

Each line within this file corresponds to a user account on the system. Entries are split into columns, separated by a colon (:). The username is in the first column, so you can see that I’ve created users jay and jdoe. The next column on each is simply an x. I’ll go over what that means a bit later. For now, let’s skip to the third and fourth columns, which reference the UID and GID respectively.

On a Linux system, user accounts and groups are actually referenced by their IDs. While it’s easier for you and I to manage users by their names, usernames and group names are nothing more than a label placed on the UID and GID in order to help us identify them more easily.

For example, it may be frustrating to try to remember that jdoe is UID 1001 on our server each time we want to manage this account. Managing it by referring to the account as jdoe is easier for humans, since we don’t remember numbers as well as we do names. But to Linux, each time we reference user jdoe, we’re actually just referencing UID 1001. When a user is created, the system (by default) automatically assigns the next available UID to the account. If you manage multiple Ubuntu servers, note that the UIDs will not match from one system to another, so keep in mind that UIDs don’t synchronize between installations.

In my case (as shown in Figure 2.5), the UID of each user is the same as their GID. This is just a coincidence on my system and it isn’t always that way in practice. While I’ll discuss creating groups later in this chapter, understand that creating groups works in a similar way to creating users, in the sense that the group is assigned the next available GID in much the same way as new user accounts are assigned the next available UID. When you create a user, the user’s primary group is the same as their username (unless you request otherwise). For example, when I created jdoe, the system also automatically created a jdoe group as well.

This is what you’re actually seeing here—the UID for the user, as well as the GID for the user’s primary group. Again, we’ll get to groups in more detail later.

You probably also noticed that the /etc/passwd file on your system contains entries for many more users than the ones we’ve created ourselves. This is perfectly normal, as Linux uses user accounts for various processes and services that run in the background. You’ll likely never interact with the default accounts at all, though you may someday create your own system user for a process to run as. For example, perhaps you’ll create a data processor account for an automated data-processing script to run under.

Anyway, back to our /etc/passwd file. The fifth column is designated for user info, most commonly the user’s first and last names. In my example, the fifth field is blank for jdoe, as I created jdoe with the useradd command, which didn’t prompt me for the first and last names. This field is also nicknamed the GECOS field, and you may see it referred to as such when you read the documentation.

In the sixth column, the home directory for each user is shown. In the case of jdoe, it’s set as /home/jdoe. Finally, we designate the user’s shell as /bin/bash. This field refers to the default shell the user will use, which defaults to /bin/bash when an account is created with the adduser command, and /bin/sh when created with the useradd command. (If you have no preference, /bin/bash is the best choice for most.) If we want the user to use a different shell, we can clarify that here (though shells other than /bin/bash aren’t covered in this book). If we wanted, we could change the user’s shell to something invalid to prevent them from logging in at all. This is useful for when a security issue requires us to disable an account quickly.

Understanding the /etc/shadow file

With that out of the way, let’s take a look at the /etc/shadow file. We can use cat to display the contents like any other text file, but unlike /etc/passwd, we need root privileges in order to view it. So, go ahead and display the contents of this file, and I’ll walk you through it:

sudo cat /etc/shadow

This will display the following output:

Figure 2.6: Example /etc/shadow file

The preceding screenshot, Figure 2.6, shows the last four lines of this file on my server. First, we have the username in the first column—no surprises there. Note that the output is not showing the UID for each user in this file. The system knows which username matches which UID based on the /etc/passwd file, so there’s no need to repeat that here. In the second column, we have what appears to be gobbledygook. Actually, that’s the most important part of this entire file. That’s the actual hash for the user’s password.

A password hash is a conversion of the actual password to a different string that represents the original password. This is a one-way conversion, so you cannot find the actual password by reverse-engineering the hash. In the /etc/passwd file, the hash of the password is stored rather than the actual password, for security purposes.

If you recall, in the /etc/passwd file, each user listing had an x for the second column, and I mentioned I would explain that later. What the x refers to is the fact that the user’s password is encrypted and simply not stored in /etc/passwd and is instead stored in /etc/shadow. After all, the /etc/passwd file is viewable by everyone, so it would compromise security quite a bit if anyone could just open up the file and see what everyone’s passwords were.

In the days of old, you could actually store a user’s password in /etc/passwd, but it’s never done that way anymore. Whenever you create a user account on a modern Linux system, the user’s password is encrypted (an x is placed in the second column of /etc/passwd for the user), and the actual password hash is stored in the second column of /etc/shadow to keep it away from prying eyes. Hopefully, now the relationship between these two files has become apparent.

Remember earlier I mentioned that the root user account is locked out by default? Well, let’s actually see that in action. Execute the following command to see the root user account entry in /etc/shadow:

sudo cat /etc/shadow | grep root

On my system, I get the following output:

Figure 2.7: Example /etc/shadow file

You should notice right away that the root user account doesn’t have a password hash at all. Instead, there’s an asterisk where the password hash would’ve been. In practice, placing an asterisk or exclamation point here is one way to lock an account. Even easier, you can use the passwd -l command against an account to lock it without having to edit a file. But either way, we can still switch to the root account anytime (which I’ll show you how to do later on in this chapter). Entering an asterisk or exclamation mark in the second field creates the restriction that we can’t directly log in as that user from the shell or over the network. We have to log in to the system as a normal user account first, and then we can still switch to that user if we want to.

With the discussion of password hashes out of the way, there are a few more fields within /etc/shadow entries that we should probably understand. Here’s a contrived example line:

mulder:$6$TPxx8Z.:16809:0:99999:7:::

Continuing on with the third column, we can see the number of days since the Unix epoch that the password was last changed. For those that don’t know, the Unix epoch is January 1, 1970. Therefore, we can read that column as the password having last been changed 16,809 days after the Unix epoch.

Personally, I like to use the following command to show more easily when the password was last changed:

sudo passwd -S <username>

This will result in an output that looks something like the following:

Figure 2.8: Checking the date of the last password change for a user

By executing this command, you can view information about any account on your system. The first column is obviously the username. The second has to do with the status of the password, which in this case is L, which refers to the fact that the user has a password that is locked. It would show P if the password was set and usable, or NP if the user didn’t have a password at all.

The third column of this command’s output gives you the actual date of the last password change for the user. 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, jdoe can change the password any time because the minimum number of days is set to 0. We’ll talk about how to set the minimum number of days later on in this chapter, but I’ll give you a brief explanation of what this refers to. At first, it may seem silly to require a user to wait a certain number of days to be able to change their password. However, never underestimate the ability of your users to be oppositional. It’s quite common for a user, when required to change their password, to change their password to satisfy history requirements, only to then just change it back to what it was originally. By setting a minimum number of days, you’re forcing a waiting period in between password changes, making it less convenient for your users to cycle back through to their original password.

The fifth column, as you can probably guess, is the maximum number of days that can pass between password changes. If you require your users to change their passwords every certain number of days, you’ll see that in this column. By default, this is set to 99999 days. That number of days is way beyond the human lifespan, so it may as well be infinite.

Continuing with the sixth column, we have the number of days that will elapse before the expiration date on which the user is warned that they will soon be required to change their password. In the seventh column, we set how many days can pass after the password expires, in which case the account will be disabled. With our example user, this is not set. Finally, with the eighth column (which is not visible), we can see the number of days since the Unix epoch that will elapse before the account is disabled (in our case, there’s nothing here, so there is no disabled day set).

We’ll go over setting these fields later, but for now, hopefully you understand the contents of the /etc/shadow file better.

If at any time you’d like additional clarification, feel free to check out the Ubuntu man pages. A man page (short for manual page) can give you quite a bit more information about commands as well as files. For example, the following command shows you the man page for the ls command:

man ls

More specific to this section, you can retrieve man pages for the /etc/shadow files as well:

man passwd
man shadow

Press q on your keyboard to exit out of a man page. Feel free to check out the man pages for any command in this book to learn more as you go along.

Now that we fully understand how to manage our users, we can also look at how to provide them with default files in their home directory.

In a typical organization, there are usually some defaults that are recommended for users in terms of files and configuration.

For example, in a company that performs software development, there are likely recommended settings for text editors and version control systems. Files that are contained within /etc/skel are copied into the home directory for all new users when you create them (assuming you’ve chosen to create a home directory while setting up the user).

In fact, you can see this for yourself right now. Execute the following command:

ls -la /etc/skel

Now, you should be able to view the contents of the /etc/skel directory:

Figure 2.9: Default /etc/skel files

You probably already know how to list files within a directory, but I added the -a option because I wanted to view hidden files as well. The files included in /etc/skel by default are hidden (their filenames begin with a period). I threw in the -l parameter solely because it shows a long list, which I think is easier to read.

Each time you create a new user and request a home directory to be created as well, these three files, shown in Figure 2.9, will be copied into their home directory, along with any other files you create here. You can verify this by listing the storage of the home directories for the users you’ve created so far. The .bashrc file in one user’s home directory should be the same as any other, unless they’ve made changes to it.

Armed with this knowledge, it should be extremely easy to create default files for new users that you create. For example, you could create a file named welcome with your favorite text editor and place it in /etc/skel. Perhaps you may create this file to contain helpful phone numbers and information for new hires in your company. The file would then be automatically copied to the new user’s home directory when you create the account. The user, after logging in, would see this file in their home directory and see the information. More practically, if your company has specific editor settings that are favored for writing code, you can include those files in /etc/skel as well to help ensure your users are compliant. In fact, you can include default configuration files for any application your company uses.

Go ahead and give it a try. Feel free to create some random text files and then create a new user afterward, and you’ll see that these files will propagate into the home directories of the new user accounts that you add to your system.

Now that we have multiple users and have also seen how to manage their default files, we can take a look at how to switch from one user to another.

Now that we have several users on our system, we need to know how to switch between them. Of course, you can always just log in to the server as one of the users, but you can actually switch to any user account at any time, provided you either know that user’s password or have sudo access.

The command you will use to switch from one user to another is the su command. If you enter su with no options, it will assume that you want to switch to root and will ask you for the root password. As I mentioned earlier, Ubuntu locks the root account by default, so at this point you may not have a root password.

Even though Ubuntu doesn’t create a password for root by default, some Virtual Private Server (VPS) providers unlock the root password and actually have you log in as the root user. Having an unlocked root account is not a standard Ubuntu practice, and is a customization specific to some cloud providers.

Unlocking the root account is actually really simple; all you have to do is create a root password. To do that, you can execute the following command as any user with sudo access:

sudo passwd

The command will ask you to create and confirm your root password. From this point on, you will be able to use the root account as any other account. You can log in as root or switch to root—it’s fully available now. However, you really don’t have to unlock the root account in order to use it. You certainly can, but there are ways to switch to root without unlocking it, and it’s typically better to leave the root account locked unless you have a very specific reason to unlock it. The following command will allow you to switch to root from a user account that has sudo access:

sudo su - 

Now you’ll be logged in as root and will be able to execute any command you want with no restrictions whatsoever. To return to your previously logged-in account, simply type exit. You can tell which user you’re logged in as by the value at the beginning of your bash prompt.

What if you want to switch to an account other than root? Of course, you can simply log out and then log in as that user. But you really don’t have to do that. The following command will do the job, providing you know the password for the account:

su - <username>

The shell will ask for that user’s password and then you’ll be logged in as that user. Again, type exit when you’re done using the account, which will return you to the one you were using before you switched.

That command is all well and good if you know the user’s password, but you often won’t. Typically, in an enterprise, you’ll create an account, force the user to change their password at first login, and then you will no longer know that user’s password.

Since you have root and sudo access, you could always change their password and then log in as them. But they’ll know something is amiss if their password suddenly stops working—you’re not eavesdropping, are you? Armed with sudo access, you can use sudo to change to any user you want to, even if you don’t know their password. Just prefix our previous command with sudo and you’ll only need to enter the password for your user account, instead of theirs:

sudo su - <username>

Switching to another user account is often very helpful for support (especially while troubleshooting permissions). As an example, say that a user comes to you complaining that they cannot access the contents of a specific directory, or they are unable to run a command. In that case, you can log in to the server, switch to their user account, and try to reproduce their problem. That way, you can not only see their problem yourself, but you can also test out whether or not your fix has solved their issue before you report back to them.

Now we have a full understanding of user accounts, and even how to switch between them. In the next section, we’ll look into groups, which allow us to categorize our users.