Secure Shell
| 網際網路協定套組 |
|---|
| 應用層 |
| 傳輸層 |
| 網路層 |
| 連結層 |
安全外殼協定（Secure Shell Protocol，簡稱SSH）是一種加密的網路傳輸協定，可在不安全的網路中為網路服務提供安全的傳輸環境[1]。SSH通過在網路中建立安全隧道來實現SSH客戶端與伺服器之間的連線[2]。SSH最常見的用途是遠端登入系統，人們通常利用SSH來傳輸命令列介面和遠端執行命令。SSH使用頻率最高的場合是類Unix系統，但是Windows作業系統也能有限度地使用SSH。2015年，微軟宣布將在未來的作業系統中提供原生SSH協定支援[3]，Windows 10 1803版本已提供OpenSSH工具[4]。
在設計上，SSH是Telnet和非安全shell的替代品。Telnet和Berkeley rlogin、rsh、rexec等協定採用明文傳輸，使用不可靠的密碼，容易遭到監聽、嗅探和中間人攻擊[5]。SSH旨在保證非安全網路環境（例如網際網路）中資訊加密完整可靠。
不過，SSH也被指出有被嗅探甚至解密的漏洞。早在2011年，中國的網際網路審查機構已經有能力針對SSH連線的刺探及干擾。[6][7]而後愛德華·史諾登洩露的檔案也指出，美國國家安全局有時能夠把SSH協定傳輸的資訊解密出來，從而讀出SSH對談的傳輸內容[8]。2017年7月6日，非營利組織維基解密確認美國中央情報局已經開發出能夠在Windows或Linux作業系統中竊取SSH對談的工具。[9]
概述
SSH以非對稱加密實現身分驗證[2]。身分驗證有多種途徑，例如其中一種方法是使用自動生成的公鑰-私鑰對來簡單地加密網路連線，隨後使用密碼認證進行登入；另一種方法是人工生成一對公鑰和私鑰，通過生成的金鑰進行認證，這樣就可以在不輸入密碼的情況下登入。任何人都可以自行生成金鑰。公鑰需要放在待訪問的電腦之中，而對應的私鑰需要由使用者自行保管。認證過程基於生成出來的私鑰，但整個認證過程中私鑰本身不會傳輸到網路中。
SSH協定有兩個主要版本，分別是SSH-1和SSH-2。無論是哪個版本，核實未知金鑰來源都是重要的事情，因為SSH只驗證提供使用者是否擁有與公鑰相匹配的私鑰，只要接受公鑰而且金鑰匹配伺服器就會授予許可。這樣的話，一旦接受了惡意攻擊者的公鑰，那麼系統也會把攻擊者視為合法使用者。
金鑰管理
在類Unix系統中，已許可登入的公鑰通常儲存在使用者 /home 目錄的 ~/.ssh/authorized_keys 檔案中[10]，該檔案只由SSH使用。當遠端機器持有公鑰，而本地持有對應私鑰時，登入過程不再需要手動輸入密碼。另外為了額外的安全性，私鑰本身也能用密碼保護。
私鑰會儲存在固定位置，也可以通過命令列參數指定（例如ssh命令的「-i」選項）。ssh-keygen是生成金鑰的工具之一。
SSH也支援基於密碼的身分驗證，此時金鑰是自動生成的。若客戶端和伺服器端從未進行過身分驗證，SSH未記錄伺服器端所使用的金鑰，那麼攻擊者可以模仿伺服器端請求並取得密碼，即中間人攻擊。但是密碼認證可以禁用，而且SSH客戶端在發現新金鑰或未知伺服器時會向使用者發出警告。
應用
SSH的經典用途是登入到遠端電腦中執行命令。除此之外，SSH也支援隧道協定、埠對映和X11連線。藉助SFTP或SCP協定，SSH還可以傳輸檔案[2]。
SSH使用客戶端-伺服器模型，標準埠為22[11]。伺服器端需要開啟SSH守護行程以便接受遠端的連線，而使用者需要使用SSH客戶端與其建立連線。
大多數現代作業系統（包括macOS、大部分Linux、OpenBSD、FreeBSD、Solaris等系統）都提供了SSH，包括Windows系統也提供SSH程式（在Windows 10 1809版本之後）。在軟體層次，許多關於SSH的專有軟體、免費軟體和開源軟體被研發出來，如：
從雲端運算的角度上講，SSH能夠阻止一些因直接暴露在網際網路而產生的安全問題，在解決連線問題上發揮了重要作用。SSH隧道可以在網際網路、防火牆和虛擬機器之間提供一個安全的通道[12]。
歷史
1.x版本
芬蘭赫爾辛基理工大學的塔圖·于勒寧發現自己學校存在嗅探密碼的網路攻擊，便於1995年編寫了一套保護資訊傳輸的程式，並稱其為「secure shell」，簡稱SSH[13]，設計目標是取代先前的rlogin、Telnet、FTP[14]和rsh等安全性不足的協定。1995年7月，于勒寧以免費軟體的形式將其發布。程式很快流行起來，截至1995年底，SSH的使用者數已經達到兩萬，遍布五十個國家。
1995年12月，于勒寧創立了SSH通訊安全公司來繼續開發和銷售SSH。SSH的早期版本用到了很多自由軟體，例如GNU libgmp，但後來由SSH公司發布的版本逐漸變成了專有軟體。
截至2000年，已經有兩百萬使用者使用SSH。[15]
OpenSSH和OSSH
1999年，開發者們希望使用自由版本的SSH，於是重新使用較舊的1.2.12版本，這也是最後一個採用開放原始碼許可的版本。隨後瑞典程式設計師Björn Grönvall基於這個版本開發了OSSH。不久之後，OpenBSD的開發者又在Grönvall版本的基礎上進行了大量修改，形成了OpenSSH，並於OpenBSD 2.6一起發行。從該版本開始，OpenSSH又逐漸移植到了其他作業系統上面。[16]
截至2005年，OpenSSH是唯一一種最流行的SSH實現，而且成為了大量作業系統的預設組件，而OSSH已經過時[17]。OpenSSH仍在維護，而且已經支援SSH-2協定。從7.6版開始，OpenSSH不再支援SSH-1協定。
2.x版本
2006年，SSH-2協定成為了新的標準。與SSH-1相比，SSH-2進行了一系列功能改進並增強了安全性，例如基於迪菲-赫爾曼金鑰交換的加密和基於訊息鑑別碼的完整性檢查。SSH-2還支援通過單個SSH連線任意數量的shell對談。SSH-2協定與SSH-1不相容，由於更加流行，一些實現（例如lsh和Dropbear）只支援SSH-2協定。
1.99版
RFC 4253規定支援2.0及以前版本SSH的SSH伺服器應將其原始版本標為「1.99」[18]。「1.99」並不是實際的軟體版本號，而是為了表示向下相容。
基本架構
SSH協定框架中最主要的部分是三個協定：
- 傳輸層協定（The Transport Layer Protocol）：傳輸層協定提供伺服器認證，資料機密性，資訊完整性等的支援。
- 使用者認證協定（The User Authentication Protocol）：使用者認證協定為伺服器提供客戶端的身分鑑別。
- 連線協定（The Connection Protocol）：連線協定將加密的資訊隧道復用成若干個邏輯通道，提供給更高層的應用協定使用。
同時還有為許多高層的網路安全應用協定提供擴充的支援。
各種高層應用協定可以相對地獨立於SSH基本體系之外，並依靠這個基本框架，通過連線協定使用SSH的安全機制。
SSH的安全驗證
在客戶端來看，SSH提供兩種級別的安全驗證。
- 第一種級別（基於密碼的安全驗證），知道帳號和密碼，就可以登入到遠端主機，並且所有傳輸的資料都會被SSH傳輸層協定加密。但是，可能會有別的伺服器在冒充真正的伺服器，但只要客戶端校驗主機公鑰，在伺服器私鑰不洩露的前提下就能避免被「中間人」攻擊。
- 第二種級別（基於金鑰的安全驗證），需要依靠金鑰，也就是你必須為自己建立一對金鑰，並把公鑰放在需要訪問的伺服器上。客戶端軟體會向伺服器發出請求，請求用你的私鑰進行安全驗證並行送使用私鑰對對談ID等資訊的簽章。伺服器收到請求之後，先在你在該伺服器的使用者根目錄下尋找你的公鑰，然後把它和你傳送過來的公鑰進行比較，並用公鑰檢驗簽章是否正確。如果兩個金鑰一致，且簽章正確，伺服器就認為使用者登入成功。
在伺服器端來看，SSH也提供安全驗證。
- 伺服器將自己的公鑰分發給相關的客戶端，並將金鑰交換過程中的公開資訊與協商金鑰的雜湊值的簽章傳送給客戶端，客戶端將取得的伺服器公鑰計算指紋並與其他安全信道獲得的公鑰指紋相比對並驗證主機簽章。
- 存在一個金鑰認證中心，所有提供服務的主機都將自己的公鑰提交給認證中心，公鑰認證中心給伺服器端頒發憑證，而任何作為客戶端的主機則只要儲存一份認證中心的公鑰就可以了。在這種模式下，伺服器會傳送認證中心提供給主機的憑證與主機對金鑰交換過程中公開資訊的簽章。客戶端只需要驗證憑證的有效性並驗證簽章。
SSH協定的可延伸性
SSH協定框架中設計了大量可延伸項，比如使用者自訂演算法、客戶自訂金鑰規則、高層擴充功能性應用協定。這些擴充大多遵循IANA的有關規定，特別是在重要的部分，像命名規則和訊息編碼方面。
參考文獻
- ^ The Secure Shell (SSH) Protocol Architecture. RFC 4251. IETF Network Working Group. 2006-01 [2017-12-02]. （原始內容存檔於2018-10-10）.
- ^ 2.0 2.1 2.2 The Secure Shell (SSH) Authentication Protocol. RFC 4252. IETF Network Working Group. 2006-01 [2017-12-02]. （原始內容存檔於2017-11-19）.
- ^ Peter Bright. Microsoft bringing SSH to Windows and PowerShell. Ars Technica. 2015-06-02 [2017-12-02]. （原始內容存檔於2017-06-09）.
- ^ maertendMSFT. OpenSSH in Windows. docs.microsoft.com. [2019-05-11]. （原始內容存檔於2019-05-11） （美國英語）.
- ^ SSH Hardens the Secure Shell （頁面存檔備份，存於網際網路檔案館）, Serverwatch.com
- ^ 中国刺探加密连接测试新屏蔽方式. www.solidot.org. 2011-11-21 [2021-10-24]. （原始內容存檔於2020-07-07）.
- ^ Greenberg, Andy. China's Great Firewall Tests Mysterious Scans On Encrypted Connections. Forbes. [2018-02-18]. （原始內容存檔於2018-02-18） （英語）.
- ^ Prying Eyes: Inside the NSA's War on Internet Security. Spiegel Online. 2014-12-28 [2017-12-02]. （原始內容存檔於2015-01-24）.
- ^ BothanSpy. wikileaks.org. 2017-07-06 [2017-09-25]. （原始內容存檔於2017-07-08）.
- ^ SSH setup manual. [2017-12-02]. （原始內容存檔於2017-07-11）.
- ^ Service Name and Transport Protocol Port Number Registry. iana.org. [2017-12-02]. （原始內容存檔於2001-06-04）.
- ^ Amies, A; Wu, C F; Wang, G C; Criveti, M. Networking on the cloud. IBM developerWorks. 2012 [2017-12-02]. （原始內容存檔於2013-06-14）.
- ^ Tatu Ylönen. The new skeleton key: changing the locks in your network environment. 2013-04-02 [2017-12-02]. （原始內容存檔於2017-08-20）.
- ^ Tatu Ylönen. SSH Port. [2017-12-02]. （原始內容存檔於2017-08-03）.
- ^ Nicholas Rosasco and David Larochelle. How and Why More Secure Technologies Succeed in Legacy Markets: Lessons from the Success of SSH (PDF). Quoting Barrett and Silverman, SSH, the Secure Shell: The Definitive Guide, O'Reilly & Associates (2001). Dept. of Computer Science, Univ. of Virginia. [2006-05-19]. （原始內容存檔 (PDF)於2006-06-25）.
- ^ OpenSSH: Project History and Credits. openssh.com. 2004-12-22 [2014-04-27]. （原始內容存檔於2013-12-24）.
- ^ OSSH Information for VU#419241. [2017-12-02]. （原始內容存檔於2007-09-27）.
- ^ RFC 4253, section 5. Compatibility With Old SSH Versions. RFC 4253. IETF Network Working Group. 2006-01 [2017-12-02]. （原始內容存檔於2018-03-01）.
外部連結
- SSH Communications Security Corporation的網站
- OpenSSH組織的網站（頁面存檔備份，存於網際網路檔案館）
- IANA的標準及組織
- RFC4251:The Secure Shell (SSH) Protocol Architecture
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
