跳至內容

用戶:幻想鄉的反逆者/沙盒

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
  「ssh」和「關於簡稱為「SSH」的Web開發框架，參見struts、Spring Framework和Hibernate。」重新導向至此。
互聯網協定套組
應用層
傳輸層
網絡層
連結層

Secure Shell（安全外殼協定，簡稱SSH）是一種加密的網絡傳輸協定，可在不安全的網絡中為網絡服務提供安全的傳輸環境[1]。SSH通過在網絡中建立安全隧道（英語：secure channel）來實現SSH客戶端與伺服器之間的連接[2]。雖然任何網絡服務都可以通過SSH實現安全傳輸，SSH最常見的用途是遠端登入系統，人們通常利用SSH來傳輸命令列介面和遠端執行命令。使用頻率最高的場合類Unix系統，但是Windows作業系統也能有限度地使用SSH。2015年，微軟宣佈將在未來的作業系統中提供原生SSH協定支援[3]。

在設計上，SSH是Telnet和非安全shell的替代品。Telnet和Berkeley rlogin（英語：rlogin）、rsh、rexec（英語：Remote Process Execution）等協定採用明文傳輸，使用不可靠的密碼，導致資訊容易遭到監聽，也容易通過封包分析嗅探到[4]。SSH旨在保證非安全網絡環境（例如互聯網）中資訊加密完整可靠。不過，愛德華·斯諾登泄露的檔案也指出，美國國家安全域有時能夠把SSH協定傳輸的資訊解密出來，從而讀出SSH對談的傳輸內容[5]。

2017年7月6日，非營利組織維基解密確認美國中央情報局已經開發出能夠在Windows或Linux作業系統中竊取SSH對談的工具。[6]

概述

[編輯]

SSH以非對稱加密實現身份驗證[2]。身份驗證有多種途徑，例如其中一種方法是使用自動生成的公鑰-私鑰對來簡單地加密網絡連接，隨後使用密碼認證進行登入；另一種方法是人工生成一對公鑰和私鑰，通過生成的金鑰進行認證，這樣就可以在不輸入密碼的情況下登入。任何人都可以自行生成金鑰。公鑰需要放在待訪問的電腦之中，而對應的私鑰需要由用戶自行保管。認證過程基於生成出來的私鑰，但整個認證過程私鑰本身中不會傳輸到網絡中。

SSH協定有兩個主要版本，分別是SSH-1和SSH-2。無論是哪個版本，核實未知金鑰來源都是重要的事情，因為SSH只驗證提供用戶是否擁有與公鑰相匹配的私鑰，只要接受公鑰而且金鑰匹配伺服器就會授予許可。這樣的話，一旦接受了惡意攻擊者的公鑰，那麼系統也會把攻擊者視為合法用戶。

金鑰管理

[編輯]

在類Unix系統中，已許可登入的公鑰通常儲存在用戶家目錄的 ~/.ssh/authorized_keys 檔案中[7]，該檔案只由SSH使用。當遠端機器持有公鑰，而本地持有對應私鑰時，登入過程不再需要手動輸入密碼。另外為了額外的安全性，私鑰本身也能用密碼保護。

私鑰會儲存在固定位置，也可以通過命令列參數指定（例如ssh命令的「-i」選項）。ssh-keygen是生成金鑰的工具之一。

SSH也支援基於密碼的身份驗證，此時金鑰是自動生成的。若客戶端和伺服器端從未進行過身份驗證，SSH未記錄伺服器端所使用的金鑰，那麼攻擊者可以模仿伺服器端請求並取得密碼，即中間人攻擊。但是密碼認證可以禁用，而且SSH客戶端在發現新金鑰或未知伺服器時會向用戶發出警告。

使用

[編輯]

SSH的經典用途是登入到遠端電腦中執行命令。除此之外，SSH也支援隧道協定、埠對映和X11連接。藉助SFTP或SCP協定還可以傳輸檔案[2]。

SSH使用客戶端-伺服器模型。伺服器端需要開啟SSH守護行程以便接受遠端的連接，而用戶需要使用SSH客戶端與其建立連接。標準埠中的22埠分配給了SSH服務[8]。

