什么是SSH，它如何工作？

小号治愈 嘘ell（SSH）是一种通用的安全协议，具有多种用途。它最著名的应用程序允许用户 安全地访问远程计算机和服务器, 但它也可以用于隧道，端口转发，安全文件传输等.

在本指南中，我们将介绍 SSH是什么，它的用途，协议的历史记录，其技术细节, 以及 安全问题 需要考虑的.

SSH由三个独立的协议组成： 传输层，认证层和连接层. 它们一起用于验证连接中的另一方，通过加密提供机密性，并检查数据的完整性。 SSH现在最普遍地实现为专有SSH-2或开源迭代OpenSSH.

SSH的用途

SSH是一种通用协议。它的结构和安全功能允许它以多种方式使用，例如用于远程访问，端口转发，隧道和安全文件传输.

远程访问

远程访问为用户提供了一种方法 从自己的计算机登录到另一台计算机或服务器. 它用于访问目标计算机的本地文件或在其上执行服务，而无需物理上存在.

Telnet和rlogin之类的程序也具有此功能，但是它们缺少SSH的安全性功能。 SSH涉及的加密和身份验证措施使用户即使在潜在危险的中间网络上也可以受保护的方式连接到另一台服务器或计算机。.

通常使用SSH进行远程访问，以便员工可以远程工作，或者允许IT部门完成任务而不必亲自去计算机。它可用于远程管理，网络基础结构管理，设置自动化，创建备份等.

转发端口

端口转发用于将请求从一个地址和端口号传输到另一组。它应用网络地址转换（NAT）在本地网络和远程计算机之间重定向端口，从而使您可以从网络外部访问设备.

可以通过三种不同的方式完成端口转发：

• 本地 转发端口 –本地端口转发使您可以连接本地客户端和外部网络。它可以有效地进行某些操作，例如访问在本地被阻止的网站，或连接到位于防火墙后面的数据库.
• 远程端口转发 –这种类型的转发使服务器端应用程序可以访问客户端上的服务。 SSH的远程端口转发使用户可以将本地端口重定向到远程SSH服务器，从而通过其本地PC安全地连接到远程服务器.
• 动态 转发端口 –这允许用户使用许多充当代理的SSH服务器，通过特定端口将其数据发送到远程计算机或服务器.

隧道式

隧道协议使用封装在网络之间移动数据。可以部署隧道，以允许非本机协议通过通常不支持它们的网络运行。另一个常见的用途是 通过不安全的网络提供安全性.

隧道协议将关键数据包包装在另一个数据包的有效载荷内。 SSH隧道允许用户绕过网络安全性，使用非本机网络协议链接设备，并保护正在传输的数据。它们通常用于以安全的方式将远程用户连接到组织的在线资源。.

SFTP

SSH文件传输协议（FTP），有时也称为安全文件传输协议，提供了一种访问，传输和管理文件的安全方法。它是FTP的安全替代方案，并利用SSH协议安全地发送，接收和管理文件.

SCP

安全复制协议（SCP）与SFTP类似，但范围有所限制。它仅允许安全的文件传输，而不能使用允许SFTP充当远程文件系统协议的全部功能。.

平台类 & 使用SSH的应用程序

专有SSH或OpenSSH可以在所有主要操作系统上使用。它可在基于Unix的平台上使用，例如OpenBSD，macOS，Linux和Solaris，而Windows用户可以通过PowerShell使用SSH。.

SSH的历史

SSH由TatuYlönen于1995年在赫尔辛基工业大学开发，以响应对该大学网络的密码嗅探攻击。它旨在为诸如以下协议提供替代方案 FTP，TELNET，rsh 和 登陆, 无法确保机密性或以安全方式对用户进行身份验证.

SSH于1995年免费向公众发布，并广受欢迎。在迅速采用SSH的同时，Ylönen于同年年底建立了SSH Communications Security，以继续进行SSH的开发和商业化.

