亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: OpenSSH 密鑰管理，第 3 部分 [打印本頁]

作者: socyno 時間: 2009-12-01 14:31
標題: OpenSSH 密鑰管理，第 3 部分
代理程序轉發(fā)和 keychain 改進

文檔選項

未顯示需要 JavaScript
的文檔選項

將此頁作為電子郵件發(fā)送
級別: 初級
Daniel Robbins
, 總裁兼首席執(zhí)行官, Gentoo Technologies，Inc.
2002 年  2 月  01 日
在這一系列的第三篇文章中，Daniel Robbins 向您顯示了如何利用 OpenSSH 代理程序連接轉發(fā)來增強安全性。他還共享 keychain shell 腳本近期的改進。


我們中的許多人都使用非常優(yōu)秀的 OpenSSH 作為古老的

      telnet 和

      rsh
命令的替代品，OpenSSH 不僅安全而且是加密的。OpenSSH 更吸引人的特性之一是它能夠使用以一對互補的數(shù)字式“密鑰”為基礎的 RSA
和 DSA 認證協(xié)議來認證用戶。RSA 和 DSA
認證承諾不必提供密碼就能夠與遠程系統(tǒng)建立連接，這是其主要魅力之一。有關更多背景資料，請參閱關于 OpenSSH
密鑰管理的本系列文章中以前的幾篇，分別包括
RSA/DSA 認證
（第 1 部分）和


ssh-agent 和 keychain
（第 2 部分）。




由于第 2 部分發(fā)表在 2001 年 9 月的

      developerWorks上，并且稍后在 Slashdot 和 Freshmeat（請參閱本文后面的


參考資料
，獲取到這些站點的鏈接）上引用了此文，因此，許多人已經(jīng)開始使用

      keychain ，而且它已經(jīng)做了許多更改。我收到了世界各地開發(fā)人員編寫的約 20 個高質(zhì)量的補丁程序。我已將其中許多補丁代碼合并入

      keychain 源碼中，它目前的版本是 1.8（請參閱


參考資料
）。我真誠地感謝所有提交補丁程序、錯誤報告、功能請求及感謝信的那些人。




加強 ssh 安全性


在


上篇文章
中，我花了一些時間來討論運行

      ssh-agent 在安全性方面的利弊。第二篇文章發(fā)表在

      developerWorks的幾天后，我收到來自 Sarnoff Corporation 的 Charles Karney 的一封電子郵件，他非常禮貌地通知了我 OpenSSH 新的認證代理程序轉發(fā)的能力，我們將會簡要地討論這一能力。另外，Charles 強調(diào)：在

      不可信機器上運行

      ssh-agent 是十分危險的：如果有人成功地獲取系統(tǒng)上的 root 訪問權，那么就

      能從

      ssh-agent 中抽取您解密的密鑰。即使抽取密鑰有一定的困難，但是它還是在專業(yè)的解密高手的能力范圍之內(nèi)。而且，基本事實就是偷竊私鑰是

      可能的，這意味著我們應首先采取措施來防止這種情況的發(fā)生。




為了簡單描述保護私鑰的策略，首先必須把我們訪問的機器歸為兩種類型中的一類。如果特定主機是安全性良好或是孤立的 ― 要成功獲取主機的 root 訪問權幾乎不可能 ― 那么，那臺機器應被認為是

      可信主機。不過，如果許多其他人使用這臺機器或者您懷疑系統(tǒng)的安全性，那么這臺機器應被認為是

      不可信主機。為防止您的私鑰被他人抽取，絕對不應在不可信主機上運行

      ssh-agent （和由此啟動的

      keychain ）。那樣的話，即使系統(tǒng)安全性受到威脅，由于

      ssh-agent 沒有運行，闖入者在第一時間內(nèi)也不能抽取密鑰。




但是，這產(chǎn)生了一個問題。如果不能在不可信主機上運行

      ssh-agent ，那么如何從這些系統(tǒng)上建立安全的、無密碼的

      ssh 連接呢？答案是：只在

      可信主機上使用

      ssh-agent 和

      keychain ，并利用 OpenSSH 新的

      認證轉發(fā)能力將無密碼的認證擴展到任何不可信主機上。簡略地說，就是通過允許遠程

      ssh 會話來聯(lián)系運行在可信系統(tǒng)上的

      ssh-agent ，使認證轉發(fā)工作。