大多數現代作業系統（包括macOS、大部分Linux、OpenBSD、FreeBSD、Solaris等系統）都提供了SSH，但Windows系統未內建SSH程式。Windows用戶可以使用Cygwin來建立SSH服務。SSH客戶端種類很多，包括專有軟件、免費軟件和開源軟件，例如PuTTY和傳輸檔案專用的WinSCP等。

從雲端運算的角度上講，SSH能夠阻止一些因直接暴露在互聯網而產生的安全問題，在解決連接問題上發揮了重要作用。SSH隧道可以在互聯網、防火牆和虛擬機器之間提供一個安全的通道[9]。

歷史

[編輯]

1.x版本

[編輯]

芬蘭赫爾辛基理工大學的塔圖·于勒寧發現自己學校存在嗅探密碼的網絡攻擊，便於1995年編寫了一套保護資訊傳輸的程式，並稱其為「secure shell」，簡稱SSH[10]，設計目標是取代先前的rlogin（英語：rlogin）、Telnet、FTP[11]和rsh等安全性不足的協定。1995年7月，于勒寧以免費軟件的形式將其發佈。程式很快流行起來，截至1995年底，SSH的用戶數已經達到兩萬，遍佈五十個國家。

1995年12月，于勒寧創立了SSH通訊安全公司來繼續開發和銷售SSH。SSH的早期版本用到了很多自由軟件，例如GNU libgmp，但後來由SSH公司發佈的版本逐漸變成了專有軟件。

截至2000年，已經有兩百萬用戶使用SSH。[12]

OpenSSH和OSSH

[編輯]

1999年，開發者們希望使用自由版本的SSH，於是重新使用較舊的1.2.12版本，這也是最後一個採用開放原始碼許可的版本。隨後瑞典程式設計師Björn Grönvall基於這個版本開發了OSSH。不久之後，OpenBSD的開發者又在Grönvall版本的基礎上進行了大量修改，形成了OpenSSH，並於OpenBSD 2.6一起發行。從該版本開始，OpenSSH又逐漸移植到了其他作業系統上面。[13]

截至2005年，OpenSSH是唯一一種最流行的SSH實現，而且成為了大量作業系統的預設組件，而OSSH已經過時[14]。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」[15]。「1.99」並不是實際的軟件版本號，而是為了表示向下相容。

應用

[編輯]
通過SSH隧道轉發X11應用：用戶josh在名為foofighter的電腦中連接了名字為tengwar的電腦，並將遠端機器tengwar中的xeyes程式轉發到了本地電腦foofighter上面。
在Windows系統中，通過名為PuTTY的軟件連接到遠端的OpenWrt系統中。

SSH可以用在很多平台上面，例如大多數類Unix系統（如Linux、Solaris、包括macOS在內的BSD等）和Windows系統。SSH能夠完成很多工，例如：

  • 遠端登入並在遠端系統上執行命令；
  • 檔案傳輸；
  • 與rsync配合，安全地備份、複製檔案或製作鏡像；
  • 建立隧道協定，實現埠對映；
  • 實現VPN；
  • 將遠端系統上的X對映到本機；
  • 通過SSH建立的加密SOCKS代理瀏覽網站；
  • 自動化監視與管理遠端伺服器；
  • 在支援SSH的流動電話或嵌入式裝置上進行軟件開發。

上述各功能中，有些需要特定的SSH的伺服器或客戶端，例如VPN只能通過OpenSSH來實現。

檔案傳輸協定

[編輯]

以下幾種檔案傳輸方式採用了SSH協定：

Architecture

[編輯]
Diagram of the SSH-2 binary packet.