1995年，Ylönen还发布了Internet工程任务组（IETF）Internet草案，该草案 记录了SSH-1协议. 协议中很快发现了局限性，在不影响向后兼容性的情况下就无法解决这些局限性。该解决方案是该协议的新版本，SSH-2由Ylönen公司于1996年推出.

SSH-2采用了新算法，这促使IETF成立了一个旨在对该协议进行标准化的工作组。该小组的昵称是SECSH， 秒尿 嘘ell，并在1997年发布了第一个SSH-2互联网草案.

用于SSH-2的软件于1998年发布，但由于其限制性更强的许可，因此并未立即被广泛采用。. 在2006年，IETF将该协议的变更版本作为标准. 使用消息身份验证代码来检查完整性以及使用Diffie-Hellman密钥交换进行身份验证，这是更安全的.

在1999年，OpenBSD项目发布了OpenSSH. OpenSSH是该协议的免费版本 这是基于BjörnGrönvall对SSH 1.1.12进行的修改。开发人员返回此旧版本并对其进行了重大更改，因为它是完全开源的SSH最新版本。 OpenSSH现在是使用最广泛的选项，并且此后已在多种操作系统中实现，例如Windows，macOS，Linux，Solaris等.

SSH-1 vs SSH-2 vs OpenSSH

如上所述，SSH-1是该协议的第一个版本，最初是在 开源许可证. 它被认为是不安全的，因此不应实施。这将专有版本SSH-2和免费版本OpenSSH作为可行的替代方案。.

SSH-2和OpenSSH在架构和工作方式上基本相同。主要区别在于专有版本带有一系列支持选项，而使用OpenSSH的版本则需要依靠社区自由创建的资源。.

SSH：技术细节

SSH-1只能作为一个协议使用，但由于它已过时，因此在此不再赘述。相反，我们将专注于SSH-2和OpenSSH，它们均由三个独立的协议组成：

• 传输协议 –这将建立连接并提供基础安全性.
• 认证协议 –该层用于验证客户端.
• 连接协议 –该协议处理通过其传输数据的通道.

这些协议中的每一个都扮演着独特的角色，该角色致力于建立和保护连接，认证对方并传输数据。默认的TCP连接端口为22，并在SSH客户端和SSH服务器之间建立连接， 客户-服务器模型.

SSH的远程登录过程根据以下基本结构（视配置而异）进行，稍后我们将对其进行详细介绍：

• 客户端联系SSH服务器开始连接.
• 然后，服务器将其公钥发送给客户端以验证其身份.
• 双方协商连接的参数，然后沿这些线路建立安全通道.
• 然后，用户登录到服务器主机的操作系统，现在可以远程管理其任务.

传输协议

传输层是一个低层协议，它负责以下任务.

• 服务器主机认证
• 密钥交换
• 数据保密加密
• 完整性检查以验证数据没有被更改
• 建立可以在其他协议中使用的会话ID

的 传输协议仅对服务器进行身份验证，而不对客户端进行身份验证 （如果需要，则在身份验证协议中完成客户端身份验证）.

在传输层中，连接由客户端发起，然后由双方协商如何交换密钥，将使用哪种公钥算法，哪种对称密钥密码将加密数据，将使用哪种消息身份验证算法。检查数据，以及将采​​用哪种压缩方法（如果有）.

连接一旦开始，服务器和客户端都需要通过标识字符串发送，该字符串包括协议版本（2.0）.

算法协商

要设置连接的参数，双方都要通过包含以下选项的列表的数据包进行发送：

字节SSH_MSG_KEXINIT

字节[16] cookie（随机字节）
名称列表kex_algorithms
名称列表server_host_key_algorithms
名称列表encryption_algorithms_client_to_server
名称列表encryption_algorithms_server_to_client
名称列表mac_algorithms_client_to_server
名称列表mac_algorithms_server_to_client
名称列表compression_algorithms_client_to_server
名称列表compression_algorithms_server_to_client
名称列表语言_client_to_server
名称列表语言_server_to_client
布尔值first_kex_packet_follows
uint32 0（保留以供将来扩展）

