用户的特殊 shell 与 PAM 模块
特殊的 shell, /sbin/nologin
使用了这个 shell 的用户即使有了密码,你想要登入时他也无法登入,因为会出现如下的讯息喔:
This account is currently not available.
我们所谓的『无法登入』指的仅是:『这个使用者无法使用 bash 或其他 shell 来登入系统』而已,并不是说这个账号就无法使用其他的系统资源喔!
举例来说,各个系统账号,打印作业由 lp 这个账号在管理, WWW 服务由 apache 这个账号在管理, 他们都可以进行系统程序的工作,但是『就
是无法登入主机取得互动的 shell』而已啦!_
换个角度来想,如果我的 Linux 主机提供的是邮件服务,所以说,在这部 Linux 主机上面的账号,其实大部分都是用来收受主机的信件而已,并不需要登入主机的呢! 这个时候,我们就可以考虑让单纯使用 mail 的账号以 /sbin/nologin 做为他们的 shell , 这样,最起码当我的主机被尝试想要登入系统以取得 shell 环境时,可以拒绝该账号呢!
另外,如果我想要让某个具有 /sbin/nologin 的使用者知道,他们不能登入主机时, 其实我可以建立/etc/nologin.txt这个文件, 并且在这个文件内说明不能登入的原因,那么下次当这个用户想要登入系统时, 屏幕上出现的就会是 /etc/nologin.txt 这个文件的内容,而不是预设的内容了
例：
[root@study ~]# vim /etc/nologin.txt
This account is system account or mail account.
Please DO NOT use this account to login my Linux server.
[root@study ~]# su - myuser3
This account is system account or mail account.
Please DO NOT use this account to login my Linux server.
PAM 模块简介
在过去,我们想要对一个使用者进行认证 (authentication),得要要求用户输入账号密码, 然后透过自行撰写的程序来判断该账号密码是否正确。也因为如此,我们常常得使用不同的机制来判断账号密码, 所以搞的一部主机上面拥有多个各别的认证系统,也造成账号密码可能不同步的验证问题! 为了解决这个问题因此有了 PAM (Pluggable Authentication Modules, 嵌入式模块) 的机制!
PAM 可以说是一套应用程序编程接口 (Application Programming Interface, API),他提供了一连串的验证机制,只要使用者将验证阶段的需求告知 PAM 后, PAM 就能够回报使用者验证的结果 (成功或失败)。由于 PAM 仅是一套验证的机制,又可以提供给其他程序所呼叫引用,因此不论你使用什么程序,都可以使用 PAM 来进行验证,如此一来,就能够让账号密码或者是其他方式的验证具有一致的结果!也让程序设计师方便处理验证的问题喔!
PAM 用来进行验证的数据称为模块 (Modules),每个 PAM 模块的功能都不太相同。举例来说, 还记得我们在本章使用 passwd 指令时,如果随便输入字典上面找的到的字符串, passwd 就会回报错误信息了!这是为什么呢?这就是 PAM 的 pam_cracklib.so 模块的功能!他能够判断该密码是否在字典里面! 并回报给密码修改程序,此时就能够了解你的密码强度了。
所以,当你有任何需要判断是否在字典当中的密码字符串时,就可以使用pam_cracklib.so 这个模块来验证! 并根据验证的回报结果来撰写你的程序呢!这样说,可以理解 PAM 的功能了吧?
PAM 模块设定语法
- 用户开始执行 /usr/bin/passwd 这支程序,并输入密码;
- passwd 呼叫 PAM 模块进行验证;
- PAM 模块会到 /etc/pam.d/ 找寻与程序 (passwd) 同名的配置文件;
- 依据 /etc/pam.d/passwd 内的设定,引用相关的 PAM 模块逐步进行验证分析;
- 将验证结果 (成功、失败以及其他讯息) 回传给 passwd 这支程序;
- passwd 这支程序会根据 PAM 回传的结果决定下一个动作 (重新输入新密码或者通过验证!)
从上头的说明,我们会知道重点其实是 /etc/pam.d/ 里面的配置文件,以及配置文件所呼叫的 PAM模块进行的验证工作! 既然一直谈到 passwd 这个密码修改指令,那我们就来看看 /etc/pam.d/passwd这个配置文件的内容是怎样吧!
[root@study ~]# cat /etc/pam.d/passwd
#%PAM-1.0 <==PAM 版本的说明而已!
auth include system-auth
account include system-auth<==每一行都是一个验证的过程
验证类别 控制标准 PAM 模块与该模块的参数
第一个字段:验证类别 (Type)
auth
是 authentication (认证) 的缩写,所以这种类别主要用来检验使用者的身份验证,这种类别通常是需要密码来检验的, 所以后续接的模块是用来检验用户的身份
account
account (账号) 则大部分是在进行 authorization (授权),这种类别则主要在检验使用者是否具有正确的权限,举例来说,当你使用一个过期的密码来登入时,当然就无法正确的登入了。
session
session 是会议期间的意思,所以 session 管理的就是使用者在这次登入 (或使用这个指令) 期间,PAM 所给予的环境设定。 这个类别通常用在记录用户登入与注销时的信息!例如,如果你常常使用 su 或者是 sudo指令的话, 那么应该可以在 /var/log/secure 里面发现很多关于 pam 的说明,而且记载的数据是『session open, session close』的信息!
password
password 就是密码嘛!所以这种类别主要在提供验证的修订工作,举例来说,就是修改/变更密码啦!
这四个验证的类型通常是有顺序的,不过也有例外就是了。 会有顺序的原因是,(1)我们总是得要先验证身份 (auth) 后, (2)系统才能够藉由用户的身份给予适当的授权与权限设定 (account),而且(3)登入与注销期间的环境才需要设定, 也才需要记录登入与注销的信息 (session)。如果在运作期间需要密码修订时,(4)才给予 password 的类别。这样说起来, 自然是需要有点顺序吧!
第二个字段:验证的控制旗标 (control flag)
required
此验证若成功则带有 success (成功) 的标志,若失败则带有 failure 的标志,但不论成功或失败都会继续后续的验证流程。 由于后续的验证流程可以继续进行,因此相当有利于资料的登录 (log) ,这也是 PAM 最常使用 required 的原因。
requisite
若验证失败则立刻回报原程序 failure 的标志,并终止后续的验证流程。若验证成功则带有 success 的标志并继续后续的验证流程。 这个项目与 required 最大的差异,就在于失败的时候还要不要继续验证下去?由于 requisite 是失败就终止, 因此失败时所产生的 PAM 信息就无法透过后续的模块来记录了。
sufficient
若验证成功则立刻回传 success 给原程序,并终止后续的验证流程;若验证失败则带有 failure 标志并继续后续的验证流程。 这玩意儿与 requisits 刚好相反!
optional
这个模块控件目大多是在显示讯息而已,并不是用在验证方面的。
常用模块简介
谈完了配置文件的语法后,现在让我们来查阅一下 CentOS 5.x 提供的 PAM 预设文件的内容是啥吧!由于我们常常需要透过各种方式登入 (login) 系统,因此就来看看登入所需要的 PAM 流程为何:
[root@study ~]# cat /etc/pam.d/login
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth substack system-auth
auth include postlogin
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user contextsession required pam_selinux.so open
session required pam_namespace.so
session optional pam_keyinit.so force revoke
session include system-auth
session include postlogin
-session optional pam_ck_connector.so
# 我们可以看到,其实 login 也呼叫多次的 system-auth ,所以底下列出该配置文件
[root@study ~]# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session
optional
pam_systemd.so
session [success=1 default=ignore] p
上面这个表格当中使用到非常多的 PAM 模块,每个模块的功能都不太相同,详细的模块情报可以在你的系统中找到:
/etc/pam.d/*:每个程序个别的 PAM 配置文件;
/lib64/security/*:PAM 模块文件的实际放置目录;
/etc/security/*:其他 PAM 环境的配置文件;
/usr/share/doc/pam-*/:详细的 PAM 说明文件。
例如鸟哥使用未 update 过的 CentOS 7.1 ,pam_nologin 说明文件档在:
/usr/share/doc/pam-1.1.8/txts/README.pam_nologin。你可以自行查阅一下该模块的功能。 鸟哥这里仅简单介绍几个较常使用的模块,详细的信息还得要您努力查阅参考书呢! _
pam_securetty.so:
限制系统管理员 (root) 只能够从安全的 (secure) 终端机登入;那什么是终端机?例如 tty1, tty2 等就是传
统的终端机装置名称。那么安全的终端机设定呢? 就写在 /etc/securetty 这个文件中。你可以查阅一下该文
件, 就知道为什么 root 可以从 tty1~tty7 登入,但却无法透过 telnet 登入 Linux 主机了!
pam_nologin.so:
这个模块可以限制一般用户是否能够登入主机之用。当 /etc/nologin 这个文件存在时,则所有一般使用者均
无法再登入系统了!若 /etc/nologin 存在,则一般使用者在登入时, 在他们的终端机上会将该文件的内容
显示出来!所以,正常的情况下,这个文件应该是不能存在系统中的。 但这个模块对 root 以及已经登入
系统中的一般账号并没有影响。 (注意喔!这与 /etc/nologin.txt 并不相同!)
pam_selinux.so:
SELinux 是个针对程序来进行细部管理权限的功能,SELinux 这玩意儿我们会在第十六章的时候再来详细
谈论。由于 SELinux 会影响到用户执行程序的权限,因此我们利用 PAM 模块,将 SELinux 暂时关闭,
等到验证通过后, 再予以启动!
pam_console.so:
当系统出现某些问题,或者是某些时刻你需要使用特殊的终端接口 (例如 RS232 之类的终端联机设备) 登
入主机时, 这个模块可以帮助处理一些文件权限的问题,让使用者可以透过特殊终端接口 (console) 顺利
的登入系统。
pam_loginuid.so:
我们知道系统账号与一般账号的 UID 是不同的!一般账号 UID 均大于 1000 才合理。 因此,为了验证
使用者的 UID 真的是我们所需要的数值,可以使用这个模块来进行规范!
pam_env.so:
用来设定环境变量的一个模块,如果你有需要额外的环境变量设定,可以参考 /etc/security/pam_env.conf 这
个文件的详细说明。
pam_unix.so:
这是个很复杂且重要的模块,这个模块可以用在验证阶段的认证功能,可以用在授权阶段的账号许可证管
理, 可以用在会议阶段的登录文件记录等,甚至也可以用在密码更新阶段的检验!非常丰富的功能! 这
个模块在早期使用得相当频繁喔!
pam_pwquality.so:
可以用来检验密码的强度!包括密码是否在字典中,密码输入几次都失败就断掉此次联机等功能,都是这
模块提供的! 最早之前其实使用的是 pam_cracklib.so 这个模块,后来改成 pam_pwquality.so 这个模块,
但此模块完全兼容于 pam_cracklib.so, 同时提供了 /etc/security/pwquality.conf 这个文件可以额外指定默认
值!比较容易处理修改!
pam_limits.so:
还记得我们在第十章谈到的 ulimit 吗? 其实那就是这个模块提供的能力!还有更多细部的设定可以参考:
/etc/security/limits.conf 内的说明。
PAM 验证机制流程
验证阶段 (auth):
首先, (a)会先经过 pam_securetty.so 判断,如果使用者是 root 时,则会参考 /etc/securetty
的设定; 接下来(b)经过 pam_env.so 设定额外的环境变量;再©透过 pam_unix.so 检验密码,若通过则回报 login 程序;若不通过则(d)继续往下以 pam_succeed_if.so 判断 UID 是否大于 1000 ,若小于 1000 则
回报失败,否则再往下 (e)以 pam_deny.so 拒绝联机。
授权阶段 (account):
(a)先以 pam_nologin.so 判断 /etc/nologin 是否存在,若存在则不许一般使用者登入;
(b)接下来以 pam_unix.so 及 pam_localuser.so 进行账号管理,再以 © pam_succeed_if.so 判断 UID 是否
小于 1000 ,若小于 1000 则不记录登录信息。(d)最后以 pam_permit.so 允许该账号登入。
密码阶段 (password):
(a)先以 pam_pwquality.so 设定密码仅能尝试错误 3 次; (b)接下来以 pam_unix.so 透
过 sha512, shadow 等功能进行密码检验,若通过则回报 login 程序,若不通过则 ©以 pam_deny.so 拒绝
登入。
会议阶段 (session):
(a)先以 pam_selinux.so 暂时关闭 SELinux;(b)使用 pam_limits.so 设定好用户能够操
作的系统资源; ©登入成功后开始记录相关信息在登录文件中; (d)以 pam_loginuid.so 规范不同的 UID
权限;(e)开启 pam_selinux.so 的功能。
总之,就是依据验证类别 (type) 来看,然后先由 login 的设定值去查阅,如果出现『 include system-auth 』 就转到 system-auth 文件中的相同类别,去取得额外的验证流程就是了。然后再到下一个验证类别,最终将所有的验证跑完! 就结束这次的 PAM 验证啦!经过这样的验证流程,现在你知道为啥 /etc/nologin 存在会有问题,也会知道为何你使用一些远程联机机制时, 老是无法使用 root 登入的问题了吧?没错!这都是 PAM 模块提供的功能啦!
例题:
为什么 root 无法以 telnet 直接登入系统,但是却能够使用 ssh 直接登入?
答:
一般来说, telnet 会引用 login 的 PAM 模块,而 login 的验证阶段会有 /etc/securetty 的限制! 由于远程联机属于 pts/n (n 为数字) 的动态终端机接口装置名称,并没有写入到 /etc/securetty , 因此 root 无法以 telnet 登入远程主机。至于 ssh 使用的是 /etc/pam.d/sshd 这个模块, 你可以查阅一下该模块,由于该模块的验证阶段并没有加入 pam_securetty ,因此就没有 /etc/securetty 的限制!故可以从远程直接联机到服务器端。
其他相关文件
除了前一小节谈到的 /etc/securetty 会影响到 root 可登入的安全终端机, /etc/nologin 会影响到一般使用者是否能够登入的功能之外,我们也知道 PAM 相关的配置文件在 /etc/pam.d , 说明文件在/usr/share/doc/pam-(版本) ,模块实际在 /lib64/security/ 。那么还有没有相关的 PAM 文件呢? 是有的,主要都在 /etc/security 这个目录内!我们底下介绍几个可能会用到的配置文件喔!
limits.conf
我们在第十章谈到的 ulimit 功能中, 除了修改使用者的 ~/.bashrc 配置文件之外,其实系统管理员可以统一藉由 PAM 来管理的! 那就是 /etc/security/limits.conf 这个文件的设定了。这个文件的设定很简单,你可以自行参考一下该文件内容。 我们这里仅作个简单的介绍:
/var/log/secure, /var/log/messages
如果发生任何无法登入或者是产生一些你无法预期的错误时,由于 PAM 模块都会将数据记载在/var/log/secure 当中,所以发生了问题请务必到该文件内去查询一下问题点!举例来说, 我们在 limits.conf 的介绍内的范例二,就有谈到多重登入的错误可以到 /var/log/secure 内查阅了! 这样你也就知道为何第二个 pro1 无法登入啦!_