OpenSSH 密鑰管理，第 3 部分

socyno

代理程序轉(zhuǎn)發(fā)和 keychain 改進(jìn)




文檔選項(xiàng)



未顯示需要 JavaScript
的文檔選項(xiàng)


將此頁(yè)作為電子郵件發(fā)送
級(jí)別: 初級(jí)
Daniel Robbins
, 總裁兼首席執(zhí)行官, Gentoo Technologies，Inc.
2002 年  2 月  01 日
在這一系列的第三篇文章中，Daniel Robbins 向您顯示了如何利用 OpenSSH 代理程序連接轉(zhuǎn)發(fā)來(lái)增強(qiáng)安全性。他還共享 keychain shell 腳本近期的改進(jìn)。
      
      
我們中的許多人都使用非常優(yōu)秀的 OpenSSH 作為古老的
        
        telnet 和
        
        rsh
命令的替代品，OpenSSH 不僅安全而且是加密的。OpenSSH 更吸引人的特性之一是它能夠使用以一對(duì)互補(bǔ)的數(shù)字式“密鑰”為基礎(chǔ)的 RSA
和 DSA 認(rèn)證協(xié)議來(lái)認(rèn)證用戶。RSA 和 DSA
認(rèn)證承諾不必提供密碼就能夠與遠(yuǎn)程系統(tǒng)建立連接，這是其主要魅力之一。有關(guān)更多背景資料，請(qǐng)參閱關(guān)于 OpenSSH
密鑰管理的本系列文章中以前的幾篇，分別包括
RSA/DSA 認(rèn)證
（第 1 部分）和
        
        
ssh-agent 和 keychain
（第 2 部分）。
      
      
      
      
由于第 2 部分發(fā)表在 2001 年 9 月的
        
        developerWorks上，并且稍后在 Slashdot 和 Freshmeat（請(qǐng)參閱本文后面的
        
        
參考資料
，獲取到這些站點(diǎn)的鏈接）上引用了此文，因此，許多人已經(jīng)開(kāi)始使用
        
        keychain ，而且它已經(jīng)做了許多更改。我收到了世界各地開(kāi)發(fā)人員編寫(xiě)的約 20 個(gè)高質(zhì)量的補(bǔ)丁程序。我已將其中許多補(bǔ)丁代碼合并入
        
        keychain 源碼中，它目前的版本是 1.8（請(qǐng)參閱
        
        
參考資料
）。我真誠(chéng)地感謝所有提交補(bǔ)丁程序、錯(cuò)誤報(bào)告、功能請(qǐng)求及感謝信的那些人。
      
      
      
      
加強(qiáng) ssh 安全性
      
      
在
        
        
上篇文章
中，我花了一些時(shí)間來(lái)討論運(yùn)行
        
        ssh-agent 在安全性方面的利弊。第二篇文章發(fā)表在
        
        developerWorks的幾天后，我收到來(lái)自 Sarnoff Corporation 的 Charles Karney 的一封電子郵件，他非常禮貌地通知了我 OpenSSH 新的認(rèn)證代理程序轉(zhuǎn)發(fā)的能力，我們將會(huì)簡(jiǎn)要地討論這一能力。另外，Charles 強(qiáng)調(diào)：在
        
        不可信機(jī)器上運(yùn)行
        
        ssh-agent 是十分危險(xiǎn)的：如果有人成功地獲取系統(tǒng)上的 root 訪問(wèn)權(quán)，那么就
        
        能從
        
        ssh-agent 中抽取您解密的密鑰。即使抽取密鑰有一定的困難，但是它還是在專業(yè)的解密高手的能力范圍之內(nèi)。而且，基本事實(shí)就是偷竊私鑰是
        
        可能的，這意味著我們應(yīng)首先采取措施來(lái)防止這種情況的發(fā)生。
      
      
      
      
