等保測(cè)評(píng)：CentOS登錄失敗參數(shù)說明和雙因素認(rèn)證
本文上半部和等保聯(lián)絡(luò)不是很密切，還是說一了些linux里細(xì)節(jié)一些的東西，所以有可能會(huì)糟蹋你生命中的好幾分鐘，一起我運(yùn)用的是centos6。
一、登錄失利處理功用參數(shù)詳解
等保測(cè)評(píng)主機(jī)安全：CentOS暗碼修正周期與登錄失利處理，登錄失利處理功用的上半段內(nèi)容在這篇文章的下半部分，本篇文章主要說pam_tally2的參數(shù)所代表的的意思。
在測(cè)評(píng)時(shí)，設(shè)計(jì)登錄失利處理功用，就少不了要運(yùn)用pam_tally2（centos6和之后的版別），那么就有必要理解這個(gè)模塊各個(gè)參數(shù)（選項(xiàng)）的含義。
而網(wǎng)上關(guān)于pam_tally2參數(shù)材料，不能說不對(duì)，可是總覺得不夠詳細(xì)和全面，所以寫了這篇文章闡明闡明。
首要，先貼上常用的參數(shù)解說，保證來源部分不會(huì)出錯(cuò)，一起給出中文解說，我們能夠?qū)φ罩矗?br />
1.1. deny
這個(gè)就不用多說了，登錄失利次數(shù)一旦大于等于該數(shù)值，所登錄的賬號(hào)就會(huì)被確定。
1.2. lock_time
這個(gè)比較不常見，如同一般都不怎么說這個(gè)參數(shù)，這個(gè)參數(shù)的意思便是你每一次登錄失利后，在尚未到達(dá)deny所設(shè)置的次數(shù)時(shí)，會(huì)約束你登錄的時(shí)刻。
舉個(gè)例子，假如你設(shè)置deny是3，lock_time為10。那么你第1次和第2次登錄失利時(shí)，在10s內(nèi)的登錄是無效的，輸入啥都不會(huì)讓你登進(jìn)去的。
另外當(dāng)你到達(dá)了第3次登錄失利后，該參數(shù)失效，由unlock_time來接收。
1.3. unlock_time
這個(gè)就很常見了，意思便是當(dāng)你登錄失利的次數(shù)大于等于deny所設(shè)置的數(shù)值時(shí)，賬號(hào)確定的時(shí)刻，就不必多解說了吧？
1.4. magic_root
這個(gè)的意思也很簡(jiǎn)略，假如不包括這個(gè)參數(shù)，則哪怕是root也會(huì)添加失利計(jì)數(shù)，但留意，添加失利計(jì)數(shù)不代表root就會(huì)被確定，這是兩碼事。
在tally2的源代碼中表示如下（c言語）：
if (!(opts->ctrl & OPT_MAGIC_ROOT) || getuid) { /* magic_root doesn't change tally */ tally.fail_cnt += inc; if (tally.fail_cnt == TALLY_HI) { /* Overflow *and* underflow. */ tally.fail_cnt -= inc; pam_syslog(pamh, LOG_ALERT, "Tally %sflowed for user %s", (inc<0)?"under":"over",user); } }
if (!(opts->ctrl & OPT_MAGIC_ROOT) || getuid)很好解說，便是當(dāng)你傳入的參數(shù)中有magic_root選項(xiàng)且為root用戶時(shí)，整個(gè)表達(dá)式的值才為false，才不會(huì)去履行if內(nèi)的句子，也便是添加失利計(jì)數(shù)：tally.fail_cnt += inc。
傳入的參數(shù)中有magic_root選項(xiàng)，則!(opts->ctrl & OPT_MAGIC_ROOT)部分的bool值為false是root用戶，而getuid的返回值是當(dāng)時(shí)用戶的uid，所以該部分為0，轉(zhuǎn)為bool類型則為false，則此時(shí)||運(yùn)算符兩邊皆為false，所以不會(huì)履行。
而在源代碼的另外一處，tally_check函數(shù)中，有這樣的代碼：
if ((opts->ctrl & OPT_MAGIC_ROOT) && getuid == 0) { return PAM_SUCCESS; } /* magic_root skips tally check */
這個(gè)就更好解說了，假如存在magic_root參數(shù)，且是root賬號(hào)，就不經(jīng)過履行下面的代碼，直接返回成功了。
那么假如是root賬號(hào)，但沒有設(shè)置magic_root參數(shù)呢？其實(shí)也不一定會(huì)對(duì)root賬號(hào)進(jìn)行確定設(shè)置，請(qǐng)看下一個(gè)參數(shù)。
1.5. even_deny_root
意思便是說，有這個(gè)參數(shù)，只需到達(dá)了deny設(shè)定的值，root賬號(hào)照樣也會(huì)被確定。
在tally_check函數(shù)中，假如是root賬號(hào)，但沒有設(shè)置magic_root參數(shù)，則代碼會(huì)往下履行，其中有一個(gè)if判斷如下：
if (opts->deny != 0 && /* deny==0 means no deny */ tally->fail_cnt > opts->deny && /* tally>deny means exceeded */ ((opts->ctrl & OPT_DENY_ROOT) || uid)) { /* even_deny stops uid check */
留意看((opts->ctrl & OPT_DENY_ROOT) || uid))，意思假如沒有設(shè)置even_deny_root選項(xiàng)，且uid為0也便是root賬號(hào)的情況下，if句子塊的代碼就不會(huì)履行。
同樣反過來，只需設(shè)置even_deny_root選項(xiàng)，不管啥賬號(hào)，都會(huì)履行if句子塊的代碼。 或許沒有設(shè)置even_deny_root選項(xiàng)，但不是root賬號(hào)，也會(huì)履行if句子塊的代碼。
插一句，在tally2源代碼中，對(duì)傳入選項(xiàng)的解析階段，有這么一段：
else if ( ! strcmp( *argv, "even_deny_root_account" ) || ! strcmp( *argv, "even_deny_root" ) ) { log_phase_no_auth(pamh, phase, *argv); opts->ctrl |= OPT_DENY_ROOT; }
也便是說傳入even_deny_root_account如同也是能夠的，可能是為了兼容曾經(jīng)的版別什么的？
1.6. root_unlock_time
這個(gè)便是和even_deny_root合作運(yùn)用的，假如root賬號(hào)被確定，則它所確定的時(shí)刻。
這兒就有一個(gè)問題，假如只有even_deny_root選項(xiàng)，沒有設(shè)置root_unlock_time選項(xiàng)，root賬號(hào)會(huì)被確定多久？
解說中如同沒說，直接看tally2解析傳入選項(xiàng)的源代碼的倒數(shù)第二句：
if (opts->root_unlock_time == -1) opts->root_unlock_time = opts->unlock_time;
root_unlock_time的默認(rèn)值是-1，所以假如發(fā)現(xiàn)你沒有給它進(jìn)行設(shè)置，在最終，它就會(huì)等于unlock_time。
反過來，假如只有root_unlock_time而沒有even_deny_root，又會(huì)怎么樣？
能夠看tally2解析傳入選項(xiàng)的源代碼：
else if ( ! strncmp( *argv, "root_unlock_time=", 17 ) ) { log_phase_no_auth(pamh, phase, *argv); if ( sscanf((*argv)+17,"%ld",&opts->root_unlock_time) != 1 ) { pam_syslog(pamh, LOG_ERR, "bad number supplied: %s", *argv); return PAM_AUTH_ERR; } opts->ctrl |= OPT_DENY_ROOT; /* even_deny_root implied */ }
如同是假如傳入了root_unlock_time且能夠轉(zhuǎn)化為數(shù)字的話，就相當(dāng)于傳入了even_deny_root參數(shù)。
啰嗦了這么多，應(yīng)該把常用參數(shù)解說清楚了。
關(guān)于這些參數(shù)，假如光看網(wǎng)上搜的材料，發(fā)現(xiàn)有不清楚的地方，就應(yīng)該直接去看man里邊的解說。 假如解說里邊寫得也不夠理解，那么就直接看代碼。
不管怎么說，代碼總是功用的直接表現(xiàn)，是不會(huì)產(chǎn)生困惑的。
二、雙要素認(rèn)證
這一部分沒有特別明確的標(biāo)準(zhǔn)，所以僅為個(gè)人經(jīng)歷，而我又沒多少經(jīng)歷，所以假如有過錯(cuò)請(qǐng)見諒。
2.1. 堡壘機(jī)
其實(shí)常用的的做法便是，經(jīng)過堡壘機(jī)來管理服務(wù)器。 一起，堡壘機(jī)運(yùn)用雙要素認(rèn)證，從而直接的到達(dá)了服務(wù)器的雙要素認(rèn)證。
可是首要，這種方法如同不能被認(rèn)為是認(rèn)證：
不過假如就算被認(rèn)為是雙要素認(rèn)證，也有兩點(diǎn)值得留意。
第一點(diǎn)
堡壘機(jī)有必要強(qiáng)制運(yùn)用雙要素認(rèn)證方法，而不是任選一種方法進(jìn)行登錄。
第二點(diǎn)
堡壘機(jī)所管理的服務(wù)器，有必要對(duì)銜接方法進(jìn)行約束，經(jīng)過防火墻或許網(wǎng)絡(luò)設(shè)備什么的，保證只能經(jīng)過堡壘機(jī)進(jìn)行銜接。否則，就算堡壘機(jī)強(qiáng)制運(yùn)用雙要素認(rèn)證，但服務(wù)器還是能經(jīng)過長(zhǎng)途桌面或許ssh連上去，那堡壘機(jī)的雙要素認(rèn)證就含義不大了。
2.2. VPN
VPN方法和堡壘機(jī)有點(diǎn)像，vpn本身也能夠運(yùn)用雙要素進(jìn)行身份鑒別，比方SANGFOR SSL VPN，就能夠在控制臺(tái)中進(jìn)行設(shè)置（功用如同挺多的，能夠做很多設(shè)置）：
但要害的還是要看配置有沒有做全面：
第一點(diǎn)
只能經(jīng)過vpn銜接服務(wù)器，有些單位的內(nèi)網(wǎng)直接能夠用wifi連上，防火墻那也沒對(duì)拜訪服務(wù)器長(zhǎng)途端口的ip做出約束，只需連上wifi就能連服務(wù)器，那這種vpn的雙要素認(rèn)證就不能認(rèn)為是服務(wù)器的雙要素認(rèn)證。
或許假如對(duì)拜訪長(zhǎng)途端口的ip沒有做出約束，可是沒有內(nèi)網(wǎng)wifi，要連內(nèi)網(wǎng)就得拿網(wǎng)線跑去機(jī)房銜接的話，感覺也算是做了約束。
第二點(diǎn)
那天然便是登錄vpn要強(qiáng)制運(yùn)用雙要素認(rèn)證啦。
2.3. pam插件
另外一種比較雙要素認(rèn)證的方法，關(guān)于centos等linux體系，便是經(jīng)過運(yùn)用pam組件。
關(guān)于pam，請(qǐng)看等保測(cè)評(píng)主機(jī)安全：CentOS暗碼修正周期與登錄失利處理中的登錄失利處理功用部分，里邊對(duì)pam做了一個(gè)比較明晰的介紹。
不過這兒不妨能夠再說下，pam全名是可插拔認(rèn)證模塊，比方登錄linux體系時(shí)，驗(yàn)證用戶名暗碼其實(shí)便是經(jīng)過調(diào)用pam的一個(gè)驗(yàn)證模塊——pam_unix。
而這個(gè)模塊干的事情，也便是提示你輸入用戶名和暗碼，然后應(yīng)該是別離和passwd以及shadow文件進(jìn)行比照，最終返回成功或失利。
所以，想實(shí)現(xiàn)雙要素認(rèn)證，比方“用戶名/口令”+“手機(jī)短信”的認(rèn)證方法，完全能夠直接修正pam_unix模塊（c言語），添加“手機(jī)短信”驗(yàn)證功用。
又或許添加一個(gè)自定義驗(yàn)證模塊，里邊運(yùn)用手機(jī)短信驗(yàn)證，然后經(jīng)過配置文件中的控制符號(hào)，讓這個(gè)自定義的模塊和pam_unix模塊都成功才驗(yàn)證成功，也能實(shí)現(xiàn)作用。
至于詳細(xì)有沒有這樣的模塊?我們百度查找centos 雙要素認(rèn)證即可，詳細(xì)就不說了，網(wǎng)上的材料介紹得還是很明晰的。
2.4. ssh密鑰方法登錄
這個(gè)我也不知道是不是啊，可是我感覺如同能夠算是？
簡(jiǎn)略來說便是關(guān)于centos等linux體系，在ssh的配置文件中，禁掉用戶名、暗碼登錄方法，運(yùn)用密鑰（公鑰/私鑰）+私鑰暗碼的方法進(jìn)行登錄。
網(wǎng)上材料如下：
[root@host ~]$ ssh-keygen <== 樹立密鑰對(duì) Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): <== 按 Enter Created directory '/root/.ssh'. Enter passphrase (empty for no passphrase): <== 輸入密鑰鎖碼，或直接按 Enter 留空 Enter same passphrase again: <== 再輸入一遍密鑰鎖碼 Your identification has been saved in /root/.ssh/id_rsa. <== 私鑰 Your public key has been saved in /root/.ssh/id_rsa.pub. <== 公鑰 The key fingerprint is: 0f:d3:e7:1a:1c:bd:5c:03:f1:19:f1:22:df:9b:cc:08 root@host
留意，在樹立密鑰對(duì)的時(shí)分是能夠設(shè)置私鑰的暗碼的。
這樣，你進(jìn)行登錄的時(shí)分，比方運(yùn)用xshell進(jìn)行長(zhǎng)途銜接，用戶名本來就需要輸入，私鑰也要供給，私鑰的暗碼也要供給。
一、登錄失利處理功用參數(shù)詳解
等保測(cè)評(píng)主機(jī)安全：CentOS暗碼修正周期與登錄失利處理，登錄失利處理功用的上半段內(nèi)容在這篇文章的下半部分，本篇文章主要說pam_tally2的參數(shù)所代表的的意思。
在測(cè)評(píng)時(shí)，設(shè)計(jì)登錄失利處理功用，就少不了要運(yùn)用pam_tally2（centos6和之后的版別），那么就有必要理解這個(gè)模塊各個(gè)參數(shù)（選項(xiàng)）的含義。
而網(wǎng)上關(guān)于pam_tally2參數(shù)材料，不能說不對(duì)，可是總覺得不夠詳細(xì)和全面，所以寫了這篇文章闡明闡明。
首要，先貼上常用的參數(shù)解說，保證來源部分不會(huì)出錯(cuò)，一起給出中文解說，我們能夠?qū)φ罩矗?br />
1.1. deny
這個(gè)就不用多說了，登錄失利次數(shù)一旦大于等于該數(shù)值，所登錄的賬號(hào)就會(huì)被確定。
1.2. lock_time
這個(gè)比較不常見，如同一般都不怎么說這個(gè)參數(shù)，這個(gè)參數(shù)的意思便是你每一次登錄失利后，在尚未到達(dá)deny所設(shè)置的次數(shù)時(shí)，會(huì)約束你登錄的時(shí)刻。
舉個(gè)例子，假如你設(shè)置deny是3，lock_time為10。那么你第1次和第2次登錄失利時(shí)，在10s內(nèi)的登錄是無效的，輸入啥都不會(huì)讓你登進(jìn)去的。
另外當(dāng)你到達(dá)了第3次登錄失利后，該參數(shù)失效，由unlock_time來接收。
1.3. unlock_time
這個(gè)就很常見了，意思便是當(dāng)你登錄失利的次數(shù)大于等于deny所設(shè)置的數(shù)值時(shí)，賬號(hào)確定的時(shí)刻，就不必多解說了吧？
1.4. magic_root
這個(gè)的意思也很簡(jiǎn)略，假如不包括這個(gè)參數(shù)，則哪怕是root也會(huì)添加失利計(jì)數(shù)，但留意，添加失利計(jì)數(shù)不代表root就會(huì)被確定，這是兩碼事。
在tally2的源代碼中表示如下（c言語）：
if (!(opts->ctrl & OPT_MAGIC_ROOT) || getuid) { /* magic_root doesn't change tally */ tally.fail_cnt += inc; if (tally.fail_cnt == TALLY_HI) { /* Overflow *and* underflow. */ tally.fail_cnt -= inc; pam_syslog(pamh, LOG_ALERT, "Tally %sflowed for user %s", (inc<0)?"under":"over",user); } }
if (!(opts->ctrl & OPT_MAGIC_ROOT) || getuid)很好解說，便是當(dāng)你傳入的參數(shù)中有magic_root選項(xiàng)且為root用戶時(shí)，整個(gè)表達(dá)式的值才為false，才不會(huì)去履行if內(nèi)的句子，也便是添加失利計(jì)數(shù)：tally.fail_cnt += inc。
傳入的參數(shù)中有magic_root選項(xiàng)，則!(opts->ctrl & OPT_MAGIC_ROOT)部分的bool值為false是root用戶，而getuid的返回值是當(dāng)時(shí)用戶的uid，所以該部分為0，轉(zhuǎn)為bool類型則為false，則此時(shí)||運(yùn)算符兩邊皆為false，所以不會(huì)履行。
而在源代碼的另外一處，tally_check函數(shù)中，有這樣的代碼：
if ((opts->ctrl & OPT_MAGIC_ROOT) && getuid == 0) { return PAM_SUCCESS; } /* magic_root skips tally check */
這個(gè)就更好解說了，假如存在magic_root參數(shù)，且是root賬號(hào)，就不經(jīng)過履行下面的代碼，直接返回成功了。
那么假如是root賬號(hào)，但沒有設(shè)置magic_root參數(shù)呢？其實(shí)也不一定會(huì)對(duì)root賬號(hào)進(jìn)行確定設(shè)置，請(qǐng)看下一個(gè)參數(shù)。
1.5. even_deny_root
意思便是說，有這個(gè)參數(shù)，只需到達(dá)了deny設(shè)定的值，root賬號(hào)照樣也會(huì)被確定。
在tally_check函數(shù)中，假如是root賬號(hào)，但沒有設(shè)置magic_root參數(shù)，則代碼會(huì)往下履行，其中有一個(gè)if判斷如下：
if (opts->deny != 0 && /* deny==0 means no deny */ tally->fail_cnt > opts->deny && /* tally>deny means exceeded */ ((opts->ctrl & OPT_DENY_ROOT) || uid)) { /* even_deny stops uid check */
留意看((opts->ctrl & OPT_DENY_ROOT) || uid))，意思假如沒有設(shè)置even_deny_root選項(xiàng)，且uid為0也便是root賬號(hào)的情況下，if句子塊的代碼就不會(huì)履行。
同樣反過來，只需設(shè)置even_deny_root選項(xiàng)，不管啥賬號(hào)，都會(huì)履行if句子塊的代碼。 或許沒有設(shè)置even_deny_root選項(xiàng)，但不是root賬號(hào)，也會(huì)履行if句子塊的代碼。
插一句，在tally2源代碼中，對(duì)傳入選項(xiàng)的解析階段，有這么一段：
else if ( ! strcmp( *argv, "even_deny_root_account" ) || ! strcmp( *argv, "even_deny_root" ) ) { log_phase_no_auth(pamh, phase, *argv); opts->ctrl |= OPT_DENY_ROOT; }
也便是說傳入even_deny_root_account如同也是能夠的，可能是為了兼容曾經(jīng)的版別什么的？
1.6. root_unlock_time
這個(gè)便是和even_deny_root合作運(yùn)用的，假如root賬號(hào)被確定，則它所確定的時(shí)刻。
這兒就有一個(gè)問題，假如只有even_deny_root選項(xiàng)，沒有設(shè)置root_unlock_time選項(xiàng)，root賬號(hào)會(huì)被確定多久？
解說中如同沒說，直接看tally2解析傳入選項(xiàng)的源代碼的倒數(shù)第二句：
if (opts->root_unlock_time == -1) opts->root_unlock_time = opts->unlock_time;
root_unlock_time的默認(rèn)值是-1，所以假如發(fā)現(xiàn)你沒有給它進(jìn)行設(shè)置，在最終，它就會(huì)等于unlock_time。
反過來，假如只有root_unlock_time而沒有even_deny_root，又會(huì)怎么樣？
能夠看tally2解析傳入選項(xiàng)的源代碼：
else if ( ! strncmp( *argv, "root_unlock_time=", 17 ) ) { log_phase_no_auth(pamh, phase, *argv); if ( sscanf((*argv)+17,"%ld",&opts->root_unlock_time) != 1 ) { pam_syslog(pamh, LOG_ERR, "bad number supplied: %s", *argv); return PAM_AUTH_ERR; } opts->ctrl |= OPT_DENY_ROOT; /* even_deny_root implied */ }
如同是假如傳入了root_unlock_time且能夠轉(zhuǎn)化為數(shù)字的話，就相當(dāng)于傳入了even_deny_root參數(shù)。
啰嗦了這么多，應(yīng)該把常用參數(shù)解說清楚了。
關(guān)于這些參數(shù)，假如光看網(wǎng)上搜的材料，發(fā)現(xiàn)有不清楚的地方，就應(yīng)該直接去看man里邊的解說。 假如解說里邊寫得也不夠理解，那么就直接看代碼。
不管怎么說，代碼總是功用的直接表現(xiàn)，是不會(huì)產(chǎn)生困惑的。
二、雙要素認(rèn)證
這一部分沒有特別明確的標(biāo)準(zhǔn)，所以僅為個(gè)人經(jīng)歷，而我又沒多少經(jīng)歷，所以假如有過錯(cuò)請(qǐng)見諒。
2.1. 堡壘機(jī)
其實(shí)常用的的做法便是，經(jīng)過堡壘機(jī)來管理服務(wù)器。 一起，堡壘機(jī)運(yùn)用雙要素認(rèn)證，從而直接的到達(dá)了服務(wù)器的雙要素認(rèn)證。
可是首要，這種方法如同不能被認(rèn)為是認(rèn)證：
不過假如就算被認(rèn)為是雙要素認(rèn)證，也有兩點(diǎn)值得留意。
第一點(diǎn)
堡壘機(jī)有必要強(qiáng)制運(yùn)用雙要素認(rèn)證方法，而不是任選一種方法進(jìn)行登錄。
第二點(diǎn)
堡壘機(jī)所管理的服務(wù)器，有必要對(duì)銜接方法進(jìn)行約束，經(jīng)過防火墻或許網(wǎng)絡(luò)設(shè)備什么的，保證只能經(jīng)過堡壘機(jī)進(jìn)行銜接。否則，就算堡壘機(jī)強(qiáng)制運(yùn)用雙要素認(rèn)證，但服務(wù)器還是能經(jīng)過長(zhǎng)途桌面或許ssh連上去，那堡壘機(jī)的雙要素認(rèn)證就含義不大了。
2.2. VPN
VPN方法和堡壘機(jī)有點(diǎn)像，vpn本身也能夠運(yùn)用雙要素進(jìn)行身份鑒別，比方SANGFOR SSL VPN，就能夠在控制臺(tái)中進(jìn)行設(shè)置（功用如同挺多的，能夠做很多設(shè)置）：
但要害的還是要看配置有沒有做全面：
第一點(diǎn)
只能經(jīng)過vpn銜接服務(wù)器，有些單位的內(nèi)網(wǎng)直接能夠用wifi連上，防火墻那也沒對(duì)拜訪服務(wù)器長(zhǎng)途端口的ip做出約束，只需連上wifi就能連服務(wù)器，那這種vpn的雙要素認(rèn)證就不能認(rèn)為是服務(wù)器的雙要素認(rèn)證。
或許假如對(duì)拜訪長(zhǎng)途端口的ip沒有做出約束，可是沒有內(nèi)網(wǎng)wifi，要連內(nèi)網(wǎng)就得拿網(wǎng)線跑去機(jī)房銜接的話，感覺也算是做了約束。
第二點(diǎn)
那天然便是登錄vpn要強(qiáng)制運(yùn)用雙要素認(rèn)證啦。
2.3. pam插件
另外一種比較雙要素認(rèn)證的方法，關(guān)于centos等linux體系，便是經(jīng)過運(yùn)用pam組件。
關(guān)于pam，請(qǐng)看等保測(cè)評(píng)主機(jī)安全：CentOS暗碼修正周期與登錄失利處理中的登錄失利處理功用部分，里邊對(duì)pam做了一個(gè)比較明晰的介紹。
不過這兒不妨能夠再說下，pam全名是可插拔認(rèn)證模塊，比方登錄linux體系時(shí)，驗(yàn)證用戶名暗碼其實(shí)便是經(jīng)過調(diào)用pam的一個(gè)驗(yàn)證模塊——pam_unix。
而這個(gè)模塊干的事情，也便是提示你輸入用戶名和暗碼，然后應(yīng)該是別離和passwd以及shadow文件進(jìn)行比照，最終返回成功或失利。
所以，想實(shí)現(xiàn)雙要素認(rèn)證，比方“用戶名/口令”+“手機(jī)短信”的認(rèn)證方法，完全能夠直接修正pam_unix模塊（c言語），添加“手機(jī)短信”驗(yàn)證功用。
又或許添加一個(gè)自定義驗(yàn)證模塊，里邊運(yùn)用手機(jī)短信驗(yàn)證，然后經(jīng)過配置文件中的控制符號(hào)，讓這個(gè)自定義的模塊和pam_unix模塊都成功才驗(yàn)證成功，也能實(shí)現(xiàn)作用。
至于詳細(xì)有沒有這樣的模塊?我們百度查找centos 雙要素認(rèn)證即可，詳細(xì)就不說了，網(wǎng)上的材料介紹得還是很明晰的。
2.4. ssh密鑰方法登錄
這個(gè)我也不知道是不是啊，可是我感覺如同能夠算是？
簡(jiǎn)略來說便是關(guān)于centos等linux體系，在ssh的配置文件中，禁掉用戶名、暗碼登錄方法，運(yùn)用密鑰（公鑰/私鑰）+私鑰暗碼的方法進(jìn)行登錄。
網(wǎng)上材料如下：
[root@host ~]$ ssh-keygen <== 樹立密鑰對(duì) Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): <== 按 Enter Created directory '/root/.ssh'. Enter passphrase (empty for no passphrase): <== 輸入密鑰鎖碼，或直接按 Enter 留空 Enter same passphrase again: <== 再輸入一遍密鑰鎖碼 Your identification has been saved in /root/.ssh/id_rsa. <== 私鑰 Your public key has been saved in /root/.ssh/id_rsa.pub. <== 公鑰 The key fingerprint is: 0f:d3:e7:1a:1c:bd:5c:03:f1:19:f1:22:df:9b:cc:08 root@host
留意，在樹立密鑰對(duì)的時(shí)分是能夠設(shè)置私鑰的暗碼的。
這樣，你進(jìn)行登錄的時(shí)分，比方運(yùn)用xshell進(jìn)行長(zhǎng)途銜接，用戶名本來就需要輸入，私鑰也要供給，私鑰的暗碼也要供給。