回頁首
認證代理程序轉發(fā)


要了解認證轉發(fā)工作的原理，讓我們首先看一下一個假設情況，其中用戶

      drobbins 有一個稱為

      lappy 的可信的便攜式電腦、一個稱為

      trustbox 的可信服務器和另外兩個他必須訪問的不可信系統(tǒng)，分別稱為

      notrust1 和

      notrust2 。當前，他在所有這四臺機器上都使用

      ssh-agent 以及

      keychain ，如下所示：






圖 1. 運行在可信和不可信機器上的 ssh-agent

這種方法所帶來的問題是如果有人獲取

      notrust1 或

      notrust2 的 root 訪問權，那么這個人當然可以從現(xiàn)在易受攻擊的

      ssh-agent 進程中抽取密鑰。為了解決這個問題，

      drobbins 停止運行不可信主機

      notrust1 和

      notrust2 上的

      ssh-agent 和

      keychain 。事實上，為了更為小心，

      drobbins 決定只在

      lappy 上使用

      ssh-agent 和

      keychain 。這樣限制了他解密的私鑰的泄露，同時防止他的私鑰被偷竊：






圖 2. ssh-agent 只運行在 lappy 上；一個更安全的配置

當然，這種方法帶來的問題是

      drobbins 現(xiàn)在只能從

      lappy 建立無密碼的連接。讓我們看一下如何啟用認證轉發(fā)并解決這個問題。




假設所有機器都運行 OpenSSH 的最近版本，通過使用認證轉發(fā)，我們能解決這個問題。認證轉發(fā)允許遠程

      ssh 進程聯(lián)系您正在本地可信機器上運行的

      ssh-agent ― 而不要求在您正運行

      ssh  的同一臺機器上運行

      ssh-agent 的一個版本。這通常允許您在單個機器上運行

      ssh-agent （和

      keychain ），并且這意味著源于這臺機器的所有

      ssh 連接（直接或間接）都將使用本地

      ssh-agent 。




為了啟用認證轉發(fā)，我們在

      lappy 和

      trustbox 的

      /etc/ssh/ssh_config 中添加了下面行。請注意：這是

      ssh 的配置文件（

      ssh_config），而不是 ssh 守護進程

      sshd 的配置文件（

      sshd_config）：




清單 1. 將這行添加到 /etc/ssh/ssh_config 中



ForwardAgent Yes



現(xiàn)在，為了利用認證轉發(fā)，

      drobbins 可以從

      lappy 連接到

      trustbox ，然后在不提供任何連接的密碼的情況下，從

      trustbox 連接到

      notrust1 。這兩個

      ssh 進程都“進入”運行在

      lappy 上的

      ssh-agent ：




清單 2. 進入 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!
$





如果您嘗試使用類似的配置，并發(fā)現(xiàn)代理程序轉發(fā)不起作用，請嘗試使用

      ssh -A 替代原來單純的

      ssh 來明確啟用認證轉發(fā)。這里是當我們使用上面提到的認證轉發(fā)而登錄到

      trustbox 和

      notrust1 時，實現(xiàn)此操作的內(nèi)部運行圖：






圖 3. 正在運作的代理程序轉發(fā)

正如您看到的，當

      ssh 連接到

      trustbox 時，它維持與運行在

      lappy 上的

      ssh-agent 的連接。當產(chǎn)生從

      trustbox 到

      notrust1 的

      ssh 連接時，這個新的

      ssh 進程維持與以前

      ssh 的認證連接，這樣有效地延伸了鏈。這個認證鏈是否能延伸到

      notrust1 以外的其它主機取決于

      notrust1 的 /etc/ssh/ssh_config 是如何配置的。只要啟用了代理程序轉發(fā)，通過使用在可信

      lappy 上運行的

      ssh-agent ，這個鏈上的所有部分都能認證。

回頁首
代理程序連接轉發(fā)的優(yōu)點


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

