Linux認證的概念
RHCA(Red Hat Certified Architect)，是RedHat公司在2004年推出的頂級認證，也是Linux界公認的作業系統最高級認證。下面是小編整理的關於Linux認證的概念，歡迎大家參考!
Linux用戶認證方法簡介
當今IT環境中,任何計算機系統都要充分考慮設計、使用和運行過程中的安全性。所以在目前主流作業系統的各個環節當中都增加了很多安全方面的功能和特性，而在眾多的安全特性和功能中有相當多的技術是確保用戶鑑別和身份認證方面的安全性的。
所謂用戶鑑別，就是用戶向系統以一種安全的方式提交自己的身份證明，然後由系統確認用戶的身份是否屬實的過程。換句話說，用戶鑑別是系統的門戶，每個用戶進入到系統之前都必須經過鑑別這一道關。 而所謂認證安全，簡而言之就是計算機系統確認了用戶是經過授權的合法用戶之後才能允許訪問。安全認證最常用的方式是比對用戶輸入和預存於資料庫中的密碼。
不過在用戶進行身份鑑別和安全認證的過程中，肯定會涉及幾個核心問題。例如：
如何真正實現正確鑑別用戶的真實身份?
在鑑別用戶合法身份之後，如何確定用戶可以對哪些資源進行訪問?
如何控制用戶以何種方式來訪問計算機資源?
如何對用戶的安全訪問隨時隨地按需調整?
上述這些問題都是在設計鑑別和認證程序過程中需要充分考慮和精心設計的。而在Linux類的作業系統中，這些問題的處理實際上有一套完整的流程和機制。
在Linux類的作業系統中，最初用戶鑑別過程就像各種Unix作業系統一樣：系統管理員為用戶建立一個帳號並為其指定一個口令，用戶用此指定的口令登錄之後重新設置自己的口令，這樣用戶就具有了一個只有它自己知道的口令或者密碼。一般情況下，用戶的身份信息在Linux系統中存放在/etc/passwd文件當中，這實際上是一個擁有簡單格式的資料庫表，通過"："作為分隔符分隔出多個欄位，其中包括用戶的名稱、用戶ID、組ID、用戶說明、主目錄和登錄使用的shell等相關信息。而用戶口令經過加密處理後存放於/etc/shadow 文件中。也是一個格式類似的資料庫表，除了用戶名和經過加密之後的密碼之外，還包括多個對密碼有效期進行定義的欄位，包括密碼有效時間、密碼報警時間等。
用戶登錄的時候，登錄服務程序提示用戶輸入其用戶名和口令，然後將口令加密並與/etc/shadow 文件中對應帳號的加密口令進行比較，如果口令相匹配，說明用戶的身份屬實並允許此用戶訪問系統。這種思想基於只有用戶自己知道它的口令，所以輸入的口令是正確的話，那麼系統就認定它是所聲稱的那個人。
在Linux類作業系統中，定義用戶信息和密碼信息的欄位和格式都需要符合標準的Linux Naming Service Switch定義，即NSS定義。因此用戶信息只要保證滿足NSS規範，就可以來源於本地passwd和shadow之外的其它信息資料庫和認證源。所以在此基礎上還派生出一些其它認證解決方案。例如NIS、LDAP等，都可作為存放用戶信息的資料庫，而存放用戶口令或者鑑別用戶身份的資料庫，可以採用專用於網絡環境的Kerberos以及智慧卡鑑別系統等方式。
這一整套的鑑別和認證方案貌似無懈可擊，但是將這種解決方案真正應用到作業系統中的話就會發現一些問題：
第一，在作業系統上所包含的認證不僅僅只涉及到系統登錄和訪問，在系統外圍往往提供了眾多的應用程式，相當多的應用程式在訪問過程中是有認證需求的。那麼是否需要針對每一個應用程式都得加入認證和鑑別的功能?如果要，那麼無論從程序的開發和使用管理角度來講，工作量都將成倍增加;如果不要，則系統級的用戶鑑別和安全認證與應用程式沒有任何關係，意味著不管用戶是否需要登錄系統，但是對應用程式的訪問都將缺乏最基本的安全性。
第二，如果針對每一個應用程式都開發用戶鑑別和認證的功能，那麼一旦發現所用的算法存在某些缺陷或想採用另一種鑑別和認證方法時，開發者或者用戶都將不得不重寫(修改或替換)應用程式，然後重新編譯原程序。
所以，尤其是當實現鑑別功能的代碼以通常方法作為應用程式一部分一起編譯的時候，上述問題將十分突出。很明顯，傳統的身份鑑別和用戶認證方式一旦整合到實際的作業系統中，在實用當中缺乏靈活性。
鑒於以上原因，Linux作業系統的開發者和設計人員開始尋找一種更佳的替代方案：一方面，將鑑別功能從應用中獨立出來，單獨進行模塊化的設計，實現和維護;另一方面，為這些鑑別模塊建立標準的應用程式接口即API，以便眾多的應用程式能方便地使用它們提供的各種功能;同時，鑑別機制對上層用戶(包括應用程式和最終用戶)要求一定要是透明的，這樣可以對使用者隱藏其中比較複雜的實現細節。
可插拔認證模塊PAM的基本概念
事實上直到1995年的時候，SUN的研究人員才提出了一種滿足以上需求的方案，這就是可插拔認證模塊(Pluggable Authentication Module--PAM)機制，並首次在其作業系統 Solaris 2.3上部分實現。
可插拔認證模塊(PAM)機制採用模塊化設計和插件功能，使用戶可以輕易地在應用程式中插入新的認證模塊或替換原先的組件，同時不必對應用程式做任何修改，從而使軟體的定製、維持和升級更加輕鬆。因為認證和鑑別機制與應用程式之間相對獨立。所以應用程式可以通PAM API來方便地使用PAM提供的.各種鑑別功能而不必了解太多的底層細節。此外PAM的易用性也較強，主要表現在它對上層屏蔽了鑑別和認證的具體細節，所以用戶不必被迫學習各種各樣的鑑別方式，也不必記住多個口令;又由於它實現了多鑑別認證機制的集成問題，所以單個程序可以輕易集成多種鑑別機制，如Kerberos和Diffie - Hellman等認證機制，但用戶仍可以用同一個口令登錄而且感覺不到採取了各種不同的鑑別方法。
在廣大開發人員的努力下，各版本的UNIX系統陸續增加和提供了對PAM應用的支持。其中Linux-PAM是專門為Linux作業系統實現的，眾多的Linux作業系統包括Caldera、Debian、Turbo、Red Hat、SuSE 及它們的後續版本都提供對PAM的支持。而FreeBSD從3.1版本也開始支持PAM。而且除了具體實現方法上多少有些不同外，各種版本Unix系統上PAM的框架是相同的。所以我們在這裡介紹的Linux的PAM框架知識具有相當的普遍性，而且在下文介紹其框架過程中可以看到，我們並沒有刻意區分Unix PAM與Linux PAM這兩個技術術語。
PAM的分層體系結構
PAM 為了實現其插件功能和易用性，採取了分層設計思想。就是讓各鑑別模塊從應用程式中獨立出來，然後通過PAM API作為兩者聯繫的紐帶，這樣應用程式就可以根據需要靈活地在其中"插入"所需要的鑑別功能模塊，從而真正實現了在認證和鑑別基礎上的隨需應變。實際上，這一思路也非常符合軟體設計中的"高內聚，低耦合"這一重要思想。
PAM 的體系如下簡圖所示：
從上面的結構圖可以看出，PAM 的API起著承上啟下的作用，它是應用程式和認證鑑別模塊之間聯繫的紐帶和橋樑：當應用程式調用PAM API 時，應用接口層按照PAM配置文件的定義來加載相應的認證鑑別模塊。然後把請求(即從應用程式那裡得到的參數)傳遞給底層的認證鑑別模塊，這時認證鑑別模塊就可以根據要求執行具體的認證鑑別操作了。當認證鑑別模塊執行完相應的操作後，再將結果返回給應用接口層，然後由接口層根據配置的具體情況將來自認證鑑別模塊的應答返回給應用程式。
上面描述了PAM的各個組成部分以及整體的運作機理。下面將對PAM中的每一層分別加以介紹。
第一層：模塊層。模塊層處於整個PAM體系結構中的最底層，它向上為接口層提供用戶認證鑑別等服務。也就是說所有具體的認證鑑別工作都是由該層的模塊來完成的。對於應用程式，有些不但需要驗證用戶的口令，還可能要求驗證用戶的帳戶是否已經過期。此外有些應用程式也許還會要求記錄和更改當前所產生的會話類的相關信息或改變用戶口令等。所以PAM在模塊層除了提供鑑別模塊外，同時也提供了支持帳戶管理、會話管理以及口令管理功能的模塊。當然，這四種模塊並不是所有應用程式都必需的，而是根據需要靈活取捨。比如雖然login可能要求訪問上述所有的四種模塊,但是su可能僅僅需要使用到鑑別模塊的功能即可。至於如何取捨則涉及到接口層的PAM API和配置文件，這部分內容將在後文中加以介紹。
第二層：應用接口層。應用接口層位於PAM結構的中間部分，它向上為應用程式屏蔽了用戶鑑別等過程的具體細節，向下則調用模塊層中的具體模塊所提供的特定服務。由上圖可以看出，它主要由PAM API和配置文件兩部分組成，下面將逐一介紹。
PAM API可以分為兩類：一類是用於調用下層特定模塊的接口，這類接口與底層的模塊相對應，包括：
鑑別類接口：pam_authenticate()用於鑑別用戶身份，pam_setcred()用於修改用戶的私密信息。
帳號類接口：pam_acct_mgmt()用於檢查受鑑別的用戶所持帳戶是否有登錄系統許可，以及該帳戶是否已過期等。
會話類接口：包括用於會話管理和記帳的 pam_open_session()和 pam_close_session()函數。
口令類接口：包括用於修改用戶口令的 pam_chauthtok()。
第二類接口通常並不與底層模塊一一對應，它們的作用是對底層模塊提供支持以及實現應用程式與模塊之間的通信等。具體如下：
管理性接口： 每組 PAM 事務從 pam_start()開始，結束於 pam_end()函數。接口 pam_get_item()和 pam_set_item()用來讀寫與 PAM 事務有關的狀態信息。同時，能夠用 pam_str()輸出 PAM 接口的出錯信息。
應用程式與模塊間的通訊接口：在應用程式初始化期間，某些諸如用戶名之類的數據可以通過 pam_start()將其存放在PAM接口層中，以備將來底層模塊使用。另外底層模塊還可以使用 pam_putenv()向應用程式傳遞特定的環境變量，然後應用程式利用pam_getenv()和pam_getenvlist()讀取這些變量。
用戶與模塊間的通訊接口：pam_start()函數可以通過會話式的回調函數，讓底層模塊通過它們讀寫模塊相關的鑑別信息，比如以應用程式所規定的方式提示用戶輸入口令。
模塊間通訊接口：儘管各模塊是獨立的，但是它們仍然能夠通過pam_get_item()和pam_set_item()接口共享某些與鑑別會話有關的公用信息，諸如用戶名、服務名、口令等。此外，這些API還可以用於在調用pam_start()之後，讓應用程式修改狀態信息。
讀寫模塊狀態信息的接口：接口pam_get_data()和pam_set_data()用以按照PAM句柄要求訪問和更新特定模塊的信息。此外，還可以在這些模塊後附加一個清除數據函數，以便當調用 pam_end()時清除現場。
由於 PAM 模塊隨需加載,所以各模塊始化任務在第一次調用時完成。如果某些模塊的清除任務必須在鑑別會話結束時完成，則它們應該使用 pam_set_data()規定清除函數，這些執行清除任務的函數將在應用程式調用 pam_end()接口時被調用。
RHCA(Red Hat Certified Architect)，是RedHat公司在2004年推出的頂級認證，也是Linux界公認的作業系統最高級認證。下面是小編整理的關於Linux認證的概念，歡迎大家參考!
Linux用戶認證方法簡介
當今IT環境中,任何計算機系統都要充分考慮設計、使用和運行過程中的安全性。所以在目前主流作業系統的各個環節當中都增加了很多安全方面的功能和特性，而在眾多的安全特性和功能中有相當多的技術是確保用戶鑑別和身份認證方面的安全性的。
所謂用戶鑑別，就是用戶向系統以一種安全的方式提交自己的身份證明，然後由系統確認用戶的身份是否屬實的過程。換句話說，用戶鑑別是系統的門戶，每個用戶進入到系統之前都必須經過鑑別這一道關。 而所謂認證安全，簡而言之就是計算機系統確認了用戶是經過授權的合法用戶之後才能允許訪問。安全認證最常用的方式是比對用戶輸入和預存於資料庫中的密碼。
不過在用戶進行身份鑑別和安全認證的過程中，肯定會涉及幾個核心問題。例如：
如何真正實現正確鑑別用戶的真實身份?
在鑑別用戶合法身份之後，如何確定用戶可以對哪些資源進行訪問?
如何控制用戶以何種方式來訪問計算機資源?
如何對用戶的安全訪問隨時隨地按需調整?
上述這些問題都是在設計鑑別和認證程序過程中需要充分考慮和精心設計的。而在Linux類的作業系統中，這些問題的處理實際上有一套完整的流程和機制。
在Linux類的作業系統中，最初用戶鑑別過程就像各種Unix作業系統一樣：系統管理員為用戶建立一個帳號並為其指定一個口令，用戶用此指定的口令登錄之後重新設置自己的口令，這樣用戶就具有了一個只有它自己知道的口令或者密碼。一般情況下，用戶的身份信息在Linux系統中存放在/etc/passwd文件當中，這實際上是一個擁有簡單格式的資料庫表，通過"："作為分隔符分隔出多個欄位，其中包括用戶的名稱、用戶ID、組ID、用戶說明、主目錄和登錄使用的shell等相關信息。而用戶口令經過加密處理後存放於/etc/shadow 文件中。也是一個格式類似的資料庫表，除了用戶名和經過加密之後的密碼之外，還包括多個對密碼有效期進行定義的欄位，包括密碼有效時間、密碼報警時間等。
用戶登錄的時候，登錄服務程序提示用戶輸入其用戶名和口令，然後將口令加密並與/etc/shadow 文件中對應帳號的加密口令進行比較，如果口令相匹配，說明用戶的身份屬實並允許此用戶訪問系統。這種思想基於只有用戶自己知道它的口令，所以輸入的口令是正確的話，那麼系統就認定它是所聲稱的那個人。
在Linux類作業系統中，定義用戶信息和密碼信息的欄位和格式都需要符合標準的Linux Naming Service Switch定義，即NSS定義。因此用戶信息只要保證滿足NSS規範，就可以來源於本地passwd和shadow之外的其它信息資料庫和認證源。所以在此基礎上還派生出一些其它認證解決方案。例如NIS、LDAP等，都可作為存放用戶信息的資料庫，而存放用戶口令或者鑑別用戶身份的資料庫，可以採用專用於網絡環境的Kerberos以及智慧卡鑑別系統等方式。
這一整套的鑑別和認證方案貌似無懈可擊，但是將這種解決方案真正應用到作業系統中的話就會發現一些問題：
第一，在作業系統上所包含的認證不僅僅只涉及到系統登錄和訪問，在系統外圍往往提供了眾多的應用程式，相當多的應用程式在訪問過程中是有認證需求的。那麼是否需要針對每一個應用程式都得加入認證和鑑別的功能?如果要，那麼無論從程序的開發和使用管理角度來講，工作量都將成倍增加;如果不要，則系統級的用戶鑑別和安全認證與應用程式沒有任何關係，意味著不管用戶是否需要登錄系統，但是對應用程式的訪問都將缺乏最基本的安全性。
第二，如果針對每一個應用程式都開發用戶鑑別和認證的功能，那麼一旦發現所用的算法存在某些缺陷或想採用另一種鑑別和認證方法時，開發者或者用戶都將不得不重寫(修改或替換)應用程式，然後重新編譯原程序。
所以，尤其是當實現鑑別功能的代碼以通常方法作為應用程式一部分一起編譯的時候，上述問題將十分突出。很明顯，傳統的身份鑑別和用戶認證方式一旦整合到實際的作業系統中，在實用當中缺乏靈活性。
鑒於以上原因，Linux作業系統的開發者和設計人員開始尋找一種更佳的替代方案：一方面，將鑑別功能從應用中獨立出來，單獨進行模塊化的設計，實現和維護;另一方面，為這些鑑別模塊建立標準的應用程式接口即API，以便眾多的應用程式能方便地使用它們提供的各種功能;同時，鑑別機制對上層用戶(包括應用程式和最終用戶)要求一定要是透明的，這樣可以對使用者隱藏其中比較複雜的實現細節。
可插拔認證模塊PAM的基本概念
事實上直到1995年的時候，SUN的研究人員才提出了一種滿足以上需求的方案，這就是可插拔認證模塊(Pluggable Authentication Module--PAM)機制，並首次在其作業系統 Solaris 2.3上部分實現。
可插拔認證模塊(PAM)機制採用模塊化設計和插件功能，使用戶可以輕易地在應用程式中插入新的認證模塊或替換原先的組件，同時不必對應用程式做任何修改，從而使軟體的定製、維持和升級更加輕鬆。因為認證和鑑別機制與應用程式之間相對獨立。所以應用程式可以通PAM API來方便地使用PAM提供的.各種鑑別功能而不必了解太多的底層細節。此外PAM的易用性也較強，主要表現在它對上層屏蔽了鑑別和認證的具體細節，所以用戶不必被迫學習各種各樣的鑑別方式，也不必記住多個口令;又由於它實現了多鑑別認證機制的集成問題，所以單個程序可以輕易集成多種鑑別機制，如Kerberos和Diffie - Hellman等認證機制，但用戶仍可以用同一個口令登錄而且感覺不到採取了各種不同的鑑別方法。
在廣大開發人員的努力下，各版本的UNIX系統陸續增加和提供了對PAM應用的支持。其中Linux-PAM是專門為Linux作業系統實現的，眾多的Linux作業系統包括Caldera、Debian、Turbo、Red Hat、SuSE 及它們的後續版本都提供對PAM的支持。而FreeBSD從3.1版本也開始支持PAM。而且除了具體實現方法上多少有些不同外，各種版本Unix系統上PAM的框架是相同的。所以我們在這裡介紹的Linux的PAM框架知識具有相當的普遍性，而且在下文介紹其框架過程中可以看到，我們並沒有刻意區分Unix PAM與Linux PAM這兩個技術術語。
PAM的分層體系結構
PAM 為了實現其插件功能和易用性，採取了分層設計思想。就是讓各鑑別模塊從應用程式中獨立出來，然後通過PAM API作為兩者聯繫的紐帶，這樣應用程式就可以根據需要靈活地在其中"插入"所需要的鑑別功能模塊，從而真正實現了在認證和鑑別基礎上的隨需應變。實際上，這一思路也非常符合軟體設計中的"高內聚，低耦合"這一重要思想。
PAM 的體系如下簡圖所示：
從上面的結構圖可以看出，PAM 的API起著承上啟下的作用，它是應用程式和認證鑑別模塊之間聯繫的紐帶和橋樑：當應用程式調用PAM API 時，應用接口層按照PAM配置文件的定義來加載相應的認證鑑別模塊。然後把請求(即從應用程式那裡得到的參數)傳遞給底層的認證鑑別模塊，這時認證鑑別模塊就可以根據要求執行具體的認證鑑別操作了。當認證鑑別模塊執行完相應的操作後，再將結果返回給應用接口層，然後由接口層根據配置的具體情況將來自認證鑑別模塊的應答返回給應用程式。
上面描述了PAM的各個組成部分以及整體的運作機理。下面將對PAM中的每一層分別加以介紹。
第一層：模塊層。模塊層處於整個PAM體系結構中的最底層，它向上為接口層提供用戶認證鑑別等服務。也就是說所有具體的認證鑑別工作都是由該層的模塊來完成的。對於應用程式，有些不但需要驗證用戶的口令，還可能要求驗證用戶的帳戶是否已經過期。此外有些應用程式也許還會要求記錄和更改當前所產生的會話類的相關信息或改變用戶口令等。所以PAM在模塊層除了提供鑑別模塊外，同時也提供了支持帳戶管理、會話管理以及口令管理功能的模塊。當然，這四種模塊並不是所有應用程式都必需的，而是根據需要靈活取捨。比如雖然login可能要求訪問上述所有的四種模塊,但是su可能僅僅需要使用到鑑別模塊的功能即可。至於如何取捨則涉及到接口層的PAM API和配置文件，這部分內容將在後文中加以介紹。
第二層：應用接口層。應用接口層位於PAM結構的中間部分，它向上為應用程式屏蔽了用戶鑑別等過程的具體細節，向下則調用模塊層中的具體模塊所提供的特定服務。由上圖可以看出，它主要由PAM API和配置文件兩部分組成，下面將逐一介紹。
PAM API可以分為兩類：一類是用於調用下層特定模塊的接口，這類接口與底層的模塊相對應，包括：
鑑別類接口：pam_authenticate()用於鑑別用戶身份，pam_setcred()用於修改用戶的私密信息。
帳號類接口：pam_acct_mgmt()用於檢查受鑑別的用戶所持帳戶是否有登錄系統許可，以及該帳戶是否已過期等。
會話類接口：包括用於會話管理和記帳的 pam_open_session()和 pam_close_session()函數。
口令類接口：包括用於修改用戶口令的 pam_chauthtok()。
第二類接口通常並不與底層模塊一一對應，它們的作用是對底層模塊提供支持以及實現應用程式與模塊之間的通信等。具體如下：
管理性接口： 每組 PAM 事務從 pam_start()開始，結束於 pam_end()函數。接口 pam_get_item()和 pam_set_item()用來讀寫與 PAM 事務有關的狀態信息。同時，能夠用 pam_str()輸出 PAM 接口的出錯信息。
應用程式與模塊間的通訊接口：在應用程式初始化期間，某些諸如用戶名之類的數據可以通過 pam_start()將其存放在PAM接口層中，以備將來底層模塊使用。另外底層模塊還可以使用 pam_putenv()向應用程式傳遞特定的環境變量，然後應用程式利用pam_getenv()和pam_getenvlist()讀取這些變量。
用戶與模塊間的通訊接口：pam_start()函數可以通過會話式的回調函數，讓底層模塊通過它們讀寫模塊相關的鑑別信息，比如以應用程式所規定的方式提示用戶輸入口令。
模塊間通訊接口：儘管各模塊是獨立的，但是它們仍然能夠通過pam_get_item()和pam_set_item()接口共享某些與鑑別會話有關的公用信息，諸如用戶名、服務名、口令等。此外，這些API還可以用於在調用pam_start()之後，讓應用程式修改狀態信息。
讀寫模塊狀態信息的接口：接口pam_get_data()和pam_set_data()用以按照PAM句柄要求訪問和更新特定模塊的信息。此外，還可以在這些模塊後附加一個清除數據函數，以便當調用 pam_end()時清除現場。
由於 PAM 模塊隨需加載,所以各模塊始化任務在第一次調用時完成。如果某些模塊的清除任務必須在鑑別會話結束時完成，則它們應該使用 pam_set_data()規定清除函數，這些執行清除任務的函數將在應用程式調用 pam_end()接口時被調用。
收藏