日本搞逼视频_黄色一级片免费在线观看_色99久久_性明星video另类hd_欧美77_综合在线视频

國內最全IT社區平臺 聯系我們 | 收藏本站
阿里云優惠2
您當前位置:首頁 > php框架 > 框架設計 > SSH Agent Forwarding原理

SSH Agent Forwarding原理

來源:程序員人生   發布時間:2016-07-07 13:32:27 閱讀次數:3834次
 

SSH Agent Forwarding原理 

 2947人瀏覽 評論(2) 收藏 舉報

目錄(?)[+]

轉載自:http://blog.pkufranky.com/2012/08/ssh-agent-forwarding-guide/

ssh-agent的manual寫得倒是挺詳細,可看了好幾次都沒怎樣弄明白。08年在網上找到了非常好的1篇文章,An Illustrated Guide to SSH Agent Forwarding (后文簡稱agent guide), 將ssh的各種認證方法講得非常之詳細。 文章從密碼認證,公鑰認證,使用agent和agent forward的公鑰認證幾個方面,逐漸的將全部進程剖析得非常全面。 看完以后總算是入了門,為此寫了1篇簡短的博文。

本周為了做ssh agent相干的培訓,多方查看資料,包括ssh/sshd的manual, 相干RFC, wikipedia。 終究算是把密碼學和ssh相干東西理解得更深入了。然后重新將agent guide看了看,發現了1些問題。agent guide是2006年寫的,而06年SSH⑵剛剛出來,因此文章是基于SSH⑴的。雖然ssh agent的基本原理還是對的,但有的地方(主要是認證部份)已不正確了。

所以本文針對SSH⑵,將不準確的地方重新梳理1下,并添加了1些SSH基石(密碼學)相干的內容。

密碼學

先從密碼學說起。 現代之前,密碼學(cryptography)主要專指加密(encryption)解密(decryption)。1組配對的加密和解密算法稱為cipher. 加解密的具體運作由兩部份決定:1個是算法(algorithm),另外一個是鑰匙(key).

現代密碼學主要分為對稱鑰匙密碼學和公鑰密碼學(非對稱鑰匙密碼學)。對稱鑰匙密碼學指的是加密方和解密方都具有相同的密鑰。對稱鑰匙加密算法包括3DES, AES, Blowfish等。 對稱鑰匙密碼學依賴于鑰匙的保密性,其為難的困難是:當安全的通道不存在于雙方時,如何安全傳送這1雙方同享的密鑰?如果有通道可以安全地建立鑰匙,何不使用現有的通道。這個“雞生蛋、蛋生雞”的矛盾是終年以來密碼學沒法在真實世界利用的阻礙。直到1976年,公鑰密碼學的誕生,安全通道的問題才得以很好的解決。這1點下面講SSL/TLS的時候會提到。

公鑰密碼學,則使用1對公鑰和私鑰,通過公鑰加密,私鑰解密。公鑰和私鑰是相干的,但很難從1個推導出另外1個。公鑰密碼學不存在安全傳送密鑰的問題,由于公鑰可以對外公然,明文傳送。

公鑰密碼學包括公鑰加密算法和數字簽名算法。RSA是最多見的公鑰加密算法。RSA算法由3步構成: 公鑰私鑰的生成,加密和解密。公鑰和私鑰中的任何1個可用作加密,另外一個則用作解密。

RSA也可用作數字簽名,甲方將消息的散列值使用私鑰加密,作為簽名附在消息后面,乙方收到消息后使用公鑰將簽名解密,然后和消息計算的散列值進行對照。假設二者符合的話,那末乙方就能夠知道發信人持有甲的私鑰,和這個消息在傳播路徑上沒有被篡改過。

DSA是經常使用的數字簽名算法,但不能用作加密解密。

如何利用密碼學來安全傳輸數據呢?目前最經常使用的安全數據傳輸協議(利用層協議)是SSL/TLS. SSL (Secure Socket Layer)協議分為1.0, 2.0(1995),3.0(1996)3個版本。TLS (Transport Layer Security)則是SSL的后繼協議,分為1.0, 1.1,1.2(2008)3個版本。TLS在SSL3.0的基礎上改動其實不大,但和SSL3.0不能互操作(interoperate)。TLS中包括將連接降級到SSL3.0的方法,因此也寫作SSL/TLS.

TLS1般使用基于非對稱密碼學的Diffie-Hellman key exchange來安全傳送同享密鑰,然后使用對稱鑰匙加密算法和這1同享密鑰對傳送的數據進行加密。很多利用層的協議都可通過SSL/TLS來安全傳輸數據,比如最多見的HTTPS, 郵件傳輸服務協議(SMTP)等。