每一面都列出了他们愿意在连接中接受的参数，以逗号分隔。首选算法应首先列出.

对于 密钥交换 （kex_algorithms），将选择双方都支持的第一种算法进行连接（根据选择的算法，还可能需要满足其他因素）。如果双方都找不到满足这些要求的相互支持的算法，则连接失败.

服务器主机密钥算法 是服务器主机密钥支持的算法。服务器对具有主机密钥的算法进行布局，而客户端则指定准备接受的算法。选择将取决于确定的密钥交换方法是否需要具有加密功能的主机密钥或数字签名。

双方列出 对称密钥算法 他们愿意接受的方法，顶部是首选方法。必须使用出现在客户端列表上的第一个选项，该选项也恰好在服务器列表上。如果无法达成协议，则连接失败.

这俩 MAC算法 和 压缩算法 以相同的方式谈判.

密钥交换

密钥交换负责 服务器认证, 和它 设置将用于保护连接的密钥 在以下步骤中。通常从各方将彼此支持的算法列表相互发送开始。另外，双方可以猜测对方的首选算法，并在开始时发送适合该算法参数的数据包.

如果一方的猜测是正确的，则将该数据包用作第一个密钥交换数据包。如果没有一个正确的猜测，那么双方都必须退后一步，并发送自己的首选算法列表。如果密钥交换消息中包含服务器的数字签名作为服务器合法性的证明，则认为 显式服务器身份验证. 如果它改用共享机密，则称为 隐式服务器身份验证.

密钥交换还负责建立共享机密和哈希。来自初始密钥交换的哈希值成为会话的唯一标识符，还用作数字签名的一部分，以证明该方是其私钥的真正所有者。.

使用的哈希函数将取决于协商中确定的密钥交换方法。密钥交换完成后，以后的所有通信将使用新的密钥和算法集.

根据Internet工程任务组（IETF）Internet草案，以下密钥交换方法被认为是安全的：

• 曲线25519-sha256
• 曲线448-sha512
• diffie-hellman-group-exchange-sha256
• diffie-hellman-group14-sha256
• diffie-hellman-group15-sha512
• diffie-hellman-group16-sha512
• diffie-hellman-group17-sha512
• diffie-hellman-group18-sha512
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• gss-group14-sha256
• gss-group15-sha512
• gss-group16-sha512
• gss-group17-sha512
• gss-group18-sha512
• gss-nistp256-sha256
• gss-nistp384-sha384
• gss-nistp521-sha512
• gss-curve25519-sha256
• gss-curve448-sha512
• rsa2048-sha256

服务器主机密钥算法

这些公钥算法用于 服务器身份验证以及安全地建立共享会话ID. 也可以选择使用它们来验证主机。 SSH旨在与多种公钥算法，编码类型和格式一起使用：

• 它使用公钥算法进行加密和/或数字签名.
• 可以实现多种编码方法，从而允许使用不同的数据格式，填充和字节顺序进行配置.
• 各种密钥格式允许密钥以不同的方式进行编码以及一系列证书表示形式.

默认算法包括以下内容，但是还可以实现其他一些变体：

• ssh-rsa
• ssh-rsa-sha256
• ssh-dss
• ssh-dss-sha256
• x509v3-sign-dss
• x509v3-sign-dss-sha256
• x509v3-sign-rsa
• x509v3-sign-rsa-sha256

加密算法

对称密钥算法用于 加密数据并提供机密性. 在连接的早期阶段中建立了加密过程中使用的参数和共享密钥。选择的算法对有效负载，数据包长度，填充长度和填充字段进行加密.

SSH接受多种不同的加密算法，但是出于安全目的，最好坚持使用AES。密钥至少应为128位，但最好使用较大的密钥.

MAC算法

