SSH 加密和连接过程

1. 介绍

SSH 或 secure shell 是一种安全协议,是安全管理远程服务器的最常用方法。使用多种加密技术,SSH 提供了一种机制,用于在双方之间建立加密安全连接,向另一方验证每一方,以及来回传递命令和输出。

在其他指南中,我们讨论了如何配置基于 SSH 密钥的访问,如何使用 SSH 进行连接以及一些 SSH 提示和技巧。

在本指南中,我们将研究 SSH 采用的基础加密技术以及它用于建立安全连接的方法。此信息可用于了解各种加密层以及形成连接和验证双方所需的不同步骤。

2. 对称加密,非对称加密和哈希

为了确保信息的传输,SSH 在事务中的各个点采用了许多不同类型的数据操作技术。这些包括对称加密,非对称加密和散列的形式。

2.1 对称加密

加密和解密数据的组件的关系决定加密方案是对称的还是非对称的。

对称加密是一种加密类型,其中一个密钥可用于加密对方的消息,也可用于解密从另一个参与者接收的消息。这意味着持有该密钥的任何人都可以加密和解密持有该密钥的任何其他人的消息。

这种类型的加密方案通常称为“共享秘密”加密或“秘密密钥”加密。通常只有一个密钥用于所有操作,或者一对密钥,其中关系易于发现,并且导出相反的密钥是微不足道的。

SSH 使用对称密钥来加密整个连接。与某些用户假设的相反,可以创建的公共/私有非对称密钥对仅用于身份验证,而不是用于加密连接。对称加密允许对密码认证进行保护以防止窥探。

客户端和服务器都有助于建立此密钥,并且外部各方永远不知道所产生的秘密。密钥是通过称为密钥交换算法的过程创建的。这种交换导致服务器和客户端通过共享某些公共数据并用某些秘密数据操纵它们而独立地到达相同的密钥。稍后将更详细地解释该过程。

此过程创建的对称加密密钥是基于会话的,并构成服务器和客户端之间发送的数据的实际加密。一旦建立,其余数据必须使用此共享密钥加密。这是在验证客户端之前完成的。

SSH 可以配置为使用各种不同的对称密码系统,包括 AES,Blowfish,3DES,CAST128 和 Arcfour。服务器和客户端都可以根据优先顺序决定其支持的密码列表。服务器上可用的客户端列表中的第一个选项用作两个方向的密码算法。

在 Ubuntu 14.04 上,客户端和服务器都是默认的:aes128-ctraes192-ctraes256-ctrarcfour256arcfour128aes128-gcm@openssh.comaes256-gcm@openssh.comchacha20-poly1305@openssh.comaes128-cbcblowfish-cbccast128-cbcaes192-cbcaes256-cbcarcfour

这意味着如果两台 Ubuntu 14.04 计算机相互连接(不通过配置选项覆盖默认密码),它们将始终使用aes128-ctr密码加密其连接。

2.2 非对称加密

非对称加密与对称加密的不同之处在于,为了在单个方向上发送数据,需要两个相关的密钥。其中一个密钥称为私钥,而另一个称为公钥

公钥可以与任何一方自由共享。它与其配对密钥相关联,但私钥不能从公钥中派生。公钥和私钥之间的数学关系允许公钥加密只能由私钥解密的消息。这是一种单向能力,这意味着公钥无法解密它写入的消息,也无法解密私钥可能发送的任何内容。

私钥应保密,绝不应与另一方共享。这是公钥范式的关键要求。私钥是唯一能够解密使用关联公钥加密的消息的组件。凭借这一事实,任何能够解密这些消息的实体已经证明它们可以控制私钥。

SSH 在几个不同的地方使用非对称加密。在用于建立对称加密(用于加密会话)的初始密钥交换过程中,使用非对称加密。在这个阶段,双方都生成临时密钥对并交换公钥,以便产生将用于对称加密的共享密钥。

使用 SSH 进行非对称加密的更好讨论来自基于 SSH 密钥的身份验证。 SSH 密钥对可用于向服务器验证客户端。客户端创建密钥对,然后将公钥上载到其希望访问的任何远程服务器。它放在远程服务器上用户帐户主目录的~/ .ssh目录下名为authorized_keys的文件中。

在建立对称加密以保护服务器和客户端之间的通信之后,客户端必须进行身份验证以允许访问。服务器可以使用此文件中的公钥来加密到客户端的质询消息。如果客户端可以证明它能够解密此消息,则表明它拥有相关的私钥。然后,服务器可以为客户端设置环境。

2.3 哈希

SSH 利用的另一种形式的数据操作是加密散列。加密散列函数是创建简洁“签名”或一组信息摘要的方法。它们的主要区别在于它们永远不会被颠倒,它们几乎不可能以可预测的方式影响,它们实际上是独一无二的。

使用相同的散列函数和消息应该产生相同的散列;修改数据的任何部分应该产生完全不同的哈希。用户不应该能够从给定的哈希生成原始消息,但是他们应该能够判断给定的消息是否产生给定的哈希。

鉴于这些属性,散列主要用于数据完整性目的并验证通信的真实性。 SSH 中的主要用途是使用 HMAC 或基于散列的消息验证代码。这些用于确保收到的消息文本完整且未经修改。

作为上面概述的对称加密协商的一部分,选择消息认证码(MAC)算法。通过客户端可接受的 MAC 选择列表来选择算法。将使用服务器支持的列表中的第一个。