為了簡(jiǎn)單描述保護(hù)私鑰的策略，首先必須把我們?cè)L問(wèn)的機(jī)器歸為兩種類(lèi)型中的一類(lèi)。如果特定主機(jī)是安全性良好或是孤立的 ― 要成功獲取主機(jī)的 root 訪問(wèn)權(quán)幾乎不可能 ― 那么，那臺(tái)機(jī)器應(yīng)被認(rèn)為是
        
        可信主機(jī)。不過(guò)，如果許多其他人使用這臺(tái)機(jī)器或者您懷疑系統(tǒng)的安全性，那么這臺(tái)機(jī)器應(yīng)被認(rèn)為是
        
        不可信主機(jī)。為防止您的私鑰被他人抽取，絕對(duì)不應(yīng)在不可信主機(jī)上運(yùn)行
        
        ssh-agent （和由此啟動(dòng)的
        
        keychain ）。 那樣的話，即使系統(tǒng)安全性受到威脅，由于
        
        ssh-agent 沒(méi)有運(yùn)行，闖入者在第一時(shí)間內(nèi)也不能抽取密鑰。
      
      
      
      
但是，這產(chǎn)生了一個(gè)問(wèn)題。如果不能在不可信主機(jī)上運(yùn)行
        
        ssh-agent ，那么如何從這些系統(tǒng)上建立安全的、無(wú)密碼的
        
        ssh 連接呢？答案是：只在
        
        可信主機(jī)上使用
        
        ssh-agent 和
        
        keychain ，并利用 OpenSSH 新的
        
        認(rèn)證轉(zhuǎn)發(fā)能力將無(wú)密碼的認(rèn)證擴(kuò)展到任何不可信主機(jī)上。簡(jiǎn)略地說(shuō)，就是通過(guò)允許遠(yuǎn)程
        
        ssh 會(huì)話來(lái)聯(lián)系運(yùn)行在可信系統(tǒng)上的
        
        ssh-agent ，使認(rèn)證轉(zhuǎn)發(fā)工作。
      
      
      
      




回頁(yè)首
認(rèn)證代理程序轉(zhuǎn)發(fā)
      
      
要了解認(rèn)證轉(zhuǎn)發(fā)工作的原理，讓我們首先看一下一個(gè)假設(shè)情況，其中用戶
        
        drobbins 有一個(gè)稱為
        
        lappy 的可信的便攜式電腦、一個(gè)稱為
        
        trustbox 的可信服務(wù)器和另外兩個(gè)他必須訪問(wèn)的不可信系統(tǒng)，分別稱為
        
        notrust1 和
        
        notrust2 。當(dāng)前，他在所有這四臺(tái)機(jī)器上都使用
        
        ssh-agent 以及
        
        keychain ，如下所示：
      
      
      
      
        
        
圖 1. 運(yùn)行在可信和不可信機(jī)器上的 ssh-agent
        
        

      
      
      
      
這種方法所帶來(lái)的問(wèn)題是如果有人獲取
        
        notrust1 或
        
        notrust2 的 root 訪問(wèn)權(quán)，那么這個(gè)人當(dāng)然可以從現(xiàn)在易受攻擊的
        
        ssh-agent 進(jìn)程中抽取密鑰。為了解決這個(gè)問(wèn)題，
        
        drobbins 停止運(yùn)行不可信主機(jī)
        
        notrust1 和
        
        notrust2 上的
        
        ssh-agent 和
        
        keychain 。事實(shí)上，為了更為小心，
        
        drobbins 決定只在
        
        lappy 上使用
        
        ssh-agent 和
        
        keychain 。這樣限制了他解密的私鑰的泄露，同時(shí)防止他的私鑰被偷竊：
      
      
      
      
        
        
圖 2. ssh-agent 只運(yùn)行在 lappy 上；一個(gè)更安全的配置
        
        

      
      
      
      
當(dāng)然，這種方法帶來(lái)的問(wèn)題是
        
        drobbins 現(xiàn)在只能從
        
        lappy 建立無(wú)密碼的連接。讓我們看一下如何啟用認(rèn)證轉(zhuǎn)發(fā)并解決這個(gè)問(wèn)題。
      
      
      
      