传输协议 通过向数据包添加消息验证码（MAC）来验证数据的完整性. 该MAC基于共享密钥（在密钥交换中建立），数据包序列号和数据包内容。在加密发生之前进行计算.

实现方案需要提供一种独立的算法以在每个方向上运行，但是如果在两侧都使用相同的算法则是理想的。可以实现各种各样的消息认证算法，但是在大多数情况下应使用SHA-256及更高版本，以确保高度的安全性.

压缩

在SSH协议中，压缩不是必需的，并且其实现必须允许连接继续进行而不进行压缩。压缩只能使用诸如 zlib. 如果使用压缩，则只会影响有效负载。然后根据压缩的有效载荷计算MAC和数据包长度字段.

传输协议包

传输协议包的格式设置为包括以下信息（以及一些无关紧要的详细信息，这些细节已被省略）：

• 包长
• 填充长度
• 有效载荷
• 填充
• 消息验证码（MAC）

认证协议

服务器使用此协议来 验证客户端. 它可以通过多种不同的机制来完成此任务，其中许多机制都依赖于传输协议中建立的会话ID。一些人将传输协议中的加密和完整性检查与会话ID结合使用，而另一些人单独使用这些算法.

服务器使用其本地策略来确定其从单个用户接受的身份验证方法。由于服务器已经通过传输协议进行了身份验证, 无需再次验证服务器.

身份验证协议的安全性取决于它运行在其顶部的传输协议。如果传输协议不能保证机密性或检查数据的完整性，那么这将限制如何安全使用身份验证协议.

例如，如果传输协议未应用完整性保护，则不应允许诸如密码更改之类的请求，因为这将使攻击者有机会篡改数据而不会被发现.

身份验证协议使用公共密钥身份验证，前提是服务器主机的私钥和客户端主机的密钥均未受到破坏. 如果服务器受到攻击，则可能导致客户端的用户名和密码被释放给攻击者.

为了确保基于主机的身份验证的安全，不得损害客户端。如果可能，则应添加其他身份验证方法。请务必注意 身份验证过程仅与服务器接受的最弱交换方法一样强.

认证协议过程

认证协议在服务器向客户端发送其接受的认证方法列表时开始。然后，客户端可以按任何顺序从这些方法中进行选择。此过程可以控制服务器，但也可以提供足够的灵活性，以便客户端可以安排使用最方便的方法.

最常见的客户端身份验证方法包括：

• 公钥 –该方法使用诸如RSA，DSA和ECDSA之类的算法通过公钥加密对客户端进行身份验证。一些实现也使用x.509证书。服务器根据客户的公钥检查客户的数字签名，以验证客户的身份.
• 密码 –密码也可以用于验证客户端。客户端通过其密码发送（该密码应由传输协议加密）。如果密码与服务器的存储值匹配，则表示密码被接受并且身份验证继续进行.
• GSSAPI –在这种方法下，可以将诸如Kerberos之类的外部方案用于单点登录.
• 键盘互动 –该技术通过让服务器提示客户端输入信息来提供一次性密码认证.

连接协议

连接协议列出 如何在安全传输层上合并多个数据通道. 它还处理用于访问服务器主机上的安全子系统以及代理转发和访问Shell的参数。.

连接协议位于传输层和身份验证协议的顶部。它允许远程命令执行，以及转发的X11和TCP / IP连接。如果服务器或客户端受到威胁，则连接协议不安全.

频道

通道是基本的通信路径，任何一方都可以打开它们。频道可以包括终端会话，转发的连接和其他形式的通信。当有多个通道时，它们被复用为一个连接.

开通渠道

每个通道的两端都有编号，尽管两侧的编号可能不同。当一方请求打开频道时，它发送其频道号作为消息的一部分，以及有关 初始窗口大小 和 最大封包大小.

初始窗口大小指示打开通道的一方可以接收多少数据。如果需要发送更多数据，则必须先调整窗口。同样，最大数据包大小指定可以接收多少数据包.

