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.