私鑰只存儲在可信機器上。這樣防止懷有惡意的用戶從磁盤獲取加密的密鑰并防止他們試圖解加密。

      ssh-agent 只運行在可信機器上。這樣防止闖入者進行遠程

      ssh-agent 進程的內(nèi)存轉儲并從轉儲中抽取出您的解密私鑰。

由于您只需要在可信機器上輸入密碼，所以防止了任何擊鍵記錄器在您輸入密碼時悄悄地截取密碼。


使
用認證代理程序連接轉發(fā)的一個缺點是：它不能解決允許 cron 作業(yè)利用 RSA/DSA 認證這個問題。解決這個問題的一個方案是設置所有需要
RSA/DSA 認證的 cron 作業(yè)，這樣它們就可以從局域網(wǎng)中的一臺可信機器上執(zhí)行。如果需要的話，這些 cron 作業(yè)能使用 ssh 連接到遠程系統(tǒng)來實現(xiàn)自動備份、使文件同步等操作。




既然我們已經(jīng)了解了認證代理程序連接轉發(fā)，那么讓我們轉到近期對

      keychain 腳本本身所做的改進上。

回頁首
keychain 功能改進


感謝用戶發(fā)來補丁程序，許多重要的改進已添加到

      keychain 源碼中。用戶提交的

      keychain 補丁程序中有幾個與功能有關。例如，您應記得

      keychain 創(chuàng)建了一個 ~/.ssh-agent 文件；這個文件的名字現(xiàn)在已經(jīng)改為 ~/.ssh-agent-[hostname]，這樣

      keychain 可以使用從幾個不同物理主機上能訪問已掛裝 NFS 的主目錄。除了 ~/.ssh-agent-[hostname] 文件外，現(xiàn)在還有一個 ~/.ssh-agent-csh-[hostname] 文件，兼容

      csh 的 shell 利用 source 命令讀入并執(zhí)行該文件。最后，添加了一個新的

      --nocolor 選項，這樣，如果您碰巧在使用不兼容 vt100 的終端時，就能禁用彩色化功能部件。

回頁首
Shell 兼容性修正


當完成了許多重要的功能改進時，對

      shell 兼容性問題也做了大量的修正。您看，keychain 1.0 需要

      bash ，而以后的版本則改為可以使用任何

      sh 兼容的 shell。這一更改使得

      keychain 跳出固有的框架，可以在包括 Linux、BSD、Solaris、IRIX 和 AIX 以及其它 UNIX 平臺的幾乎所有 UNIX 系統(tǒng)上運行。轉至

      sh 并與常規(guī) UNIX 兼容，這已經(jīng)是困難重重了，而同時它也經(jīng)過了大量的學習經(jīng)驗。創(chuàng)建運行在所有這些平臺上的單個腳本事實上是非常棘手的，主要因為我根本無權訪問這些操作系統(tǒng)中的大多數(shù)系統(tǒng)！要感謝的是，全球范圍內(nèi)的

      keychain 用戶這樣做了，并且許多人在識別兼容性問題以及提交補丁程序來解決它們等方面提供了非常大的幫助。




事實上，有兩類兼容性問題必須解決。首先，我需要確信

      keychain 只使用所有

      sh 實現(xiàn)下完全支持的內(nèi)置件、表達式和操作符，包括所有流行的免費和商業(yè) UNIX

      sh shell、

      zsh （以

      sh 兼容的模式）和

      bash 版本 1 和 2。這里是用戶提交的應用到

      keychain 源碼中的一些 shell 兼容的修正：




由于較早的

      sh shell 不支持

      ~ 約定來引用用戶的主目錄，因此將使用

      ~ 的行更改為使用

      $HOME 來代替：




清單 3. 使之成為 $HOME



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



接著，所有對

      source 的引用都更改成

      . ，以確保與純 NetBSD 的

      /bin/sh 兼容，因為它根本不支持

      source 命令：




清單 4. 迎合 NetBSD



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



按照這個方法，我還應用了一些與性能相關的好的修正。一位聰明的 shell 腳本編寫者告訴我不要通過輸入

      touch foo 來“更新”文件的修改日期，您可以這樣做：




清單 5. 更新文件的修改日期



> foo



