If you need to lock an account, you can do so by running the passwd command, followed by -l followed by the account name. To unlock the account run passwd -u followed by the account name. Another way to lock an account or make sure it's not used interactively is to set the account's shell to no login. On your screen are a couple of sample entries from etc password. The first entry is from a Sento system and the other one is from an Ubuntu system. In both cases, they are system accounts that should not be used interactively. The path to no login is different on these distributions but the concept remains the same. If you were to switch to these accounts you would get a message from the no login command that says the account is not available. You can manually edit the etc password file but the preferable way to change shells on an account is to use the chsh command. You can use the -s option to supply the path to the desired shell. To lock the Jason account on a Sento system, I would run chsh space - s space /s space /sbin/nologin space jason. You can also set the shell to some other command. Historically, the shell would have been set to /bin/false so you may see that on some older systems. I just wanted to quickly point out that if you configured your systems to authenticate against a central authentication system like LDAP or freeIPA, then when you lock an account, you can lock it everywhere. The obvious downside of using a centralized system like this is if an attacker gained access to that system they can gain access to all the other systems that use it for authentication. Let's say you want to keep users from logging into your Linux system for a period of time. One way to do this is to take advantage of the pam_nologin module. If the module is enabled in your PAM configuration when you create this /etc/nologin or /var/run/nologin file logins are disabled. You can place a message in that file that will be displayed to users when they attempt to log in. To re-enable log-ins just simply remove the /etc/nologin or /var/run/nologin file. A record is created when someone logs into the system. For example, the last command displays a list of last logged in users by looking at entries in the /var/log/wtmp file. wtmp in this case is spelled w-t-m-p Failed login attempts are recorded as well. The last B command displays failed attempts by examining the slash /var/logs/btmp file. Again, that's b-t-m-p in this case. The last log command reports the last time a user has logged in. This information is stored in /var/log/lastlog. Authentication information may be stored in various other log files as well. This actually depends on the configuration being used by the system logger. Common places to find authentication logs are in /var/log/messages, /var/log/syslog, /var/log/secure and /var/log/auth.log. Again, consult the configuration of your system logger for your distribution. Instead of manually examining authentication logs you can use an intrusion prevention system or IPS, also known as an intrusion detection and prevention system IDPS such as a fail2ban. Typically fail2ban is configured to create a firewall rule to block the IP address of an attacker who is attempting a brute force attack. If repeated failed login attempts are detected the IP address is blocked. fail2ban is usually configured to unblock a host or an IP address within a certain period of time so as to not permanently lock out a genuine connection that may have been temporarily misconfigured. fail2ban can be configured to monitor any service that writes log in attempts to a log file. fail2ban even ships with filters for popular software, such as Apache, VSFTBD, qmail and Postfix. We've talked about using multi-factor authentication before. It's typically comprised of something you know, such as a password and something you have. At the time of this recording, there are at least a few good options for multi-factor authentication for Linux systems. One solution is to install and configure the Google authenticator PAM module. When you connect via SSH, you will be prompted for the code that is being displayed on your Google authenticator device, such as your phone. Another option is provided by DuoSecurity. When you connect to a system via SSH, DuoSecurity will send a message to your phone asking if you want to allow the connection to continue. You can also configure your system to use an RSA SecurID token. Like Google authenticator it displays a series of numbers that rotate. When you connect to the system you'll be prompted for the code that is currently displayed on your device. Using multifactor authentication mechanisms such as these can really tighten up account security. These are some popular options at the time of this recording, but there are other options available and these may change over time.