假設(shè)所有機(jī)器都運(yùn)行 OpenSSH 的最近版本，通過(guò)使用認(rèn)證轉(zhuǎn)發(fā)，我們能解決這個(gè)問(wèn)題。認(rèn)證轉(zhuǎn)發(fā)允許遠(yuǎn)程
        
        ssh 進(jìn)程聯(lián)系您正在本地可信機(jī)器上運(yùn)行的
        
        ssh-agent ― 而不要求在您正運(yùn)行
        
         ssh  的同一臺(tái)機(jī)器上運(yùn)行
        
        ssh-agent 的一個(gè)版本。這通常允許您在單個(gè)機(jī)器上運(yùn)行
        
        ssh-agent （和
        
        keychain ），并且這意味著源于這臺(tái)機(jī)器的所有
        
        ssh 連接（直接或間接）都將使用本地
        
        ssh-agent 。
      
      
      
      
為了啟用認(rèn)證轉(zhuǎn)發(fā)，我們?cè)?
        
        lappy 和
        
        trustbox 的
        
        /etc/ssh/ssh_config 中添加了下面行。請(qǐng)注意：這是
        
        ssh 的配置文件（
        
        ssh_config），而不是 ssh 守護(hù)進(jìn)程
        
        sshd 的配置文件（
        
        sshd_config）：
      
      
      
      
清單 1. 將這行添加到 /etc/ssh/ssh_config 中

      
      
ForwardAgent Yes

      
      
現(xiàn)在，為了利用認(rèn)證轉(zhuǎn)發(fā)，
        
        drobbins 可以從
        
        lappy 連接到
        
        trustbox ，然后在不提供任何連接的密碼的情況下，從
        
        trustbox 連接到
        
        notrust1 。這兩個(gè)
        
        ssh 進(jìn)程都“進(jìn)入”運(yùn)行在
        
        lappy 上的
        
        ssh-agent ：
      
      
      
      
清單 2. 進(jìn)入 lappy

      
      
$
        
        ssh drobbins@trustbox
Last login: Wed Sep 26 13:42:08 2001 from lappy
Welcome to trustbox!
$
        
        ssh drobbins@notrust1
Last login: Tue Sep 25 12:03:40 2001 from trustbox
Welcome to notrust1!
$
      
      

      
      
如果您嘗試使用類(lèi)似的配置，并發(fā)現(xiàn)代理程序轉(zhuǎn)發(fā)不起作用，請(qǐng)嘗試使用
        
        ssh -A 替代原來(lái)單純的
        
        ssh 來(lái)明確啟用認(rèn)證轉(zhuǎn)發(fā)。這里是當(dāng)我們使用上面提到的認(rèn)證轉(zhuǎn)發(fā)而登錄到
        
        trustbox 和
        
        notrust1 時(shí)，實(shí)現(xiàn)此操作的內(nèi)部運(yùn)行圖：
      
      
      
      
        
        
圖 3. 正在運(yùn)作的代理程序轉(zhuǎn)發(fā)
        
        

      
      
      
      
正如您看到的，當(dāng)
        
        ssh 連接到
        
        trustbox 時(shí)，它維持與運(yùn)行在
        
        lappy 上的
        
        ssh-agent 的連接。當(dāng)產(chǎn)生從
        
        trustbox 到
        
        notrust1 的
        
        ssh 連接時(shí)，這個(gè)新的
        
        ssh 進(jìn)程維持與以前
        
        ssh 的認(rèn)證連接，這樣有效地延伸了鏈。這個(gè)認(rèn)證鏈?zhǔn)欠衲苎由斓?
        
        notrust1 以外的其它主機(jī)取決于
        
        notrust1 的 /etc/ssh/ssh_config 是如何配置的。 只要啟用了代理程序轉(zhuǎn)發(fā)，通過(guò)使用在可信
        
        lappy 上運(yùn)行的
        
        ssh-agent ，這個(gè)鏈上的所有部分都能認(rèn)證。
      
      
      
      




