Linux-PAM (Pluggable Authentication Modules)
A user can interactively authenticate to applications (or services) in a Linux system using the comprehensive set of common modules known as Linux-PAM. Pluggable Authentication Modules, often known as Linux-PAM, are an evolution of the Unix-PAM concept. It provides dynamic authentication for apps by fusing several low-level authentication modules with a high-level API. This enables programmers to construct applications that need authentication regardless of the underlying authentication system. Modern Linux variations usually support Linux-PAM (commonly known as “PAM”) by default.
The relationship between services and PAMs that do the real authentication tasks is what system administrators must comprehend the most about PAM configuration files. You are not required to understand PAM’s internal workings. PAM may materially impact the security of your Linux system. Access to your laptop could be completely or partially blocked by incorrect settings.
Interfaces of Linux-PAM
The duties related to PAM authentication are handled independently by four management groups. These groups handle different parts of the request when a typical user makes a restricted service request:
Account
Using this module, you can check to see if the specified account is still valid in the given situation. In this category, a number of things are looked at, such as account expiration, the time of day, or if the user has permission to use the relevant service.
Authentication
After all the fundamental data has been confirmed to be accurate, this module verifies the user’s identity. Allowing the user to enter a login or any other specific piece of information that only they must know serves to confirm their identity
Password
This module helps the user update passwords and is intended to function in conjunction with the authentication module. Secure passwords can be enforced using either resonance.
Session
The actions that must be carried out at the beginning and conclusion of sessions are described in this module, which is not the least significant of the modules that make up the sequence in which the overall PAM strategy accomplishes the desired purpose. Once the person has properly validated themself, the session can start.
How to validate a Linux-PAM
A software or application needs to be “PAM aware,” or specifically developed and compiled to use PAM. To check if a program was created with the PAM library and is “PAM-aware,” use the “ldd” command. The file “libpam.so” is highlighted in the second line that supports the query when the command “ldd /bin/su” is run. The screenshot below displays the validation:
The configuration for LINUX-PAM is located in the directory /etc/pam.d/. Enter the following command in the terminal of your Linux operating system to access the PAM directory:
The previous image demonstrates how to use the “ls” command to browse the contents of the PAM directory. If it isn’t mentioned as a service that uses PAM, the sshd server needs to be installed. A networking tool called SSH, commonly referred to as secure shell, encrypts data transmission and enables different computer types and users to connect securely and remotely to various systems via a network. The command below will download the openssh-server package:
Once it has finished installing all the files, you may re-enter the PAM directory, check for the services, and notice that the sshd has been installed. The “/etc/pam.d” directory contains a highlighted entry for the sshd service.
How to configure a Linux-PAM
Every call made by a PAM module either succeeds or fails. With the use of control flags, PAM handles the outcome. The success or failure of each module in relation to the overarching goal of verifying the user’s identification with the service is specified by the control flags, and modules can be piled in a particular sequence. There are four accessible preconfigured control flags:
Required
The package response must be successful for authentication to continue. If the attempt fails at this point, the user won’t be informed until all of the package tests that utilise that interface have completed completing their analyses.
Requirement
The reasoning say that if this breaks, everything else would too. A failure warning will be sent and PAM will also be discontinued.
Sufficient
No other required modules are called if this module succeeds and all preceding required modules also succeed.
Optional
Option indicates that the module is not necessary for the outcome of the user’s service request. Only in the absence of any demonstrable successes or failures of previous or later stacked modules is its value taken into account.
Include
This control flag retrieves each line from the configuration file when the matching argument matches.
Simply use the command below in the PAM directory:
As you can see, the phrase “control-flags,” which we previously mentioned in the PAM file below:
When writing the basic configuration, keep in mind the following general rule:
Service
Service is the official name of the software.
Type
Interface, context, and type of module
Control-Flag
The control flag dictates how the PAM-API will behave if the module fails to fulfil its authentication task
Module
The filename or absolute pathname for the PAM
Module-argument
A list of tokens called module parameters can be used to modify a module’s functionality.
You must restrict access to the sshd service if you want to stop root users from using SSH to connect to any systems. Access to the login services must also be limited.
However, we may make use of the very flexible and feature-rich module /lib/security/pam listfile.so. Several modules control access and distribute privileges. Open the target service’s file in the /etc/pam.d/ directory and make the following adjustments:
In the file, the following rule has to be added:
The module type was previously auth (or context). The control flag indicates that the module must succeed if it is used, regardless of how well the other modules are doing, or the entire result will be a failure. The PAM listfile offers a way to activate or disable services based on any file. Therefore, module. onerr=succeed is a module argument. The module argument item=user describes the contents of the file that must be validated. If the item is found in the file, the sense=deny module option specifies what should be done. If not, the alternative course of action is demanded. The module option file=/etc/ssh/deniedusers specifies a file with a line break between each item.
After the file /etc/ssh/deniedusers has been created, the name root must be added:
Once the relevant rights have been granted, save the changes and close the file:
With the preceding rule in place, PAM will be given instructions to examine the contents of the file /etc/ssh/deniedusers and forbid any users who are listed from accessing the SSH and login services in the future.
Conclusions
The strong high-level API known as PAM allows programs that rely on authentication to guarantee that only authorized apps are present in a Linux operating system. It has a lot of power, but it’s also very challenging to understand and use. Dynamic authentication is supported by PAM for Linux-based programs and services. The control flags listed in this manual can all be used to assess a module’s performance. Because PAM is more dependable and user-friendly than the traditional password-and-username authentication technique, it is frequently utilized in many secure systems.
