- Instant Access
- Logging in to Linux
- The Shell and the GUI
- Finding Your Way
- Getting Help
- Editing Text Files
This chapter is from the book
This chapter is from the book
This chapter is from the book
Logging in to Linux
After installing and booting a SLES server, you should be presented with either a text or graphical login prompt. Entering an appropriate username and password will give you access to the server. For an administrator, it is important to understand how access is granted and how local SLES user accounts are configured. It is also important to have this knowledge prior to implementing OES components such as Linux User Management (LUM). The following section will briefly discuss local user accounts and how the local authentication process works.
Local Account Files
On a SLES9 server, local user accounts are defined in the /etc/passwd file as shown in Figure 3.1. Every user defined in this file must have certain attributes that are used by the server for determining such things as user permissions and login name. The format of /etc/passwd is one user account entry per line.
Each line within the passwd file is made up of five fields, separated by colons. These fields provide the necessary attributes for user accounts to be considered valid by the operating system. The purpose of each field is documented in Table 3.1 for the entry jdoe:x:1000:100:John Doe:/home/jdoe:/bin/bash.
)
Figure 3.1 An example of the /etc/passwd file.
Table 3.1 Explanation of /etc/passwd Entry
|
Field Entry |
Description |
|
jdoe |
User login name. |
|
x |
Password field. If an "x" is in this field, shadow passwords are enabled. A "*" in this field prevents most types of local logins. |
|
1000 |
Numeric User ID (UID) of this account. |
|
100 |
Numeric primary Group ID (GID) of this account. |
|
John Doe |
General Electric Comprehensive Operating System (GECOS) field. Commonly used for the user’s full name or description. |
|
/home/jdoe |
User’s home directory. |
|
/bin/bash |
User’s default shell. |
If the second field in the /etc/passwd file is an "x", shadow passwords are enabled. This is the default configuration for SLES. Shadow passwords provide for a more secure environment, and allow for additional password aging options.
When you use shadow passwords, an additional configuration file is used for storing encrypted user passwords. This file is the /etc/shadow file. Table 3.2 explains the fields of this file for the entry jdoe:AztgeYU5TrGn.:12702:0:38:7:3:::.
Table 3.2 Explanation of /etc/shadow Entry
|
Field Entry |
Description |
|
jdoe |
User login name. |
|
AztgeYU5TrGn. |
Encrypted password. |
|
12702 |
Date password was last changed. This value is the number of days between January 1, 1970 and the day the password was last changed. |
|
0 |
Days before password may be changed. |
|
38 |
Days after which password must be changed. |
|
7 |
Days before password expires that user is warned to change the password. |
|
3 |
Days after password expires that account is disabled. |
|
<blank> |
Date account is to be disabled. This value is the number of days between January 1, 1970 and the day the account will be disabled. |
Within the /etc/passwd file, the fourth field contains the GID of the primary group of the specified user. When users create files and directories, the new filesystem objects receive a user owner and a group owner. The user owner is the UID of the user who created the filesystem entry. The group owner is the GID of the user’s primary group at the time of object creation. (Both the UID and GID numbers are converted to user and group names when viewing file listings.) Local groups are defined in the /etc/group file. Table 3.3 shows the fields and their definitions for the entry users:x:100:tjohnson,mblack.
Table 3.3 Explanation of the /etc/group File
|
Field Entry |
Description |
|
users |
Group name. |
|
x |
Encrypted password. An "x" in this field indicates that shadow group files are in use. |
|
100 |
Numeric Group ID (GID). |
|
tjohnson,mblack |
Secondary members of the current group. |
Creating and modifying local user accounts and groups can be done with several utilities. Within SLES, the YaST utility can be used to easily create these accounts. (Information on YaST can be found in Chapter 6.) Users and groups can also be added to the system using several command-line utilities. A few of these utilities are listed in Table 3.4.
Table 3.4 Local User and Group Utilities
|
Utility |
Description |
|
useradd |
Create a new local user account |
|
userdel |
Delete local user account |
|
passwd |
Set or change user password |
|
usermod |
Modify a local user account (including password expiration intervals) |
|
grpadd |
Add a local group |
|
grpdel |
Delete local group |
|
pwconv |
Convert to secure shadow accounts |
|
pwunconv |
Convert from shadow accounts to normal password accounts |
The Root Administrator Account
Within Linux, the superuser or administrator account is known as root. This account has all rights over everything found on a Linux server. It is important to realize that these rights cannot be locked out or restricted in any way. Given the vast amount of power root has, a secure and confidential password must be used for this account.
It is also important to avoid using the root account just for the sake of accessibility. When you are logged in as root, malicious scripts or programs can potentially be deadly to your Linux environment if they are run accidentally. Be sure to avoid these issues by logging in as a regular user and only using root privileges when necessary. (See the "Switching Identities" section later in this chapter for more information on that topic.)
The UID for root is always 0 (zero). This is hard-coded into many aspects of Linux and should not be manually adjusted. Also, when integrating local Linux accounts into OES through LUM, the root account should not be included. Local user account access to the server as the root user is critical for many troubleshooting steps.
The Login Process
There are actually many methods by which a user can authenticate or log in to a Linux server. The tables in the preceding section describe how local user accounts are stored in the system, but having a local user account is only one step in the login process.
Local logins are not the only method of authentication to a Linux server. Logins can be initiated through several methods, including remote graphical sessions, remote shell sessions, and service-specific type of authentications, such as occur when authenticating to a Samba server.
Although these types of authentications normally rely on the local user account files, most can also be configured to authenticate using a remote user account store. These stores can be many different types, but authentication back to an LDAP-enabled directory, such as eDirectory, is an extremely common method of providing account management. OES provides for this functionality in the Linux User Management (LUM) component. LUM is covered in detail in Chapter 8, "Users and Network Security." LUM is actually quite complex, and understanding the authentication process of a local login should help you get prepared for implementing LUM.
In SLES, Pluggable-Authentication Modules (PAM) are used to provide user authentication to all PAM-enabled services. PAM-enabled services include local logins, secure shell access, and most other services requiring authentication. PAM configuration of these services is performed using service-specific configuration files found in /etc/pam.d. In this directory, each service relying on PAM to enforce authentication has a configuration file. The default login configuration file used for local logins is shown in Figure 3.2.
PAM configuration divides the authentication process across four distinct module types. The explanations for these module types can be found in Table 3.5.
)
Figure 3.2 Contents of /etc/pam.d/login.
Table 3.5 PAM Module Types
|
Module Type |
Description |
|
Auth |
Used to establish the user’s validity through checking passwords or other credentials. |
|
Account |
Used to ensure a valid user account exists and is allowed access. This stage will not allow expired, disabled, or otherwise invalid accounts to proceed. |
|
Password |
Used to set the authentication token (password) of the user. |
|
Session |
Used to create a session for the authenticated user. |
Each module type takes one of four control flags as a parameter used to indicate how that specific module is to be handled. These control flags are explained in Table 3.6.
Table 3.6 PAM Control Flags
|
Control Flag |
Description |
|
Required |
All module checks are required to complete successfully. If a module fails, all other modules are processed. All failures are then returned to the authentication process. |
|
Requisite |
Similar to required, but with a requisite control flag, execution halts at the first failure. The corresponding error code is immediately returned to the authentication process. |
|
Sufficient |
After a sufficient module is successfully processed, the module type is considered to have been successfully processed and execution skips to the next module type. |
|
Optional |
Optional modules are not required to be successfully completed in order for the login to be successful. |
The last two fields of the PAM configuration file for any service are used to denote external authentication modules and any parameters those modules may require. Many different modules can be used for each portion of the authentication stages. These modules range from providing LDAP lookup for user accounts to checking passwords for certain security requirements.
In the case of a login process based on the configuration file in Figure 3.2, the authentication process would have to successfully pass all requirements for each specified module in order to generate a fully authenticated connection. In other words, the pam_unix2.so module would ensure that the user’s account exists and is allowed access. The pam_securetty.so module then determines if the user is allowed to log in from the current terminal. The pam_nologin.so module is used to check for the existence of an /etc/nologin file, which would prevent non-root users from logging in. This process continues until all modules have been processed. If the PAM modules are successfully processed, the user is authenticated and provided with a shell prompt. Otherwise, the user is denied access.
Switching Identities
When you have logged in to a Linux environment using your local account, you may find that you have insufficient privileges to accomplish a specific task. In order to execute certain commands, or have rights to view specific files, it is sometimes required to change your identity to that of the root user. To do this, you must use the su command.
The su or "substitute user" command is used to temporarily substitute your identity with that of another user. When run as a normal user and executed with no parameters, the su command will prompt for root’s password. After the password has been entered, the current session will be given root-level access. (To return to your normal permissions, use exit.) The su command can also be used to switch to the identity of another, non-root user. To perform this action, specify the desired user name as a parameter to su, as shown in Figure 3.3.
)
Figure 3.3 An example of using the su command.
It is important to realize that the su command does not otherwise modify the current environment. In other words, executing su will not change the current directory, or the currently configured environment variables. When switching to another user’s identity, it is often desirable to also assume that user’s environment. This requires switching identities and also executing a normal login process for the new user. In order to temporarily switch users and complete a login cycle as that user, the su command must be executed using a "-"command-line parameter, as shown in Figure 3.4.
)
Figure 3.4 Example of the su - command.