Linux安全认证隐匿插件：PAM配置探秘

初遇PAM：踏入未知领域

案例：

现网环境升级总是报错端口已被占用，原因是执行升级包中的一条命令时，返回多了一条日志打印，导致升级包中解析命令执行结果错误

当时是第一次遇到这个问题，谁也不知道这条日志是系统在哪里配置打印的。

只能通过strace跟踪，看看执行这条命令时，进行了哪些系统调用，最后通过对比其他正常环境strace的结果，发现在打印Last Login之前，对比正常环境多执行了postlogin

简单的去搜索了一下pam.d下配置文件的作用，发现pam是linux的一个可插拔的认证模块，通过pam.d下的配置，可在不同的功能应用模块设置认证障碍。而postlogin的作用是配置在用户完成登录并且会话模块完成之后执行的一些操作

查看/etc/pam.d/postlogin.发现在postlogin配置了lastlog的pam模块，用于记录用户上次登录时间和来源

那为什么sudo命令会加载这个插件呢？

在/etc/pam.d目录下搜索了一下postlogin，发现还挺多的。此时还不知道是到底是哪个配置文件下的postlogin导致了这行日志打印

只能再通过strace  -e trace=open sudo ls （这里主要是观察sudo命令加载的认证插件）继续追踪

对比之下发现是system-auth这个配置文件。

原来这个文件的作用是定义系统上的默认身份验证规则和策略。调用 sudo 命令时会读取 /etc/pam.d/system-auth 文件是因为 sudo 是一个需要身份验证的特权管理工具。在执行 sudo 命令时，sudo 命令需要读取 /etc/pam.d/system-auth 文件以获取系统的默认身份验证规则和策略，以确定用户是否有权限执行请求的操作。

解决方案：

方案1： 注释掉 /etc/pam.d/system-auth中session     include       postlogin

方案2：注释掉/etc/pam.d/postlogin 中的session     [default=1]   pam_lastlog.so  nowtmp showfailed

PAM详解：揭开神秘面纱

PAM简介

PAM全称是Pluggable Authentication Modules，可插拔认证模块，设计初衷，是将不同的底层认证机制，集中到一个高层次的API中，省去开发人员自己去设计和实现各种繁杂的认证机制的麻烦。

比如，对于常用命令su ，在执行时，需要做两件事：认证和启动相应的shell。

对于认证功能，开发人员一开始可能会判断，当前用户是不是root，如果不是root的，则要求输入 密码。这个逻辑并不复杂，容易开发。

但可能过了几天，用户提出，运维团队都属于wheel组，是否能让wheel组不用输入密码使用su切换。

等等，认证的需求，可能各式各样，如果每个命令都要去关注认证，那linux开发人员不仅不能专注自己业务模块，而且还会出现“重复造轮子”的情况。

所以伟大的PAM功能模块就出现了。

PAM的基础配置

Linux系统中每个支持pam的服务，都有一个与之对应的配置文件在/etc/pam.d/目录下

而支持这些配置的各个认证模块默认在/lib/security 或者/lib64/security目录下，以动态库文件的形式存在

/etc/pam.d/下配置文件的语法格式

模块类型（Type）：PAM 配置文件中的每一行通常包含一个模块类型，指定了该行描述的模块在何时被调用。常见的模块类型包括 auth（身份验证）、account（账户）、password（密码）、session（会话）。

控制标记（Control Flags）：在模块类型后面，可能会有一个或多个控制标记，用于指定模块的行为。常见的控制标记包括：

required：该模块必须成功才能继续进行认证过程。

requisite：如果该模块失败，认证过程将立即失败，且不会继续进行其他模块的认证。

sufficient：如果该模块成功，则认证过程将成功，且不会继续进行其他模块的认证。

optional：无论该模块成功或失败，认证过程都将继续进行。

include: 将其他配置文件中的流程栈包含在当前的位置

substack：运行其他配置文件中的流程，并将整个运行结果作为该行的结果进行输出。

模块路径和参数：在控制标记后面，可以指定模块的路径和参数。路径指定了要使用的 PAM 模块的名称或路径，参数则是传递给模块的额外选项。

上述案例中其实也可以看出cat /etc/pam.d/sudo include了 system-auth模块，所以才会调用/etc/pam.d/system-auth配置中的postlogin。

PAM支持的认证插件

可以通过“man 模块”获取官方文档进行查看。此处不再赘述

再遇PAM：ssh秘钥登录缓慢，密码登录正常

案例：

产品部署失败，因为使用秘钥连接worker节点缓存，需要接近30s，导致节点认证失败

思路：使用traceroute和mtr排除了网络问题，怀疑是ssh的配置导致秘钥登录的方式过于缓慢，但是对比了现网环境和正常环境的ssh配置，发现也并无差异。

查看系统日志（由于环境开启了auditd审计日志，所以系统日志可能打印得比较多，先过滤ssh）

tail -f /var/log/messages | grep ssh

锁定这个时间段的日志，这是ssh开始到ssh成功结束的日志，再vim查看，发现在ssh期间一直在通过PAM插件进行session open 和session close

跟会话相关的PAM插件是pam_systemd.so， 负责在会话期间创建和关闭 systemd 作用域。

搜索/etc/pam.d/下是否配置了pam_systemd.so

发现在/etc/pam.d/password-auth中配置了，并且在/etc/pam.d/sshd中也include了password-auth

推测是 SSH 在每次进行认证时都会触发 PAM 模块的执行，这样会导致不断触发 pam_systemd.so 创建和关闭会话，并且记录审计日志，导致连接缓慢。

解决方案

在/etc/pam.d/password-auth注释掉-session     optional      pam_systemd.so

注释掉后，ssh秘钥登录响应时间立马从30s变成1s内，连接期间，审计日志也不再重复打印session open和session close的审计日志了

总结：

这些问题排查的难点是：

1. 问题出在不了解的领域时，很难想到，特别是系统层面。遇到问题，在业务层面没有思路了时，strace和系统日志是很好的工具，因为所有的程序都是从业务层再到系统再到硬件的（有时还涉及到网络），这是一条完整的链路。
2. 根据完整的链路，再逐个去查询单个的知识点，了解整个过程，那就没有什么问题可以难倒你了。