协商加密后发送的每条消息都必须包含 MAC,以便另一方可以验证数据包的完整性。 MAC 是根据对称共享密钥,消息的分组序列号和实际消息内容计算的。

MAC 本身作为数据包的最后部分发送到对称加密区域之外。研究人员通常建议首先加密数据,然后计算 MAC。

3. SSH如何工作?

您可能已经基本了解 SSH 的工作原理。 SSH 协议使用客户端 - 服务器模型来验证双方并加密它们之间的数据。

服务器组件侦听指定的端口以进行连接。它负责协商安全连接,验证连接方,并在接受凭证时生成正确的环境。

客户端负责开始与服务器的初始 TCP 握手,协商安全连接,验证服务器的身份是否与先前记录的信息匹配,以及提供身份验证的凭据。

SSH 会话分两个阶段建立。首先是同意并建立加密以保护未来的通信。第二阶段是对用户进行身份验证,并发现是否应授予对服务器的访问权限。

4. 协商会话加密

当客户端建立 TCP 连接时,服务器会使用它支持的协议版本进行响应。如果客户端可以匹配其中一个可接受的协议版本,则继续连接。服务器还提供其公共主机密钥,客户端可以使用该密钥来检查这是否是预期的主机。

此时,双方使用称为 Diffie-Hellman 算法的版本协商会话密钥。该算法(及其变体)使得每一方能够将他们自己的私有数据与来自另一系统的公共数据组合以得到相同的秘密会话密钥。

会话密钥将用于加密整个会话。用于此部分过程的公钥和私钥对与用于向服务器验证客户端的SSH密钥完全分开。

经典 Diffie-Hellman 秘钥协商的基本流程为:

  1. 双方都同意一个大的素数,它将作为种子值。
  2. 双方就密文生成器(通常为 AES)达成一致,该生成器将用于以预定义的方式操纵值。
  3. 独立地,每一方都提出另一个素数,该号码对另一方保密。此编号用作此交互的私钥(与用于身份验证的专用 SSH 密钥不同)。
  4. 生成的私钥,密文生成器和共享素数用于生成从私钥导出但可以与另一方共享的公钥。
  5. 然后两个参与者交换他们生成的公钥。
  6. 接收实体使用他们自己的私钥,另一方的公钥和原始共享素数来计算共享密钥。虽然这是由各方独立计算的,但使用相反的私钥和公钥,它将产生相同的共享密钥。
  7. 然后使用共享密钥加密随后的所有通信。

用于其余连接的共享秘密加密称为二进制数据包协议。上述过程允许每一方平等地参与生成共享秘密,这不允许一端控制秘密。它还完成了生成相同的共享秘密的任务,而无需通过不安全的通道发送该信息。

生成的秘密是对称密钥,这意味着用于加密消息的相同密钥可用于在另一侧解密它。这样做的目的是将所有进一步的通信包装在一个无法被外人破译的加密隧道中。

建立会话加密后,用户身份验证阶段开始。

5. 验证用户对服务器的访问权限

下一阶段涉及验证用户和决定访问权限。根据服务器接受的内容,有几种不同的方法可用于身份验证。

最简单的可能是密码验证,其中服务器只是提示客户端输入他们尝试登录的帐户的密码。密码通过协商加密发送,因此对外方是安全的。

即使密码将被加密,由于密码复杂性的限制,通常不建议使用此方法。与其他身份验证方法相比,自动脚本可以非常轻松地破坏正常长度的密码。

最受欢迎和推荐的替代方案是使用 SSH 密钥对。 SSH 密钥对是非对称密钥,这意味着两个关联密钥服务于不同的功能。

公钥用于加密只能使用私钥解密的数据。公钥可以自由共享,因为虽然它可以加密私钥,但是没有从公钥导出私钥的方法。

在建立对称加密之后,使用 SSH 密钥对进行身份验证,如上一节所述。程序如下:

  1. 客户端首先向服务器发送要对其进行身份验证的密钥对的 ID。
  2. 服务器检查客户端尝试登录密钥ID的帐户的 authorized_keys 文件。
  3. 如果在文件中找到具有匹配 ID 的公钥,则服务器生成随机数并使用公钥加密该号码。
  4. 服务器向客户端发送此加密消息。
  5. 如果客户端实际上具有关联的私钥,则它将能够使用该密钥解密消息,从而显示原始号码。
  6. 客户端将解密的号码与用于加密通信的共享会话密钥组合,并计算该值的 MD5 哈希值。
  7. 然后,客户端将此 MD5 哈希值发送回服务器,作为加密号码消息的答案。
  8. 服务器使用相同的共享会话密钥和它发送给客户端的原始编号来自行计算 MD5 值。它将自己的计算与客户端发回的计算进行比较。如果这两个值匹配,则证明客户端拥有私钥并且客户端已经过身份验证。

如您所见,密钥的不对称性允许服务器使用公钥加密到客户端的消息。然后,客户端可以通过正确解密消息来证明它拥有私钥。使用的两种类型的加密(对称共享密钥和非对称公钥 - 私钥)都能够利用它们在此模型中的特定优势。

6. 总结

了解 SSH 中的连接协商步骤和加密层可以帮助您更好地了解登录到远程服务器时发生的情况。 希望您现在能够更好地了解各种组件和算法之间的关系,并了解所有这些组件如何组合在一起。

7. 原文

https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,098评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,213评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,960评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,519评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,512评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,533评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,914评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,574评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,804评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,563评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,644评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,350评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,933评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,908评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,146评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,847评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,361评论 2 342

推荐阅读更多精彩内容