回頁(yè)首
代理程序連接轉(zhuǎn)發(fā)的優(yōu)點(diǎn)
      
      
認(rèn)證轉(zhuǎn)發(fā)提供了許多在此沒(méi)有提到的安全性優(yōu)點(diǎn)。為了讓我相信代理程序連接轉(zhuǎn)發(fā)的重要性，Charles Karney 與我分享了以下三個(gè)安全性優(yōu)點(diǎn)：
      
      

私鑰只存儲(chǔ)在可信機(jī)器上。這樣防止懷有惡意的用戶從磁盤(pán)獲取加密的密鑰并防止他們?cè)噲D解加密。

         
          ssh-agent 只運(yùn)行在可信機(jī)器上。這樣防止闖入者進(jìn)行遠(yuǎn)程
         
          ssh-agent 進(jìn)程的內(nèi)存轉(zhuǎn)儲(chǔ)并從轉(zhuǎn)儲(chǔ)中抽取出您的解密私鑰。
        
        

由于您只需要在可信機(jī)器上輸入密碼，所以防止了任何擊鍵記錄器在您輸入密碼時(shí)悄悄地截取密碼。
      
      
使
用認(rèn)證代理程序連接轉(zhuǎn)發(fā)的一個(gè)缺點(diǎn)是：它不能解決允許 cron 作業(yè)利用 RSA/DSA 認(rèn)證這個(gè)問(wèn)題。解決這個(gè)問(wèn)題的一個(gè)方案是設(shè)置所有需要
RSA/DSA 認(rèn)證的 cron 作業(yè)，這樣它們就可以從局域網(wǎng)中的一臺(tái)可信機(jī)器上執(zhí)行。如果需要的話，這些 cron 作業(yè)能使用 ssh 連接到遠(yuǎn)程系統(tǒng)來(lái)實(shí)現(xiàn)自動(dòng)備份、使文件同步等操作。
      
      
      
      
既然我們已經(jīng)了解了認(rèn)證代理程序連接轉(zhuǎn)發(fā)，那么讓我們轉(zhuǎn)到近期對(duì)
        
        keychain 腳本本身所做的改進(jìn)上。
      
      
      
      




回頁(yè)首
keychain 功能改進(jìn)
      
      
感謝用戶發(fā)來(lái)補(bǔ)丁程序，許多重要的改進(jìn)已添加到
        
        keychain 源碼中。 用戶提交的
        
        keychain 補(bǔ)丁程序中有幾個(gè)與功能有關(guān)。例如，您應(yīng)記得
        
        keychain 創(chuàng)建了一個(gè) ~/.ssh-agent 文件；這個(gè)文件的名字現(xiàn)在已經(jīng)改為 ~/.ssh-agent-[hostname]，這樣
        
        keychain 可以使用從幾個(gè)不同物理主機(jī)上能訪問(wèn)已掛裝 NFS 的主目錄。除了 ~/.ssh-agent-[hostname] 文件外，現(xiàn)在還有一個(gè) ~/.ssh-agent-csh-[hostname] 文件，兼容
        
        csh 的 shell 利用 source 命令讀入并執(zhí)行該文件。最后，添加了一個(gè)新的
        
        --nocolor 選項(xiàng)，這樣，如果您碰巧在使用不兼容 vt100 的終端時(shí)，就能禁用彩色化功能部件。
      
      
      
      




