## 13.5 使用者的特殊 shell 與 PAM 模塊 我們前面一直談到的大多是一般身份使用者與系統管理員 （root） 的相關操作， 而且大多是討論關于可登陸系統的帳號來說。那么換個角度想，如果我今天想要創建的， 是一個“僅能使用 mail server 相關郵件服務的帳號，而該帳號并不能登陸 Linux 主機”呢？如果不能給予該帳號一個密碼，那么該帳號就無法使用系統的各項資源，當然也包括 mail 的資源， 而如果給予一個密碼，那么該帳號就可能可以登陸 Linux 主機啊！呵呵～傷腦筋吧～ 所以，下面讓我們來談一談這些有趣的話題啰！ 另外，在本章之前談到過 [/etc/login.defs](../Text/index.html#login.defs) 文件中，關于密碼長度應該默認是 5 個字串長度，但是我們上面也談到，該設置值已經被 PAM 模塊所取代了，那么 PAM 是什么？為什么他可以影響我們使用者的登陸呢？這里也要來談談的！ ### 13.5.1 特殊的 shell, /sbin/nologin 在本章一開頭的 [passwd 文件結構](../Text/index.html#passwd_file)里面我們就談過系統帳號這玩意兒，這玩意兒的 shell 就是使用 /sbin/nologin ，重點在于系統帳號是不需要登陸的！所以我們就給他這個無法登陸的合法 shell。 使用了這個 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 這個文件的內容，而不是默認的內容了！ 例題：當使用者嘗試利用純 mail 帳號 （例如 myuser3） 時，利用 /etc/nologin.txt 告知使用者不要利用該帳號登陸系統。答：直接以 vim 編輯該文件，內容可以是這樣： ``` [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. ``` 想要測試時，可以使用 myuser3 （此帳號的 shell 是 /sbin/nologin） 來測試看看！ ``` [root@study ~]# su - myuser3 This account is system account or mail account. Please DO NOT use this account to login my Linux server. ``` 結果會發現與原本的默認訊息不一樣喔！ ^_^ ### 13.5.2 PAM 模塊簡介 在過去，我們想要對一個使用者進行認證 （authentication），得要要求使用者輸入帳號密碼， 然后通過自行撰寫的程序來判斷該帳號密碼是否正確。也因為如此，我們常常得使用不同的機制來判斷帳號密碼， 所以搞的一部主機上面擁有多個各別的認證系統，也造成帳號密碼可能不同步的驗證問題！ 為了解決這個問題因此有了 PAM （Pluggable Authentication Modules, 嵌入式模塊） 的機制！ PAM 可以說是一套應用程序接口 （Application Programming Interface, API），他提供了一連串的驗證機制，只要使用者將驗證階段的需求告知 PAM 后， PAM 就能夠回報使用者驗證的結果 （成功或失敗）。由于 PAM 僅是一套驗證的機制，又可以提供給其他程序所調用引用，因此不論你使用什么程序，都可以使用 PAM 來進行驗證，如此一來，就能夠讓帳號密碼或者是其他方式的驗證具有一致的結果！也讓程序設計師方便處理驗證的問題喔！ [[5]](#ps5) 圖13.5.1、PAM 模塊與其他程序的相關性 如上述的圖示， PAM 是一個獨立的 API 存在，只要任何程序有需求時，可以向 PAM 發出驗證要求的通知， PAM 經過一連串的驗證后，將驗證的結果回報給該程序，然后該程序就能夠利用驗證的結果來進行可登陸或顯示其他無法使用的訊息。 這也就是說，你可以在寫程序的時候將 PAM 模塊的功能加入，就能夠利用 PAM 的驗證功能啰。 因此目前很多程序都會利用 PAM 喔！所以我們才要來學習他啊！ PAM 用來進行驗證的數據稱為模塊 （Modules），每個 PAM 模塊的功能都不太相同。舉例來說， 還記得我們在本章使用 [passwd](../Text/index.html#passwd) 指令時，如果隨便輸入字典上面找的到的字串， passwd 就會回報錯誤信息了！這是為什么呢？這就是 PAM 的 pam_cracklib.so 模塊的功能！他能夠判斷該密碼是否在字典里面！ 并回報給密碼修改程序，此時就能夠了解你的密碼強度了。 所以，當你有任何需要判斷是否在字典當中的密碼字串時，就可以使用 pam_cracklib.so 這個模塊來驗證！ 并根據驗證的回報結果來撰寫你的程序呢！這樣說，可以理解 PAM 的功能了吧？ ### 13.5.3 PAM 模塊設置語法 PAM 借由一個與程序相同文件名的配置文件來進行一連串的認證分析需求。我們同樣以 passwd 這個指令的調用 PAM 來說明好了。 當你執行 passwd 后，這支程序調用 PAM 的流程是： 1. 使用者開始執行 /usr/bin/passwd 這支程序，并輸入密碼； 2. passwd 調用 PAM 模塊進行驗證； 3. PAM 模塊會到 /etc/pam.d/ 找尋與程序 （passwd） 同名的配置文件； 4. 依據 /etc/pam.d/passwd 內的設置，引用相關的 PAM 模塊逐步進行驗證分析； 5. 將驗證結果 （成功、失敗以及其他訊息） 回傳給 passwd 這支程序； 6. 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 password substack system-auth -password optional pam_gnome_keyring.so use_authtok password substack postlogin 驗證類別 控制標準 PAM 模塊與該模塊的參數 ``` 在這個配置文件當中，除了第一行宣告 PAM 版本之外，其他任何“ # ”開頭的都是注解，而每一行都是一個獨立的驗證流程， 每一行可以區分為三個字段，分別是驗證類別（type）、控制標準（flag）、PAM的模塊與該模塊的參數。 下面我們先來談談驗證類別與控制標準這兩項數據吧！  **Tips** 你會發現在我們上面的表格當中出現的是“ include （包括） ”這個關鍵字，他代表的是“請調用后面的文件來作為這個類別的驗證”， 所以，上述的每一行都要重復調用 /etc/pam.d/system-auth 那個文件來進行驗證的意思！ * 第一個字段：驗證類別 （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） 那么“驗證的控制旗標（control flag）”又是什么？簡單的說，他就是“驗證通過的標準”啦！ 這個字段在管控該驗證的放行方式，主要也分為四種控制方式： * required 此驗證若成功則帶有 success （成功） 的標志，若失敗則帶有 failure 的標志，但不論成功或失敗都會繼續后續的驗證流程。 由于后續的驗證流程可以繼續進行，因此相當有利于數據的登錄 （log） ，這也是 PAM 最常使用 required 的原因。 * requisite 若驗證失敗則立刻回報原程序 failure 的標志，并終止后續的驗證流程。若驗證成功則帶有 success 的標志并繼續后續的驗證流程。 這個項目與 required 最大的差異，就在于失敗的時候還要不要繼續驗證下去？由于 requisite 是失敗就終止， 因此失敗時所產生的 PAM 信息就無法通過后續的模塊來記錄了。 * sufficient 若驗證成功則立刻回傳 success 給原程序，并終止后續的驗證流程；若驗證失敗則帶有 failure 標志并繼續后續的驗證流程。 這玩意兒與 requisits 剛好相反！ * optional 這個模塊控制項目大多是在顯示訊息而已，并不是用在驗證方面的。 如果將這些控制旗標以圖示的方式配合成功與否的條件繪圖，會有點像下面這樣： 圖13.5.2、PAM 控制旗標所造成的回報流程 程序運行過程中遇到驗證時才會去調用 PAM ，而 PAM 驗證又分很多類型與控制，不同的控制旗標所回報的訊息并不相同。 如上圖所示， requisite 失敗就回報了并不會繼續，而 sufficient 則是成功就回報了也不會繼續。 至于驗證結束后所回報的信息通常是“succes 或 failure ”而已，后續的流程還需要該程序的判斷來繼續執行才行。 ### 13.5.4 常用模塊簡介 談完了配置文件的語法后，現在讓我們來查閱一下 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 context session 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] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so ``` 上面這個表格當中使用到非常多的 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 這玩意兒我們會在[第十六章](../Text/index.html)的時候再來詳細談論。由于 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](../Text/index.html#variable_ulimit) 嗎？ 其實那就是這個模塊提供的能力！還有更多細部的設置可以參考： /etc/security/limits.conf 內的說明。 了解了這些模塊的大致功能后，言歸正傳，討論一下 login 的 PAM 驗證機制流程是這樣的： 1. 驗證階段 （auth）：首先，（a）會先經過 pam_securetty.so 判斷，如果使用者是 root 時，則會參考 /etc/securetty 的設置； 接下來（b）經過 pam_env.so 設置額外的環境變量；再（c）通過 pam_unix.so 檢驗密碼，若通過則回報 login 程序；若不通過則（d）繼續往下以 pam_succeed_if.so 判斷 UID 是否大于 1000 ，若小于 1000則回報失敗，否則再往下 （e）以 pam_deny.so 拒絕連線。 2. 授權階段 （account）：（a）先以 pam_nologin.so 判斷 /etc/nologin 是否存在，若存在則不許一般使用者登陸； （b）接下來以 pam_unix.so 及 pam_localuser.so 進行帳號管理，再以 （c） pam_succeed_if.so 判斷 UID 是否小于 1000 ，若小于 1000 則不記錄登錄信息。（d）最后以 pam_permit.so 允許該帳號登陸。 3. 密碼階段 （password）：（a）先以 pam_pwquality.so 設置密碼僅能嘗試錯誤 3 次；（b）接下來以 pam_unix.so 通過 sha512, shadow 等功能進行密碼檢驗，若通過則回報 login 程序，若不通過則 （c）以 pam_deny.so 拒絕登陸。 4. 會議階段 （session）：（a）先以 pam_selinux.so 暫時關閉 SELinux；（b）使用 pam_limits.so 設置好使用者能夠操作的系統資源； （c）登陸成功后開始記錄相關信息在登錄文件中； （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 的限制！故可以從遠端直接連線到服務器端。 另外，關于 telnet 與 ssh 的細部說明，請參考[鳥哥的 Linux 私房菜服務器篇](http://linux.vbird.org/linux_server) ### 13.5.5 其他相關文件 除了前一小節談到的 /etc/securetty 會影響到 root 可登陸的安全終端機， /etc/nologin 會影響到一般使用者是否能夠登陸的功能之外，我們也知道 PAM 相關的配置文件在 /etc/pam.d ， 說明文檔在 /usr/share/doc/pam-（版本） ，模塊實際在 /lib64/security/ 。那么還有沒有相關的 PAM 文件呢？ 是有的，主要都在 /etc/security 這個目錄內！我們下面介紹幾個可能會用到的配置文件喔！ * limits.conf 我們在第十章談到的 [ulimit](../Text/index.html#variable_ulimit) 功能中， 除了修改使用者的 ~/.bashrc 配置文件之外，其實系統管理員可以統一借由 PAM 來管理的！ 那就是 /etc/security/limits.conf 這個文件的設置了。這個文件的設置很簡單，你可以自行參考一下該文件內容。 我們這里僅作個簡單的介紹： ``` 范例一：vbird1 這個用戶只能創建 100MB 的文件，且大于 90MB 會警告 [root@study ~]# vim /etc/security/limits.conf vbird1 soft fsize 90000 vbird1 hard fsize 100000 #帳號 限制依據 限制項目 限制值 # 第一字段為帳號，或者是群組！若為群組則前面需要加上 @ ，例如 @projecta # 第二字段為限制的依據，是嚴格（hard），還是僅為警告（soft）； # 第三字段為相關限制，此例中限制文件大小， # 第四字段為限制的值，在此例中單位為 KB。 # 若以 vbird1 登陸后，進行如下的操作則會有相關的限制出現！ [vbird1@study ~]$ ulimit -a ....（前面省略）.... file size （blocks, -f） 90000 ....（后面省略）.... [vbird1@study ~]$ dd if=/dev/zero of=test bs=1M count=110 File size limit exceeded [vbird1@study ~]$ ll --block-size=K test -rw-rw-r--. 1 vbird1 vbird1 90000K Jul 22 01:33 test # 果然有限制到了 范例二：限制 pro1 這個群組，每次僅能有一個使用者登陸系統 （maxlogins） [root@study ~]# vim /etc/security/limits.conf @pro1 hard maxlogins 1 # 如果要使用群組功能的話，這個功能似乎對初始群組才有效喔！而如果你嘗試多個 pro1 的登陸時， # 第二個以后就無法登陸了。而且在 /var/log/secure 文件中還會出現如下的信息： # pam_limits（login:session）: Too many logins （max 1） for pro1 ``` 這個文件挺有趣的，而且是設置完成就生效了，你不用重新啟動任何服務的！ 但是 PAM 有個特殊的地方，由于他是在程序調用時才予以設置的，因此你修改完成的數據， 對于已登陸系統中的使用者是沒有效果的，要等他再次登陸時才會生效喔！另外， 上述的設置請在測試完成后立刻注解掉，否則下次這兩個使用者登陸就會發生些許問題啦！ ^_^ * /var/log/secure, /var/log/messages 如果發生任何無法登陸或者是產生一些你無法預期的錯誤時，由于 PAM 模塊都會將數據記載在 /var/log/secure 當中，所以發生了問題請務必到該文件內去查詢一下問題點！舉例來說， 我們在 [limits.conf](../Text/index.html#limits) 的介紹內的范例二，就有談到多重登陸的錯誤可以到 /var/log/secure 內查閱了！ 這樣你也就知道為何第二個 pro1 無法登陸啦！^_^