The SSH-2 protocol has an internal architecture (defined in RFC 4251) with well-separated layers, namely:

  • The transport layer (RFC 4253). This layer handles initial key exchange as well as server authentication, and sets up encryption, compression and integrity verification. It exposes to the upper layer an interface for sending and receiving plaintext packets with sizes of up to 32,768 bytes each (more can be allowed by the implementation). The transport layer also arranges for key re-exchange, usually after 1 GB of data has been transferred or after 1 hour has passed, whichever occurs first.
  • The user authentication layer (RFC 4252). This layer handles client authentication and provides a number of authentication methods. Authentication is client-driven: when one is prompted for a password, it may be the SSH client prompting, not the server. The server merely responds to the client's authentication requests. Widely used user-authentication methods include the following:
    • password: a method for straightforward password authentication, including a facility allowing a password to be changed. Not all programs implement this method.
    • publickey: a method for public key-based authentication, usually supporting at least DSA（英語：Digital Signature Algorithm） or RSA keypairs, with other implementations also supporting X.509 certificates.
    • keyboard-interactive (RFC 4256): a versatile method where the server sends one or more prompts to enter information and the client displays them and sends back responses keyed-in by the user. Used to provide one-time password authentication such as S/Key（英語：S/Key） or SecurID（英語：SecurID）. Used by some OpenSSH configurations when PAM（英語：Pluggable authentication modules） is the underlying host-authentication provider to effectively provide password authentication, sometimes leading to inability to log in with a client that supports just the plain password authentication method.
    • GSSAPI（英語：Generic Security Services Application Program Interface） authentication methods which provide an extensible scheme to perform SSH authentication using external mechanisms such as Kerberos 5 or NTLM（英語：NTLM）, providing single sign-on capability to SSH sessions. These methods are usually implemented by commercial SSH implementations for use in organizations, though OpenSSH does have a working GSSAPI implementation.
  • The connection layer (RFC 4254). This layer defines the concept of channels, channel requests and global requests using which SSH services are provided. A single SSH connection can host multiple channels simultaneously, each transferring data in both directions. Channel requests are used to relay out-of-band channel-specific data, such as the changed size of a terminal window or the exit code of a server-side process. The SSH client requests a server-side port to be forwarded using a global request. Standard channel types include:
    • shell for terminal shells, SFTP and exec requests (including SCP transfers)
    • direct-tcpip for client-to-server forwarded connections
    • forwarded-tcpip for server-to-client forwarded connections
  • The SSHFP DNS record (RFC 4255) provides the public host key fingerprints in order to aid in verifying the authenticity of the host.

This open architecture provides considerable flexibility, allowing the use of SSH for a variety of purposes beyond a secure shell. The functionality of the transport layer alone is comparable to Transport Layer Security (TLS); the user-authentication layer is highly extensible with custom authentication methods; and the connection layer provides the ability to multiplex many secondary sessions into a single SSH connection, a feature comparable to BEEP（英語：BEEP） and not available in TLS.

改進

[編輯]

These are intended for performance enhancements of SSH products:

  • SSH-over-SCTP: support for SCTP rather than TCP as the connection oriented transport layer protocol.[16]
  • ECDSA: support for elliptic curve DSA rather than DSA or RSA for signing.[17]
  • ECDH: support for elliptic curve Diffie–Hellman rather than plain Diffie–Hellman for encryption key exchange.[17]
  • UMAC（英語：UMAC）: support for UMAC rather than HMAC for MAC/integrity.[18]

弱點

[編輯]

SSH-1

[編輯]

In 1998 a vulnerability was described in SSH 1.5 which allowed the unauthorized insertion of content into an encrypted SSH stream due to insufficient data integrity protection from CRC-32 used in this version of the protocol.[19][20] A fix known as SSH Compensation Attack Detector[21] was introduced into most implementations. Many of these updated implementations contained a new integer overflow vulnerability[22] that allowed attackers to execute arbitrary code with the privileges of the SSH daemon, typically root.

In January 2001 a vulnerability was discovered that allows attackers to modify the last block of an IDEA-encrypted session.[23] The same month, another vulnerability was discovered that allowed a malicious server to forward a client authentication to another server.[24]

Since SSH-1 has inherent design flaws which make it vulnerable, it is now generally considered obsolete and should be avoided by explicitly disabling fallback to SSH-1.[來源請求] Most modern servers and clients support SSH-2.[來源請求]

CBC plaintext recovery

[編輯]