Secure Sockets Layer (SSL) uses Diffie-Hellman key exchange if the client does not have a public-private key pair and a published certificate in the Public Key Infrastructure, and Public Key Cryptography if the user does have both the keys and the credential.

ssh認證和agent forwarding

終究到正題了,下面開始講SSH.

那SSH (Secure Shell)和SSL/TLS是甚么關系呢?SSH也是1個網絡協議,用來進行安全數據交換,遠程shell服務和命令履行等。SSH由傳輸,認證和連接等協議組成。SSH的傳輸協議類似SSL/TLS (Diffie-Hellman key exchange和對稱鑰匙加密)。

本文的重點是SSH的認證部份。client和server通過key exchange取得同享密鑰(shared session key)后,所有以后的傳輸數據都進行了加密。然落后入認證部份,認證成功后,則雙向連接通道建立,通常是login shell.

來自securecrt官網關于shared session key的描寫

Session keys are the “shared keys” described above and are randomly generated by both the client and the server during establishment of a connection. Both the client and host use the same session key to encrypt and decrypt data although a different key is used for the send and receive channels. Session keys are generated after host authentication is successfully performed but before user authentication so that usernames and passwords can be sent encrypted. These keys may be replaced at regular intervals (e.g., every one to two hours) during the session and are destroyed at its conclusion.

SSH認證有多種方法,本文側重講最多見了兩種:密碼認證和公鑰認證。

1. 密碼認證

密碼認證最簡單:

  1. ssh client向目標機器發起tcp連接(1般22端口)并發送username (username是SSH協議的1部份)
  2. 目標機器ssh daemon回應需要密碼
  3. ssh client提示用戶輸入密碼,然后將密碼發送到服務器
  4. ssh daemon如果密碼匹配成功, 則認證通過,

基于密碼認證的缺點是

  • 容易被brute-force password guessing
  • 不合適于管理多臺機器
    若每臺機器使用相同的密碼,如果密碼泄漏,所有機器都被攻破。若使用不同密碼,則密碼太多很難記住,因此也不可能使用很強的密碼。

2. 公鑰認證

公鑰認證詳細協議見RFC4252的publickey部份

公鑰認證需要先在本地機器生成公鑰私鑰對,然后將公鑰放到目標機器的$HOME/.ssh/authorized_keys中。具體進程以下

  1. ssh client向目標機器發起tcp連接(1般22端口)
  2. ssh client提示用戶輸入passphrase以解密私鑰
  3. ssh client發送私鑰簽名的包括username和公鑰等信息的message. 
  4. 目標機器ssh daemon通過檢查消息中指定用戶的$HOME/.ssh/authorized_keys,肯定公鑰是不是可用作認證并驗證簽名的合法性, 如果二者都ok, 則通過認證

如果公鑰認證失敗,ssh還會嘗試其他認證策略,比如密碼認證。多個認證策略的嘗試順序和服務器端沒關系,由客戶真個配置來決定。

需要說明的是,即便把本機的公鑰(如.ssh/id_rsa.pub)刪除掉,認證依然可以成功。那第3步中提到的公鑰從哪里來的呢?實際上,上面(如第2步)提到的私鑰(如.ssh/id_rsa)是廣義的,既包括了私鑰,也包括了公鑰,也有可能還包括了其他信息(比如證書)。比如通過ssh-keygen -y ~/.ssh/id_rsa就能夠看到id_rsa里面的公鑰。

用作認證的私鑰最好通過passphrase進行加密,否則會有很大安全隱患,只要私鑰泄漏,他人就可以訪問你能訪問的所有遠程機器。

公鑰認證由于需要配置公鑰私鑰,初始配置略微麻煩1些,但好處是所有機器只需配置1組公私鑰對就能夠了。由于只有1個私鑰,沒必要設置多個密碼,因此可以為其設置比較強的密碼。并且僅當私鑰和密碼1同丟失時才有風險,但這個幾率非常小。

不過依然煩人的是,每次登陸都得輸入passphrase。

3. 使用ssh agent的公鑰認證

為解決每次登陸遠程機器都需要輸入passphrase的問題,ssh-agent被引入了。ssh-agent啟動后,可通過ssh-add將私鑰加入agent. ssh-add會提示用戶輸入passphrase以解密私鑰,然后將解密后的私鑰納入agent管理。agent可同時管理多個私鑰。

連接服務器的步驟以下:

  1. ssh client向目標機器發起tcp連接(1般22端口)
  2. ssh client向本地的agent要求, 得到私鑰簽名的包括username和公鑰等信息的message
  3. ssh client向目標機器發送此message和簽名
  4. 目標機器ssh daemon通過檢查消息中指定用戶的$HOME/.ssh/authorized_keys,肯定公鑰是不是可用作認證并驗證簽名的合法性, 如果二者都ok, 則通過認證