回頁(yè)首
Shell 兼容性修正
      
      
當(dāng)完成了許多重要的功能改進(jìn)時(shí)，對(duì)
        
        shell 兼容性問(wèn)題也做了大量的修正。您看，keychain 1.0 需要
        
        bash ，而以后的版本則改為可以使用任何
        
        sh 兼容的 shell。這一更改使得
        
        keychain 跳出固有的框架，可以在包括 Linux、BSD、Solaris、IRIX 和 AIX 以及其它 UNIX 平臺(tái)的幾乎所有 UNIX 系統(tǒng)上運(yùn)行。轉(zhuǎn)至
        
        sh 并與常規(guī) UNIX 兼容，這已經(jīng)是困難重重了，而同時(shí)它也經(jīng)過(guò)了大量的學(xué)習(xí)經(jīng)驗(yàn)。創(chuàng)建運(yùn)行在所有這些平臺(tái)上的單個(gè)腳本事實(shí)上是非常棘手的，主要因?yàn)槲腋�本無(wú)權(quán)訪問(wèn)這些操作系統(tǒng)中的大多數(shù)系統(tǒng)！要感謝的是，全球范圍內(nèi)的
        
        keychain 用戶這樣做了，并且許多人在識(shí)別兼容性問(wèn)題以及提交補(bǔ)丁程序來(lái)解決它們等方面提供了非常大的幫助。
      
      
      
      
事實(shí)上，有兩類(lèi)兼容性問(wèn)題必須解決。首先，我需要確信
        
        keychain 只使用所有
        
        sh 實(shí)現(xiàn)下完全支持的內(nèi)置件、表達(dá)式和操作符，包括所有流行的免費(fèi)和商業(yè) UNIX
        
        sh shell、
        
        zsh （以
        
        sh 兼容的模式）和
        
        bash 版本 1 和 2。這里是用戶提交的應(yīng)用到
        
        keychain 源碼中的一些 shell 兼容的修正：
      
      
      
      
由于較早的
        
        sh shell 不支持
        
        ~ 約定來(lái)引用用戶的主目錄，因此將使用
        
        ~ 的行更改為使用
        
        $HOME 來(lái)代替：
      
      
      
      
清單 3. 使之成為 $HOME

      
      
hostname=`uname -n`
pidf=${HOME}/.ssh-agent-${hostname}
cshpidf=${HOME}/.ssh-agent-csh-${hostname}

      
      
接著，所有對(duì)
        
        source 的引用都更改成
        
        . ，以確保與純 NetBSD 的
        
        /bin/sh 兼容，因?yàn)樗�根本不支�?
        
        source 命令：
      
      
      
      
清單 4. 迎合 NetBSD

      
      
if [ -f $pidf ]
then
    . $pidf
else
SSH_AGENT_PID="NULL"
fi

      
      
按照這個(gè)方法，我還應(yīng)用了一些與性能相關(guān)的好的修正。一位聰明的 shell 腳本編寫(xiě)者告訴我不要通過(guò)輸入
        
        touch foo 來(lái)“更新”文件的修改日期，您可以這樣做：
      
      
      
      
清單 5. 更新文件的修改日期

      
      
> foo

      
      
通過(guò)使用內(nèi)置的 shell 語(yǔ)法，而不是使用外部二進(jìn)制文件，這樣避免了使用
        
        fork() ，而腳本卻變得更加有效。
        
        > foo 應(yīng)使用任何兼容
        
        sh 的 shell；但是，好象
        
        ash 并不支持它。對(duì)大多數(shù)人來(lái)說(shuō)這不應(yīng)是個(gè)問(wèn)題，因?yàn)?
        
        ash 更象是急救磁盤(pán)類(lèi)型的 shell，而不是人們每天都要使用的程序。
      
      
      
      