In November 2008, a theoretical vulnerability was discovered for all versions of SSH which allowed recovery of up to 32 bits of plaintext from a block of ciphertext that was encrypted using what was then the standard default encryption mode, CBC.[25] The most straightforward solution is to use CTR, counter mode, instead of CBC mode, since this renders SSH resistant to the attack.[25]

Undisclosed vulnerabilities

[編輯]

On December 28, 2014 Der Spiegel published classified information[5] leaked by whistleblower Edward Snowden which suggests that the National Security Agency may be able to decrypt some SSH traffic. The technical details associated with such a process were not disclosed.

US Government Hack of SSH Protocols Confirmed

[編輯]

On 6 July, 2017, the government transparency activist organization WikiLeaks released US Central Intelligence Agency documents that revealed how the CIA's Information Operations Center hacks into "secure" communications that utilize the SSH protocol on both Windows and Linux operating systems. The release included official user guides for the CIA's BothanSpy and Gyrfalcon programmes which "are designed to intercept and exfiltrate SSH credentials but work on different operating systems with different attack vectors" WikiLeaks reported.

"BothanSpy is an implant that targets the SSH client program Xshell on the Microsoft Windows platform and steals user credentials for all active SSH sessions. These credentials are either username and password in case of password-authenticated SSH sessions or username, filename of private SSH key and key password if public key authentication is used. BothanSpy can exfiltrate the stolen credentials to a CIA-controlled server (so the implant never touches the disk on the target system) or save it in an enrypted file for later exfiltration by other means. BothanSpy is installed as a Shellterm 3.x extension on the target machine.

"Gyrfalcon is an implant that targets the OpenSSH client on Linux platforms (centos,debian,rhel,suse,ubuntu). The implant can not only steal user credentials of active SSH sessions, but is also capable of collecting full or partial OpenSSH session traffic. All collected information is stored in an encrypted file for later exfiltration. It is installed and configured by using a CIA-developed root kit (JQC/KitV) on the target machine."[26]

標準文件

[編輯]

The following RFC publications by the IETF "secsh" working group（英語：working group） document SSH-2 as a proposed Internet standard.

  • RFC 4250, The Secure Shell (SSH) Protocol Assigned Numbers
  • RFC 4251, The Secure Shell (SSH) Protocol Architecture
  • RFC 4252, The Secure Shell (SSH) Authentication Protocol
  • RFC 4253, The Secure Shell (SSH) Transport Layer Protocol
  • RFC 4254, The Secure Shell (SSH) Connection Protocol
  • RFC 4255, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
  • RFC 4256, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
  • RFC 4335, The Secure Shell (SSH) Session Channel Break Extension
  • RFC 4344, The Secure Shell (SSH) Transport Layer Encryption Modes
  • RFC 4345, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol

It was later modified and expanded by the following publications.

  • RFC 4419, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol (March 2006)
  • RFC 4432, RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol (March 2006)
  • RFC 4462, Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol (May 2006)
  • RFC 4716, The Secure Shell (SSH) Public Key File Format (November 2006)
  • RFC 4819: Secure Shell Public Key Subsystem (March 2007)
  • RFC 5647: AES Galois Counter Mode for the Secure Shell Transport Layer Protocol (August 2009)
  • RFC 5656, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer (December 2009)
  • RFC 6187: X.509v3 Certificates for Secure Shell Authentication (March 2011)
  • RFC 6239: Suite B Cryptographic Suites for Secure Shell (SSH) (May 2011)
  • RFC 6594: Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records
  • RFC 6668, SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol (July 2012)
  • RFC 7479: Ed25519 SSHFP Resource Records

In addition, the OpenSSH project includes several vendor protocol specifications/extensions:

參見

[編輯]

參考文獻