如果ssh-agent中有多個私鑰, 會順次嘗試,直到認證通過或遍歷所有私鑰. 

在全部進程中,私鑰只存在于agent的內部(內存中), ssh client并沒有獲得到私鑰。

使用ssh-agent后,只需在將key納入agent管理時輸入passphrase,以后的ssh相干操作就沒必要輸入passphrase了。但如果從本機A登陸機器B后,又想從B登陸C (或從B傳輸文件到C),依然需要輸入passphrase (如果B上也配置了用戶的私鑰)或password。還是比較麻煩。

幸虧,ssh agent forwarding解決了這1問題。

4. 使用ssh agent forwarding的公鑰認證

  1. 假定用戶已從homepc連接到了第1臺機器server。homepc的agent中已保存了用戶的私鑰
  2. server: 用戶從server向server2發起ssh連接要求
  3. server: ssh client向本地(server)的agent要求, 得到私鑰簽名的包括username和公鑰等信息的message。

    注意server上其實ssh-agent壓根就沒有啟動,ssh client只是檢查$SSH_AUTH_SOCK這個環境變量是不是存在,如果存在,則和這個變量指定的domain socket進行通訊。而這個domain socket實際上是由server上的sshd創建的。所以ssh client實際上是和sshd在通訊。

    而server的sshd并沒有私鑰信息,所以sshd做的事情實際上是轉發該要求到homepc的ssh client,再由該client將要求轉發給本地(homepc)的agent。該agent將需要的消息和簽名準備終了后,再將此數據按原路返回到server的ssh client. 路徑以下所示

    agent_homepc --($SSH_AUTH_SOCK)-- ssh_homepc --(tcp)-- \ sshd_server --($SSH_AUTH_SOCK)-- ssh_server --(tcp)-- \ sshd_server2

    這下明白為何叫agent forwarding(轉發)了吧,就是所有中間節點的sshd和ssh都充當了數據轉發的角色,1直將私鑰操作的request轉發到了本機的agent,然后再將agent的response原路返回。

  4. server: ssh client向目標機器server2發送此message和簽名

  5. server2: ssh daemon通過檢查消息中指定用戶的$HOME/.ssh/authorized_keys,肯定公鑰是不是可用作認證并驗證簽名的合法性, 如果二者都ok, 則通過認證

上面只是示例,從server2,還可以類似的無密碼登陸到server3。事實上,通過ssh agent forwarding, 能實現任意級別的無密碼登陸。并且私鑰只保存在本地的機器上,保證了私鑰的安全。

agent forwarding功能是默許關閉的,為實現任意級別無密碼登陸,在ssh到其他機器時,1定要記得添加-A參數, 以打開agent forwarding (在目標機器上會生成$SSH_AUTH_SOCK環境變量)。 比如ssh -A server2

agent forwarding打開以后,也會有安全的風險。如果用戶A通過ssh連接server并打開了agent forwarding,由于server上的root用戶也有權限訪問與agent通訊的套接字,只要root用戶將$SSH_AUTH_SOCK指向用戶A對應的套接字地址,就能夠以A的身份訪問其它A可以訪問的機器。因此請確保agent forwarding僅在可信任的服務器上打開。

本文主要從基本原理角度對ssh認證和agent相干問題進行了分析。下文會講講最好實踐。



ps:

使用步驟以下:

1 eval `ssh-agent`

2 ssh-add

3 ssh -A  要連接的主機


生活不易,碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
程序員人生
------分隔線----------------------------
分享到:
------分隔線----------------------------
關閉
程序員人生
主站蜘蛛池模板: 成人在线欧美 | 国产性一级片 | 国产伊人网 | 丝袜 亚洲 另类 欧美 综合 | 欧美一区二区三区在线看 | 日本99 | 成人欧美一区二区三区1314 | 色网在线观看 | 成人在线观看免费网址 | 黑人爆操 | 欧美日韩在线观看中文字幕 | 国产一区导航 | 久久99精品久久久久久青青日本 | 国产精品15p| 国产精品自产拍在线观看桃花 | 成人精品久久 | 在线观看日韩 | 国产传媒一区二区三区 | 亚洲国产成人av | 99久久综合国产精品二区国产 | 欧美一级特黄aa大片 | 成人精品国产 | 日韩欧美在线免费观看 | 99精品一区二区 | 国产午夜精品一区二区三区 | 亚洲国产黄 | jizz亚洲女人高潮大叫 | 国产在线精品成人免费怡红院 | 99久久99久久 | 国产91在线视频 | 激情在线视频 | 欧美中文字幕在线播放 | 三级福利视频 | 久久久久一区二区三区 | 日韩免费一级 | 中文字幕在线亚洲 | 欧美3区 | 成人区精品一区二区婷婷 | 欧美九九视频 | 欧美日韩免费在线观看 | 一区二区自拍 |