Reasonably add accounts and set users to ensure system security and reliability

There are many problems to consider when it comes to system security and reliability. Today, we will focus on how to securely add accounts and set user shells.

Add User Accounts to servers

When setting the server, we often allow people to upload files or download files or messages from the server. However, we do not want to allow these people to access the entire server. In fact, when we create these users, we can restrict their access permissions.

To restrict a remote user from logging on to the shell (via SSH, telnet, or other logon services), we can set the default shell to nologin for a user. For example:

# Useradd-s/sbin/nologin jerryb

After the shell is set to nologin, this user cannot log on to the server to open a shell. However, you can still use this account to log on to the FTP service on the server (if the server is available and the user has a password ). By default, in this example, the initial directory (home directory) When you log on via FTP will be/home/jerryb. The other method that can only access the FTP service on the server is to use the/usr/lib/sftp server to act as the login shell of a user. Although this allows users to access the entire file system available to users, it limits them to access the server only through secure FTP.

A common approach for Web hosts is to allow users to place content on the server, usually by using FTP (but not shell logon) in the user's/home/username/public_html directory. However, the administrator can specify the location of the Web content to any directory, including the Web server directory within the system. The following command specifies/var/www/html as the starting directory for the webuser. (For this command to take effect, we should also change the file ownership to webuser ):

# Useradd-s/sbin/nologin-d/var/www/html webuser

If you want to add an account so that it can only access the email service, you can also choose to prevent any access to FTP. One method is to point the user's starting directory to/dev/null. For example:

# Useradd-s/sbin/nologin-d/dev/null jerryb

After a restricted user account is configured, you can use the features related to specific services to further define the services that users can access and inaccessible services on the server.

Configure Shell for the user

It is quite flexible and practical to allow each user to customize its shell Startup File individually. However, sometimes we need more centralized control than this method. You may have an environment variable or other shell settings you want to set for each user (without exception ). If you add this setting for each shell, you can edit the file and clear it. Further, if this setting needs to be changed in the future, you must change it in the shell Startup File of every user.

Fortunately, there is a better way. We have a default boot file that can be used by all users on the computer, and the command shell reads the default boot file before reading the file of a specific user. In this case, the bash command shell reads the/etc/bashrc file before executing any other operations.

Similarly, before processing the. cshrc or. tcshrc file in the user's home directory, the tcsh shell first reads the/etc/csh. cshrc file. The/etc/csh. cshrc file in the following example applies to Fedora and RHEL:

#/Etc/cshrc
#
# Csh configuration for all shell invocations.

# By default, we want this to get set.
# Even for non-interactive, non-login shells.
[Id-gn = id-un-a id-u-gt 99]
If $ status then
Umask 022
Else
Umask 002
Endif

If ($? Prompt) then
If ($? Tcsh) then
Set prompt = [% n @ % m % c] $
Else
Set prompt = [id-nu @ hostname-s] $
Endif
Endif

/Etc/cshrc and/etc/bashrc have multiple shell environment options. If you want to add or modify the shell environment provided by the system for each user, the/etc/bashrc or/etc/cshrc file is exactly where you perform this operation.