Security by Account Type
Start course

In this course, you'll learn about account security in Linux including pluggable authentication modules (PAM), password security, account access controls, and account types.

Learning Objectives

  • Learn about PAM and how to configure pluggable authentication modules
  • Understand the different types of accounts you'll find on a Linux system and the special precautions you need to take with each account type
  • Learn how to enforce good password security practices on your Linux systems
  • Learn how to make an account's password expire, how to expire an account itself, and how to lock and unlock accounts
  • Understand how to monitor log files and use intrusion detection systems
  • Learn about multi-factor authentication and how it can be implemented in Linux

Intended Audience

This course is intended for anyone who wants to understand how to secure their Linux systems.


To get the most out of this course, you should already have a good working knowledge of Linux. If you want to brush up on your Linux skills, consider taking our Learn Linux in 5 Days learning path first.


Let's talk about the root account. You already know that it's the most important and powerful account on a Linux system. Avoid using this account as your main account. Even if you are the only user on the system, create a normal user account for yourself and use it as your main account. Avoid logging in directly as the root user, instead log into your normal user account and then escalate your privileges to route as needed. If route log-ins are allowed, that means an attacker has the opportunity to get direct access to the root account as well. It's best to block direct log-ins from the root user and I'll show you how to do that in just a bit. If you need root privileges to perform a task, use sudo. Sudo stands for super user do. You simply proceed the command you want to run as route with a sudo command. You can use sudo to get a root shell, but avoid doing that if possible. That would really be the same as running Su space dash space route. The only entry in the log file would be the time when I given user switched to the root account, no other logs would be available. Sudo keeps a log of who ran what command and when creating a better audit trail than simply using SU. Don't use the same root password on every system. You want to create layers of security whenever possible. Each systems should be it's own little container or layer. If you use the same root password on all of your systems, then if one system gets compromised then the rest can be easily compromised. Ensure that the root user is the only account in Etsy password that has an ID of zero. Remember that Linux doesn't care about usernames, it operates on user ID numbers. If another account has a UID of zero, it has super user privileges. Here's a command on your screen that you can run to ensure that only the root account has a UID of zero. One way to disabled root logins is to take advantage of the pam secure TTY module. I've included a commonly used pam directive on your screen. The backslash is the line continuation character so it wouldn't be present if everything was on one line. This line, or one very similar to this will usually be found in the default pam configuration on most Linux distributions. If you want to disable root log-ins for other services, such as graphical log-ins with GDM, KTM, et cetera, then add that line to the pam configuration file for that service. The Etsy secure TTY file contains a list of devices, one per line, where route is allowed to log in. If you only want route to log into the console, just list console. If you only want route to log into TTY one, which is the first virtual console on a Linux machine, list TTY one. If you want to allow logins from multiple places, list each one on a separate line. To disable route logins use a blank Etsy secure TTY file. Even if the file is empty, route access is allowed in single user mode so you won't totally lock yourself out of your system. To disable route from SSH into a system edit the Etsy, SSH SSHD underscore config file and add a permit route log in no line. Have SSHD reload the configuration. If you're using system D, the command is system CTL reload SSHD. Now you won't be able to log in as the root user via SSH. We'll be talking more about SSH security settings in the networking section of this course. By default, there are several system accounts on a Linux system. Some people refer to these accounts as application accounts and others call them service accounts. These accounts are associated with the various services. It's a best practice to associate one service account with one service. For example, if your system runs a web server then have an account that runs that web service and owns the web server data. Unless you have a good reason to do so, keep system and service accounts locked. Remember one way to do that is to set the accounts shell to no login. If you do enable the account for interactive use, i.e. you give the account a real shell, then set the password to something nobody knows, and don't let anyone log into the account directly. You can disable SSH access for specific accounts by using the deny users directive in the SSHD config file. Provide a list of users that you don't want to allow direct SSH access to following the deny users keyword. Instead of sharing the account directly, use sudo to access the account. Sudo can be configured to allow users to run commands as other accounts, not just the root account. So let individual users log into the system as themselves and then use the sudo command to run commands as the application user. Again, it's best to avoid letting people switch to the application account, because then it's difficult if not impossible to tell which individual user did what at that point. We want to keep our audit trail in tact, so don't let users share accounts. One user per account. When a person no longer requires access to the system at least disable their account, but preferably delete their account. This goes for service accounts as well. If the service is no longer needed, uninstalled the service software and remove the associated account. To delete the user's home directory when deleting the account, use the dash r flag to the user dell command. This does not remove other files on the system that belong to the user, however. Once the user is deleted, those files are still owned by the UID of the user. If a new account were to get created with that UID, then they would now own those files. Remember Linux doesn't care about usernames. It only cares about user ID's. Define files that belong to the user that you've just deleted you can run fine with the dash user option and supply the user's UID. If you want to find all files on the system that do not have an owner, use the dash no user option to find. Now you can either delete those files or assign them to the proper owner.

About the Author
Learning Paths

Jason is the founder of the Linux Training Academy as well as the author of "Linux for Beginners" and "Command Line Kung Fu." He has over 20 years of professional Linux experience, having worked for industry leaders such as Hewlett-Packard, Xerox, UPS, FireEye, and Nothing gives him more satisfaction than knowing he has helped thousands of IT professionals level up their careers through his many books and courses.