通過使用內(nèi)置的 shell 語法，而不是使用外部二進制文件，這樣避免了使用

      fork() ，而腳本卻變得更加有效。

      > foo 應使用任何兼容

      sh 的 shell；但是，好象

      ash 并不支持它。對大多數(shù)人來說這不應是個問題，因為

      ash 更象是急救磁盤類型的 shell，而不是人們每天都要使用的程序。

回頁首
平臺可執(zhí)行問題


獲取在多個 UNIX 操作系統(tǒng)下運行的腳本不單單需要堅持純粹的

      sh 語法。請記住，大多數(shù)腳本還要調(diào)用諸如

      grep 、

      awk 、

      ps 和其它命令的外部命令，而且必須盡可能以與標準相符的方法來調(diào)用這些命令。例如，包含在大多數(shù) UNIX 版本中的

      echo 能識別

      -e 選項，而 Solaris 中的

      echo 卻不能識別 ― 當使用它時，它只把

      -e 打印到標準輸出（stdout）。因此為了處理 Solaris，

      keychain 現(xiàn)在自動檢測

      echo -e 是否起作用：




清單 6. 尋找 Solaris



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



上面的代碼中，如果支持

      -e ，那么將

      E 設置為

      -e 。然后，可以按如下所示調(diào)用 echo：




清單 7. 更好的 echo



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



通過使用

      echo $E ，而不是

      echo -e ，可以根據(jù)需要動態(tài)地啟用或禁用

      -e 選項。




pidof，ps


可能最重要的兼容性修正涉及到更改

      keychain 如何檢測當前正在運行的

      ssh-agent 的進程的方法。以前，我使用

      pidof 命令來這樣做，但是由于有幾個系統(tǒng)沒有

      pidof ，所以不得不拋棄這個方案。實際上，

      pidof 無論如何都不是最佳的解決方案，因為它列出系統(tǒng)上運行的

      所有


      ssh-agent 進程，而不管用戶是誰，但我們實際上感興趣的是當前有效的 UID 所擁有的所有

      ssh-agent 進程。




所以，為抽取所需的進程標識，我們不使用

      pidof ，而是轉向將

      ps 輸出通過管道輸送到

      grep 和

      awk 上。這是一個用戶提交的修正：




清單 8. 管道比 pidof 好



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



上面的管線將

      mypids 變量設置為當前用戶擁有的所有

      ssh-agent 進程的值。

      grep -v grep 命令是管線的一部分，這樣確保

      grep ssh-agent 進程不會成為我們的 PID 列表中的一部分。




這種方法從概念上來說非常好，但是因為

      ps 選項未在各類 BSD 和 System V 的 UNIX 派生系統(tǒng)上標準化，所以使用

      ps 開啟了一個全新的尚未解決的難題。這里是一個示例：雖然

      ps uxw 在 Linux 下起作用，而在 IRIX 下不起作用。

      ps -u username -f 在 Linux、IRIX 和 Solaris 下起作用，而在只理解 BSD 樣式的

      ps 選項的 BSD 下不起作用。為了解決這個問題，在執(zhí)行

      ps 管線之前，

      keychain 會自動檢測當前系統(tǒng)的

      ps 是使用 BSD 語法或還是 System V 語法：




清單 9. 檢測 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



為了確保我們能同時使用 System V 和 BSD 樣式的

      ps 命令，腳本試著運行

      ps uxw ，而丟棄任何輸出。如果這個命令的錯誤碼為零，那么我們知道

      ps uxw 正常工作，并且我們正確地設置了

      psopts 值。但是，如果

      ps uxw 返回一個非零的錯誤碼（指出我們需要使用 BSD 樣式的選項），那么我們試著運行

      ps -u `whoami` -f ，并再次丟棄了任何輸出。此時，我們有希望發(fā)現(xiàn)可以使用的

      ps 是 BSD 的變體還是 System V 的變體。如果我們不知道答案，那么打印出錯誤并退出。但是很有可能這兩個

      ps 命令中的一個工作正常，在這樣的情況下，執(zhí)行上面代碼段的最后一行，即

      ps 管線。通過緊跟在

      ps 后面使用

      $psopts 變量擴展，我們能將正確的選項傳送給

      ps 命令。






      ps 管線還包含一個

      grep ，它的確是一個寶物，是 Hans Peter Verne 好心發(fā)給我的。請注意

      grep -v grep 不再是管線的一部分；實際上它已經(jīng)被除去并且

      grep "ssh-agent" 已經(jīng)改為

      grep "sh-agent" 。這樣一個

      grep 命令最后執(zhí)行與

      grep ssh-agent | grep -v grep 相同的操作；您知道為什么嗎？




