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）.