Linux provides many basic security mechanisms that allow you to ensure the confidentiality, integrity, and availability of data on your device. Authentication, logging, authorisation, network filtering, virtual environments, encryption and many other subsystems can be managed by tools from the user space.
So a handy PAM or Pluggable Authentication Module solution allows you to aggregate authentication providers and provide their APIs to applications. For example, almost all system utilities for user authentication interact with PAM. How to configure it and why you should use 2FA - let's study it in this article.
What is PAM?
PAM or Pluggable Authentication Module is a service that aggregates different authentication providers and allows you to verify users. It is neither a raised service nor a kernel module, but a library stored in system paths that applications call themselves. This means that authentication via PAM is not possible without calling it, make sure your application uses PAM!
Typically the workflow is as follows:
When connecting via ssh, the user connection is handled by the sshd daemon. Having identified the user it is necessary to authenticate the user, for this ssh uses its own validation mechanisms and connects the authentication library to this. PAM starts looking for the necessary script for sshd and finds echo at /etc/pam.d/sshd. After reading the necessary parameters, accesses the libraries to authenticate the user data and returns to sshd. Either authenticated with such a UID, GID.
Many utilities and software work according to the same scheme, when instead of writing their own authentication they simply refer to PAM, where the script is already written. Let's see an example of how to set up such authentication and add a second factor!
How do I configure PAM to work?
For example, let's take the same service sshd and configure for it authentication by keys + by TOTP codes. TOTP or time-based passwords are tied to the time, owning a master key the current time is converted into a 6-digit code. It is calculated both on the client and server side, which allows authentication by the code that changes every 30 seconds.
To start with, let's install all the necessary dependencies, these are the module for authentication google_authentificator and the network time service.
apt update && apt install ntp libpam-google-authenticator 
Let's configure the server time so that it coincides with the time of our client, where we will install the application. Let's start the NTP service and check its operability:
sudo systemctl start ntpd && sudo systemctl status ntpd 
If you want to change the server pools that will be responsible for time synchronisation, you need to go to the config:
nano /etc/ntpsec/ntp.conf 
Replace the submitted server pools, then reread the configs for the services and check if the time sources are available:
systemctl daemon-reload && echo "peer" | ntpq
Great, the NTP client configuration is complete, you can also optionally specify a time zone. However, this does not affect the operation of TOTP as it takes the minutes and seconds information to generate the time code. Let's move on to configuring google_authentificator:
google-authenticator 
We answer yes to the question about using time to create the code and scan the qr or enter the code into a pre-downloaded app from AppStore or GooglePlay with the same name Google Authenticator. Below the QR line requires you to enter the time code from your phone to make sure the master key in the QR is correct. And then you can answer yes to all other questions and service options. And finally let's get to the PAM itself!
If you don't have sufficient resources than you can perform actions on powerful cloud servers. Serverspace provides isolated VPS / VDS servers for common and virtualize usage.
The first thing PAM does is to look up the script for the utility, so let's move to it along the path:
nano /etc/pam.d/sshd The logic of the work is that PAM goes through each action from top to bottom on each line and performs according to the modules checks. To understand the structure of the file, let's quickly analyse the main components, first of all the types of modules used:
- auth - module for authentication;
- account - module for authorisation;
- session - module for session management;
- password - module for re-authentication in the process of work.
In our case we will modify only authentication modules, the next line item is a control flag that defines the requirement for the authentication result. For example:
- required requires that the result of the operation is successful, in case of failure it will pass control to the next lines. However, the
- authentication will no longer be considered successful;
- requisite requires the result to succeed, if it fails it will terminate without passing control below;
- optional the result of a module is irrelevant if that module is the only one;
- sufficient requires the result to be successful, if unsuccessful it will pass control to the next lines. If successful, fully authenticates without further checks;
- include includes configs with the same instructions, so that repetitive verification mechanisms can be reused.
And so, in our case, the rules are presented in the form of lines, where there is an item @include common-auth, it is responsible for password authentication. Let's disable it by writing # at the beginning of the line and before it write a line requiring authentication by TOTP:
auth required pam_google_authenticator.so 
Остальной файл оставим неизменным, последним этапом будет настройка sshd_config для этого откроем его:
nano /etc/ssh/sshd_config And we will add additional lines where we will disable password authentication, enable key authentication, and specify methods for verification:
UsePAM yes
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactiveAfter saving the file and restarting sshd using the command:
systemctl restart sshdLet's try to authenticate and check if our settings have changed:
As you can see, when accessing the server, the keys were checked and only then the code from TOTP was requested, after which sshd authorised the user. The variations of how to use PAM and its modules are limited only by your imagination and the protection requirements of the regulator. You can configure 3 stages of authentication by 3 different factors or even 5 stage authentication, that's the advantage of a modular solution!