清單 10. 簡潔的 grep 訣竅



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



是不是有點困惑？如果您確定

      grep "ssh-agent" 和

      grep "sh-agent" 應匹配完全相同的文本行的話，那么您是正確的。所以當

      ps 的輸出通過管道輸送給它們時，為什么它們生成不同的結果呢？這里是它的工作原理：當使用

      grep "sh-agent" 時，您更改了

      grep 命令在

      ps 進程列表中顯示的方式。通過這樣做，防止

      grep 與它本身相匹配，因為

      sh-agent 字符串與

      sh-agent 正則表達式不匹配。那樣不是很完美嗎？如果您仍不太明白，請用一下

      grep ，您很快就會明白了。





回頁首
結束語


本專欄文章對討論的 OpenSSH 作出了結論。希望您已經(jīng)學到了有關 OpenSSH 的很多知識，足以開始使用 OpenSSH 來保護您系統(tǒng)的安全。

回頁首
參考資料


您可以參閱本文在 developerWorks 全球站點上的


英文原文
.



“


通用線程：OpenSSH 密鑰管理，第 1 部分
”（

      developerWorks，2001 年 7 月）涵蓋了 RSA/DSA 認證。





“


通用線程：OpenSSH 密鑰管理，第 2 部分
”（

      developerWorks，2001 年 9 月）介紹了 ssh-agent 和 keychain。





在 Gentoo Linux Keychain 頁面上可以獲得




         keychain 的最新版本

      。





請務必訪問


OpenSSH 的開發(fā)主頁
，并查閱


OpenSSH 常見問題解答
。





您可以從 Openbsd.org 下載最新的


OpenSSH 源碼 tarball 和 RPM
。







PuTTY
是用于 Windows 機器上的一個出色的 ssh 客戶程序。





“SSH, The Secure Shell: The Definitive Guide”（O'Reilly & Associates，2001）一書可能會對您有幫助。


作者的網(wǎng)站
上有關于這本書、常見問題解答、新聞和更新等信息。





請訪問


Slashdot
，獲取“面向初學者的新聞和其它相關內(nèi)容”。





請查閱


Freshmeat
，在開放源碼包的新發(fā)行版出現(xiàn)時它就列出來它們。





請瀏覽

      developerWorks上


更多 Linux 參考資料
。





請瀏覽

      developerWorks上


更多開放源碼資料
。



回頁首
關于作者

Daniel Robbins 居住在美國新墨西哥州阿爾布開克，他是 Gentoo Technologies, Inc. 的總裁兼首席執(zhí)行官，他主創(chuàng)了


Gentoo Linux
，這是一種用于 PC 機的高級 Linux，以及

      Portage系統(tǒng)，是用于 Linux 的下一代移植系統(tǒng)。他還是幾本 Macmillan 出版的書籍

      Caldera OpenLinux Unleashed、

      SuSE Linux Unleashed和

      Samba Unleashed的投稿人。Daniel 自二年級起就和計算機結下不解之緣，那時他最先接觸的是 Logo 編程語言，并沉溺于 Pac Man 游戲中。這也許就是他至今仍擔任

      SONY Electronic Publishing/Psygnosis首席圖形設計師的原因所在。Daniel 喜歡和他的妻子 Mary 以及他們的女兒 Hadassah 一起共度時光。您可以通過


drobbins@gentoo.org
與 Daniel 聯(lián)系。



本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u3/90363/showart_2108336.html

歡迎光臨 Chinaunix (http://www.72891.cn/) Powered by Discuz! X3.2

感谢您访问我们的网站，您可能还对以下资源感兴趣：
亚洲av成人无遮挡网站在线观看