回頁(yè)首
平臺(tái)可執(zhí)行問(wèn)題
      
      
獲取在多個(gè) UNIX 操作系統(tǒng)下運(yùn)行的腳本不單單需要堅(jiān)持純粹的
        
        sh 語(yǔ)法。請(qǐng)記住，大多數(shù)腳本還要調(diào)用諸如
        
        grep 、
        
        awk 、
        
        ps 和其它命令的外部命令，而且必須盡可能以與標(biāo)準(zhǔn)相符的方法來(lái)調(diào)用這些命令。例如，包含在大多數(shù) UNIX 版本中的
        
        echo 能識(shí)別
        
        -e 選項(xiàng)，而 Solaris 中的
        
        echo 卻不能識(shí)別 ― 當(dāng)使用它時(shí)，它只把
        
        -e 打印到標(biāo)準(zhǔn)輸出（stdout）。因此為了處理 Solaris，
        
        keychain 現(xiàn)在自動(dòng)檢測(cè)
        
        echo -e 是否起作用：
      
      
      
      
清單 6. 尋找 Solaris

      
      
if [ -z "`echo -e`" ]
then
    E="-e"
fi

      
      
上面的代碼中，如果支持
        
        -e ，那么將
        
        E 設(shè)置為
        
        -e 。然后，可以按如下所示調(diào)用 echo：
      
      
      
      
清單 7. 更好的 echo

      
      
echo $E Usage: ${CYAN}${0}${OFF} [ ${GREEN}options${OFF} ] ${CYAN}sshkey${OFF} ...

      
      
通過(guò)使用
        
        echo $E ，而不是
        
        echo -e ，可以根據(jù)需要?jiǎng)討B(tài)地啟用或禁用
        
        -e 選項(xiàng)。
      
      
      
      
pidof，ps
      
      
可能最重要的兼容性修正涉及到更改
        
        keychain 如何檢測(cè)當(dāng)前正在運(yùn)行的
        
        ssh-agent 的進(jìn)程的方法。以前，我使用
        
        pidof 命令來(lái)這樣做，但是由于有幾個(gè)系統(tǒng)沒(méi)有
        
        pidof ，所以不得不拋棄這個(gè)方案。實(shí)際上，
        
        pidof 無(wú)論如何都不是最佳的解決方案，因?yàn)樗�列出系統(tǒng)上運(yùn)行的
        
        所有

        
        ssh-agent 進(jìn)程，而不管用戶是誰(shuí)，但我們實(shí)際上感興趣的是當(dāng)前有效的 UID 所擁有的所有
        
        ssh-agent 進(jìn)程。
      
      
      
      
所以，為抽取所需的進(jìn)程標(biāo)識(shí)，我們不使用
        
        pidof ，而是轉(zhuǎn)向?qū)?
        
        ps 輸出通過(guò)管道輸送到
        
        grep 和
        
        awk 上。 這是一個(gè)用戶提交的修正：
      
      
      
      
清單 8. 管道比 pidof 好

      
      
mypids=`ps uxw | grep ssh-agent | grep -v grep | awk '{print $2}'`

      
      
上面的管線將
        
        mypids 變量設(shè)置為當(dāng)前用戶擁有的所有
        
        ssh-agent 進(jìn)程的值。
        
        grep -v grep 命令是管線的一部分，這樣確保
        
        grep ssh-agent 進(jìn)程不會(huì)成為我們的 PID 列表中的一部分。
      
      
      
      
這種方法從概念上來(lái)說(shuō)非常好，但是因?yàn)?
        
        ps 選項(xiàng)未在各類(lèi) BSD 和 System V 的 UNIX 派生系統(tǒng)上標(biāo)準(zhǔn)化，所以使用
        
        ps 開(kāi)啟了一個(gè)全新的尚未解決的難題。這里是一個(gè)示例：雖然
        
        ps uxw 在 Linux 下起作用，而在 IRIX 下不起作用。
        
        ps -u username -f 在 Linux、IRIX 和 Solaris 下起作用，而在只理解 BSD 樣式的
        
        ps 選項(xiàng)的 BSD 下不起作用。為了解決這個(gè)問(wèn)題，在執(zhí)行
        
        ps 管線之前，
        
        keychain 會(huì)自動(dòng)檢測(cè)當(dāng)前系統(tǒng)的
        
        ps 是使用 BSD 語(yǔ)法或還是 System V 語(yǔ)法：
      
      
      
      