当一侧要求打开通道时，另一侧将在可以容纳的情况下打开通道。如果不是，它将通过失败消息发送。可能由于以下原因而无法打开通道：

• 被政府禁止
• 连接失败
• 未知的频道类型
• 资源短缺

如果连接的任一端要发送的数据超出窗口当前允许的数量，则他们可以发送一条消息，要求添加更多字节.

关闭频道

一旦连接的一侧完成了数据传输，它就应该发送一条消息，表明已完成使用该通道。尽管如此，通道仍保持打开状态，并且仍然可以由另一方发送数据。如果一方要完全终止该频道，则使用单独的终止消息来完成.

SSH安全

SSH的各种版本都有各自的安全性问题，尽管当前的SSH配置 SSH-2和OpenSSH被认为比SSH-1安全得多.

SSH-1

SSH-1通常被认为是有缺陷的，具有一系列不同的漏洞. 其中包括SSH 1.5中的错误，该错误允许未经授权的用户将内容插入SSH数据流。此攻击利用了CRC-32算法的最小数据完整性保护.

SSH补偿攻击检测器已将其缓解，该检测器已集成到大多数较新的实现中。此修复程序带有一个新漏洞，该漏洞能够以root用户特权执行任意代码.

还有一个漏洞使攻击者可以更改使用IDEA加密的会话中的最后一个阻止，以及一个允许受感染的服务器将客户端身份验证过程转发到其他服务器的漏洞。.

由于这些安全问题，应改用SSH-2。为了确保实施的安全性，您还应该 禁用重新协商到SSH-1, 因为攻击可以利用此优势通过SSH-1的保护级别较低来访问您的数据.

SSH-2

SSH-2对其默认的加密模式CBC易受理论攻击. 它使攻击者可以从加密的块中恢复多达32位的纯文本。可以通过使用计数器模式（CTR）并将分组密码转换为流密码来缓解这种情况.

2014年底，Der Spiegel发布了NSA文件，暗示NSA有时可能会破坏SSH。这份泄漏的NSA PowerPoint指出，NSA可以“可能恢复用户名和密码”，但未提供更多详细信息。目前尚不知道该机构采用了什么方法，但似乎不太可能依靠其内部文件中的功能.

在2023年的Vault 7泄密事件中， CIA有两个可以用来拦截和窃取SSH登录名和密码的工具. BothanSpy的目标是Windows Xshell客户端，而Gyrfalcon则针对许多不同Linux发行版上的OpenSSH客户端.

这些工具能够窃取凭据，然后将其传输回CIA服务器。这些攻击都不能破坏协议本身。他们只是使用在某些实现中可以绕过它的其他旁路攻击.

尽管有这些攻击，但只要适当实施，SSH-2在大多数情况下仍被认为是安全的。高价值目标或使用过时或实施不佳的人应考虑其他选择.

OpenSSH的

在OpenSSH版本2中, 发现一种利用SSH二进制数据包漏洞的攻击. 这次攻击使伦敦大学的研究人员从一个加密的块中恢复了14位纯文本。通过使协议读取无效的数据包长度或消息身份验证代码的整体，而不是终止连接，在版本5.2中对此进行了缓解.

在版本6.8和6.9中，Linux可用于在其他用户的终端上执行任意命令。这是通过特权升级漏洞实现的，该漏洞允许攻击者使用TIOCSTI输入/输出控件注入字符.

SSH安全吗?

SSH似乎有很多安全问题, 这是相对的通常，在协议的各种实现中都会发现许多漏洞。这并不意味着SSH协议是不安全的。相反，它只是意味着 需要正确实施.

只要您正在使用 SSH-2或OpenSSH，并且其配置方式适合您的使用方式，因此您应该对SSH提供连接的保护充满信心. 这就是为什么它仍然是如此频繁使用的协议的原因，特别是对于远程访问和隧道传输而言.

另请参阅：常见的加密类型说明

网络网络技术背景 由TheDigitalArtist根据 CC0