[編輯]
  1. ^ The Secure Shell (SSH) Protocol Architecture. RFC 4251. IETF Network Working Group. 2006-01. 
  2. ^ 2.0 2.1 2.2 The Secure Shell (SSH) Authentication Protocol. RFC 4252. IETF Network Working Group. 2006-01. 
  3. ^ Peter Bright. Microsoft bringing SSH to Windows and PowerShell. Ars Technica. 2015-06-02. 
  4. ^ SSH Hardens the Secure Shell, Serverwatch.com
  5. ^ 5.0 5.1 Prying Eyes: Inside the NSA's War on Internet Security. Spiegel Online. 2014-12-28. 
  6. ^ BothanSpy. wikileaks.org. 2017-07-06 [2017-09-25]. 
  7. ^ SSH setup manual
  8. ^ Service Name and Transport Protocol Port Number Registry. iana.org. 
  9. ^ Amies, A; Wu, C F; Wang, G C; Criveti, M. Networking on the cloud. IBM developerWorks. 2012. 
  10. ^ Tatu Ylönen. The new skeleton key: changing the locks in your network environment. 2013-04-02. 
  11. ^ Tatu Ylönen. SSH Port. 
  12. ^ Nicholas Rosasco and David Larochelle. How and Why More Secure Technologies Succeed in Legacy Markets: Lessons from the Success of SSH (PDF). Quoting Barrett（英語：Daniel J. Barrett） and Silverman, SSH, the Secure Shell: The Definitive Guide, O'Reilly & Associates (2001). Dept. of Computer Science, Univ. of Virginia. [2006-05-19]. 
  13. ^ OpenSSH: Project History and Credits. openssh.com. 2004-12-22 [2014-04-27]. 
  14. ^ OSSH Information for VU#419241
  15. ^ RFC 4253, section 5. Compatibility With Old SSH Versions. RFC 4253. IETF Network Working Group. 2006-01. 
  16. ^ Seggelmann, R.; Tuxen, M.; Rathgeb, E.P. SSH over SCTP — Optimizing a multi-channel protocol by adapting it to SCTP. Communication Systems, Networks & Digital Signal Processing (CSNDSP), 2012 8th International Symposium on. 18–20 July 2012: 1–6. ISBN 978-1-4577-1473-3. doi:10.1109/CSNDSP.2012.6292659. 
  17. ^ 17.0 17.1 Stebila, D.; Green J. RFC5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer. December 2009 [2012-11-12]. 
  18. ^ Miller, D.; Valchev, P. The use of UMAC in the SSH Transport Layer Protocol / draft-miller-secsh-umac-00.txt. 2007-09-03 [2012-11-12]. 
  19. ^ SSH Insertion Attack
  20. ^ Weak CRC allows packet injection into SSH sessions encrypted with block ciphers, US-CERT
  21. ^ SSH CRC-32 Compensation Attack Detector Vulnerability, SecurityFocus
  22. ^ SSH CRC32 attack detection code contains remote integer overflow, US-CERT
  23. ^ Weak CRC allows last block of IDEA-encrypted SSH packet to be changed without notice, US-CERT
  24. ^ SSH-1 allows client authentication to be forwarded by a malicious server to another server, US-CERT
  25. ^ 25.0 25.1 SSH CBC vulnerability, US-CERT
  26. ^ BothanSpy. www.wikileaks.org. 2017-07-06 [2017-07-09]. 

擴充閱讀

[編輯]
  • Daniel J. Barrett（英語：Daniel J. Barrett）, Richard E. Silverman, and Robert G. Byrnes, SSH: The Secure Shell (The Definitive Guide), O'Reilly 2005 (2nd edition). ISBN 0-596-00895-3
  • Michael Stahnke, Pro OpenSSH, Apress 2005 ISBN 1-59059-476-2
  • Tatu Ylönen. Announcement: Ssh (Secure Shell) Remote Login Program. comp.security.unix. 1995-07-12.  Original announcement of Ssh
  • Himanshu Dwivedi; Implementing SSH, Wiley 2003. ISBN 978-0-471-45880-7
  • 本條目部分或全部內容出自以GFDL授權發佈的《自由線上電腦詞典》（FOLDOC）。

外部連結

[編輯]
維基共享資源上的相關多媒體資源：幻想鄉的反逆者/沙盒
取自 "https://zh.wikipedia.org/w/index.php?title=User:幻想乡的反逆者/沙盒&oldid=46804573"