清單 9. 檢測(cè) BSD 還是 System V

      
      
psopts="FAIL"
ps uxw >/dev/null 2>&1
if [ $? -eq 0 ]
then
psopts="uxw"
else
ps -u `whoami` -f >/dev/null 2>&1
if [ $? -eq 0 ]
then
psopts="-u `whoami` -f"
fi
fi
if [ "$psopts" = "FAIL" ]
then
echo $0: unable to use \"ps\" to scan for ssh-agent processes.  
Report KeyChain version and echo system configuration to drobbins@gentoo.org.
exit 1
fi
mypids=`ps $psopts 2>/dev/null | grep "sh-agent" | awk '{print $2}'` > /dev/null 2>&1

      
      
為了確保我們能同時(shí)使用 System V 和 BSD 樣式的
        
        ps 命令，腳本試著運(yùn)行
        
        ps uxw ，而丟棄任何輸出。如果這個(gè)命令的錯(cuò)誤碼為零，那么我們知道
        
        ps uxw 正常工作，并且我們正確地設(shè)置了
        
        psopts 值。但是，如果
        
        ps uxw 返回一個(gè)非零的錯(cuò)誤碼（指出我們需要使用 BSD 樣式的選項(xiàng)），那么我們?cè)囍�運(yùn)行
        
        ps -u `whoami` -f ，并再次丟棄了任何輸出。此時(shí)，我們有希望發(fā)現(xiàn)可以使用的
        
        ps 是 BSD 的變體還是 System V 的變體。如果我們不知道答案，那么打印出錯(cuò)誤并退出。但是很有可能這兩個(gè)
        
        ps 命令中的一個(gè)工作正常，在這樣的情況下，執(zhí)行上面代碼段的最后一行，即
        
        ps 管線。通過(guò)緊跟在
        
        ps 后面使用
        
        $psopts 變量擴(kuò)展，我們能將正確的選項(xiàng)傳送給
        
        ps 命令。
      
      
      
      

        
        ps 管線還包含一個(gè)
        
        grep ，它的確是一個(gè)寶物，是 Hans Peter Verne 好心發(fā)給我的。 請(qǐng)注意
        
        grep -v grep 不再是管線的一部分；實(shí)際上它已經(jīng)被除去并且
        
        grep "ssh-agent" 已經(jīng)改為
        
        grep "sh-agent" 。這樣一個(gè)
        
        grep 命令最后執(zhí)行與
        
        grep ssh-agent | grep -v grep 相同的操作；您知道為什么嗎？
      
      
      
      
清單 10. 簡(jiǎn)潔的 grep 訣竅

      
      
mypids=`ps $psopts 2>/dev/null | grep "sh-agent" | awk '{print $2}'` > /dev/null 2>&1

      
      
是不是有點(diǎn)困惑？如果您確定
        
        grep "ssh-agent" 和
        
        grep "sh-agent" 應(yīng)匹配完全相同的文本行的話，那么您是正確的。所以當(dāng)
        
        ps 的輸出通過(guò)管道輸送給它們時(shí)，為什么它們生成不同的結(jié)果呢？這里是它的工作原理：當(dāng)使用
        
        grep "sh-agent" 時(shí)，您更改了
        
        grep 命令在
        
        ps 進(jìn)程列表中顯示的方式。通過(guò)這樣做，防止
        
        grep 與它本身相匹配，因?yàn)?
        
        sh-agent 字符串與
        
        sh-agent 正則表達(dá)式不匹配。那樣不是很完美嗎？如果您仍不太明白，請(qǐng)用一下
        
        grep ，您很快就會(huì)明白了。
      
      
      
      




回頁(yè)首
結(jié)束語(yǔ)
      
      
本專欄文章對(duì)討論的 OpenSSH 作出了結(jié)論。希望您已經(jīng)學(xué)到了有關(guān) OpenSSH 的很多知識(shí)，足以開(kāi)始使用 OpenSSH 來(lái)保護(hù)您系統(tǒng)的安全。
   
   




