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.