回頁(yè)首
參考資料
      
      

• 您可以參閱本文在 developerWorks 全球站點(diǎn)上的
           
           
  英文原文
  .
          
          
  
• “
           
           
  通用線程：OpenSSH 密鑰管理，第 1 部分
  ”（
           
            developerWorks，2001 年 7 月）涵蓋了 RSA/DSA 認(rèn)證。
           
           
          
          
  
• “
           
           
  通用線程：OpenSSH 密鑰管理，第 2 部分
  ”（
           
            developerWorks，2001 年 9 月）介紹了 ssh-agent 和 keychain。
           
           
          
          
  
• 在 Gentoo Linux Keychain 頁(yè)面上可以獲得
           
           
  
              
              keychain 的最新版本
           
            。
           
           
          
          
  
• 請(qǐng)務(wù)必訪問(wèn)
           
           
  OpenSSH 的開(kāi)發(fā)主頁(yè)
  ，并查閱
           
           
  OpenSSH 常見(jiàn)問(wèn)題解答
  。
           
           
          
          
  
• 您可以從 Openbsd.org 下載最新的
           
           
  OpenSSH 源碼 tarball 和 RPM
  。
           
           
          
          
  
• 
           
           
  PuTTY
  是用于 Windows 機(jī)器上的一個(gè)出色的 ssh 客戶程序。
           
           
          
          
  
• “SSH, The Secure Shell: The Definitive Guide”（O'Reilly & Associates，2001）一書(shū)可能會(huì)對(duì)您有幫助。
           
           
  作者的網(wǎng)站
  上有關(guān)于這本書(shū)、常見(jiàn)問(wèn)題解答、新聞和更新等信息。
           
           
          
          
  
• 請(qǐng)?jiān)L問(wèn)
           
           
  Slashdot
  ，獲取“面向初學(xué)者的新聞和其它相關(guān)內(nèi)容”。
           
           
          
          
  
• 請(qǐng)查閱
           
           
  Freshmeat
  ，在開(kāi)放源碼包的新發(fā)行版出現(xiàn)時(shí)它就列出來(lái)它們。
           
           
          
          
  
• 請(qǐng)瀏覽
           
            developerWorks上
           
           
  更多 Linux 參考資料
  。
           
           
          
          
  
• 請(qǐng)瀏覽
           
            developerWorks上
           
           
  更多開(kāi)放源碼資料
  。
          
          
  

   
   




回頁(yè)首
關(guān)于作者



Daniel Robbins 居住在美國(guó)新墨西哥州阿爾布開(kāi)克，他是 Gentoo Technologies, Inc. 的總裁兼首席執(zhí)行官，他主創(chuàng)了
        
        
Gentoo Linux
，這是一種用于 PC 機(jī)的高級(jí) Linux，以及
        
        Portage系統(tǒng)，是用于 Linux 的下一代移植系統(tǒng)。他還是幾本 Macmillan 出版的書(shū)籍
        
        Caldera OpenLinux Unleashed、
        
        SuSE Linux Unleashed和
        
        Samba Unleashed的投稿人。Daniel 自二年級(jí)起就和計(jì)算機(jī)結(jié)下不解之緣，那時(shí)他最先接觸的是 Logo 編程語(yǔ)言，并沉溺于 Pac Man 游戲中。這也許就是他至今仍擔(dān)任
        
        SONY Electronic Publishing/Psygnosis首席圖形設(shè)計(jì)師的原因所在。Daniel 喜歡和他的妻子 Mary 以及他們的女兒 Hadassah 一起共度時(shí)光。您可以通過(guò)
        
        
drobbins@gentoo.org
與 Daniel 聯(lián)系。
      
      
               
               
               

本文來(lái)自ChinaUnix博客，如果查看原文請(qǐng)點(diǎn)：http://blog.chinaunix.net/u3/90363/showart_2108336.html