网络技术SSH工作原理 思科CCIE工程师必读-ielab
头条：
网络工程师的实用网络安全技术SSH工作原理 值得收藏
SEO：
网络技术SSH工作原理 思科CCIE工程师必读
SSH 为 Secure Shell 的缩写，由 IETF 的网络小组（Network Working Group）所制定；SSH 为建立在应用层基础上的安全协议。SSH 是较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH最初是UNIX系统上的一个程序，后来又迅速扩展到其他操作平台。SSH在正确使用时可弥补网络中的漏洞。SSH客户端适用于多种平台。
在整个通讯过程中，为实现SSH的安全连接，服务器端与客户端要经历如下五个阶段：
一、协商阶段：（明文方式传输）
1、服务器打开端口22，等待客户端连接。
2、客户端向服务器端发起TCP初始连接请求，TCP连接建立后，服务器向客户端发送第一个报文，包括版本标志字符串，格式为“SSH－主协议版本号.次协议版本号－软件版本号”，协议版本号由主版本号和次版本号组成，软件版本号主要是为调试使用。
3、客户端收到报文后，解析该数据包，如果服务器端的协议版本号比自己的低，且客户端能支持服务器端的低版本，就使用服务器端的低版本协议号，否则使用自己的协议版本号。
4、客户端回应服务器一个报文，包含了客户端决定使用的协议版本号。服务器比较客户端发来的版本号，决定是否能同客户端一起工作。
5、如果协商成功，则进入密钥和算法协商阶段，否则服务器端断开TCP连接。
二、密钥算法协商：
1、服务器端和客户端分别发送算法协商报文给对端，报文中包含自己支持的公钥算法列表、加密算法列表、MAC（Message Authentication Code，消息验证码）算法列表、压缩算法列表等。
2、服务器端和客户端根据对端和本端支持的算法列表得出最终使用的算法。
3、服务器端和客户端利用DH交换（Diffie-Hellman Exchange）算法、主机密钥对等参数，生成会话密钥和会话ID。
通过以上步骤，服务器端和客户端就取得了相同的会话密钥和会话ID。对于后续传输的数据，两端都会使用会话密钥进行加密和解密，保证了数据传送的安全。
认证阶段：
1、客户端向服务器端发送认证请求，认证请求中包含用户名、认证方法、与该认证方法相关的内容（如：password认证时，内容为密码）。
2、服务器端对客户端进行认证，如果认证失败，则向客户端发送认证失败消息，其中包含可以再次认证的方法列表。
3、客户端从认证方法列表中选取一种认证方法再次进行认证。
4、该过程反复进行，直到认证成功或者认证次数达到上限，服务器关闭连接为止。
四、会话请求阶段：
认证通过后，客户端向服务器发送会话请求。服务器等待并处理客户端的请求。在这个阶段，请求被成功处理后，服务器会向客户端回应SSH_SMSG_SUCCESS包，SSH进入交互会话阶段；否则回应SSH_SMSG_FAILURE包，表示服务器处理请求失败或者不能识别请求。
五、交互阶段
会话请求成功后，连接进入交互会话阶段。在这个模式下，数据被双向传送。客户端将要执行的命令加密后传给服务器，服务器接收到报文，解密后执行该命令，将执行的结果加密发还给客户端，客户端将接收到的结果解密后显示到终端上。
在交互阶段，客户端可以通过粘贴文本会话的方式发送要执行的命令，但文本会话不能超过2000字节。如果粘贴的文本会话超过2000字节，可以采用将配置文件上传到服务器，利用新的配置文件重新启动的方式执行这些命令。
了解最新开班，最新课程优惠，获取免费视频！一定要+WXdcm220681哦！
ssh密钥对登录安全吗？原理篇
在 《使用wireshark分析ssh口令登录细节》 和 《ssh工具，开发者必须有所了解》 这两篇文章中，我们知道了SSH登录有两种登录验证方式，其中口令登录方式使用简单，但会遇到安全问题，比如遇到中间人攻击，就会泄漏服务器的root口令。所以从安全的角度来看，建议使用另外一种登录验证方式，这就是密钥对登录方式。
密钥对验证方式对于初学者来说并不是很友好，所以我分两篇文章把这个事情说清楚，本文主要从原理的角度讲解，让你了解这种方式运作的流程，下一篇从实战的角度手把手教你登录ssh服务器。
对于开发者来说，也请务必学会使用密钥对方式登录服务器，因为现在很多应用和服务推荐这种方式，比如Github就可以使用密钥对方式连接，AWS默认就禁止口令登录。
网上有很多文章介绍ssh口令登录，但客观的说，很多文章讲错了。
很多人大概是这样理解的，客户端生成一个公开密码学算法的密钥对（注意不是ssh服务器端的密钥对），然后将公钥放到ssh服务器上的 authorized_keys 文件中（潜台词就是你有ssh权限才能操作）。
然后ssh如何登录呢?在连接过程中，会将客户端密钥对的公钥发送给ssh服务器，服务器在 authorized_keys 文件中匹配到这个公钥，就认为登录成功了，其实这个理解是有问题的。
核心的两个问题：
知道了这个结论后，我们看看详细的登录验证过程，在 《使用wireshark分析ssh口令登录细节》 中说过，ssh登录分为两个阶段，不管是哪一种登录验证，第一阶段的过程都是相同的，区别在于第二阶段。
有的同学说，这次你为啥不用wireshark分析了？因为第二阶段的消息传递都是加密保护的，并不能解密出具体的消息格式，这一点和TLS协议非常不同，TLS协议有多种方式可以解密出明文，而SSH协议是不支持的，所以wireshark只能显示密文。
基于这一点，本文就不用wireshark分析了，简单谈一谈ssh密钥对登录的流程，要经过多个消息交互。
第二阶段具体的流程如下：
1：ssh客户端生成一个 key ID（这个ID是基于密钥对的公钥算出来的，具体格式未知），再一次说明，这个密钥对不是服务器的，使用会话密钥加密后发送给服务器端。
2：服务器端从 authorized_keys 文件中匹配 key ID，如果匹配，此时还不能证明这个ssh客户端是真正的客户端密钥对的主人。
3：服务器端生成一个随机数，然后用客户端的公钥加密后发送给客户端。
4：客户端使用自己的私钥解密出服务器端的随机数，注意，如果某个攻击者仅仅有客户端的公钥，它是无法解密出的，因为攻击者没有对应的私钥。
5：为了向服务器端证明它能解密出这个随机数，客户端将解密出的随机数用会话密钥加密，将得到的值进行MD5运算。然后将这个值发送给服务器，以便响应（4）阶段的消息。
6：服务器端对原始随机数也使用会话密钥加密，再进行MD5计算，如果得出的值和（5）阶段客户端发送的一致，代表双方的登录校验通过。
服务器端使用服务器密钥对公钥指纹像客户端证明它就是真正的服务器端；而客户端使用它自己的密钥对向服务器证明它就是真实的客户端。
由于在验证过程中，客户端密钥对的公钥不会传输，所以即使遇到中间人攻击，攻击者也不会获取到公钥（不考虑客户端机器本身遇到攻击了）。
如果客户端的公钥曾经泄漏过，攻击者也不能成功登录ssh服务器，原因是攻击者没有私钥，无法解密出随机数，从而不能完成验证。
当然如果客户端密钥对公钥和私钥全部泄漏了，那就当我什么也没说，所以定期更换密钥对还是有好处的。
基于以上两点，我认为ssh密钥对登录是安全的，也是推荐的。
使用wireshark分析ssh口令登录细节
在 《ssh工具，开发者必须有所了解》 这篇文章中，概念性介绍了ssh知识，可对大多数人来说，会使用ssh工具才更有用，比如对我来说，成功登录ssh服务器后，才有动力继续了解其他ssh功能。
ssh登录通常有两种方式，分别是口令验证和密钥对验证，口令登录非常简单，运行 ssh root@localhost，然后输入正确口令后就能成功登录。
可你知道背后的细节吗？这也是我写这篇文章的目的，ssh协议和tls协议一样，都组合了很多密码学算法，用于解决网络安全问题，掌握ssh协议的原理对于理解密码学很有帮助，密码学算法有很多，比如AES对称密钥算法，公开密钥算法（DH密钥协商算法，RSA非对称加密算法），MAC算法，Hash算法，如果你大概了解这些算法，理解ssh协议会相对简单一点，否则可能会比较吃力。
了解ssh协议另外一个好处就是，遇到问题的时候就不会慌乱，也能够更安全的使用ssh。
本文先介绍相对简单的ssh口令登录，在介绍之前，先了解ssh协议的三个子协议：
这三个协议中，最后一个相对复杂，本文主要讲解前二个协议。
ssh口令登录主要分为两个阶段，第一阶段是协商出一个会话密钥，在客户端和服务器端之间构建一条安全的通道。第二个阶段在这条通道上验证客户端登录权限。
ssh服务器默认绑定在22端口，监听客户端的请求，在启动的时候会生成一个密钥对（公钥和私钥），一般是RSA算法密钥对，在第一阶段会将公钥发送给ssh客户端，主要让客户端确认ssh服务器端的身份，除了这个作用，我 目前 没有看到这个密钥对还有其他作用。
为什么说“目前”呢？因为我并没有看 ssh rfc 文档，是通过 wireshark 抓包了解 ssh 协议的，从概念性上 猜测 ssh协议原理。
先上一张图，看看ssh登录产生了那些包，大家可以wireshark抓包，然后过滤出ssh包（不看 tcp 包）：
其中红线就是ssh登录的第一阶段，该阶段一般输入 ssh root@localhost 就能产生。
另外蓝色就是ssh登录的第二阶段，输入口令后就会产生这些包。
接下去我们先介绍第一个阶段发生了什么：
1：客户端首先发送一个连接请求（序号4），告诉服务器端它目前支持的ssh版本号。
2：服务器端也响应ssh版本号，双方一般协商出的版本号是 ssh v2
3：客户端初始化连接（序号9），进行密钥交换，告诉客户端其支持的各类算法，如下图：
4：然后服务器端也告诉客户端其支持的各类算法（序号10），最后协商出一致的算法，并发送服务器公开密钥对的公钥。
5：如果第一次ssh登录，ssh客户端会提示用户确认服务器公开密钥对公钥的指纹（即公钥的md5值），当然这个在网络包中是体现不出来的。
如果你第一次ssh登录，会出现下图：
如果你确认该指纹就是你想连接ssh服务器的，那么就会将公钥保存到 ~/.ssh/known_hosts 文件中，下一次你再登录的时候，ssh客户端发现指纹和ssh服务器发送的指纹是一致的，就不会再让你确认了。
指纹非常重要，后面我会再说。
6：客户端接下去就是要发送 DH 算法密钥对的公钥了（序号13），注意这个密钥对和服务器公开密钥对不是一回事
不管是客户端还是服务器端，各自保留自己的 DH 密钥对的私钥，并将自己的 DH 密钥对的公钥发送给对方，这样双方就会协商出最终的会话密钥（用于对称加密）。
DH 算法就不多描述了，有兴趣可以看看我的书《深入浅出HTTPS：从原理到实战》，这个算法非常安全，黑客仅仅通过截获网络和机器也是破解不了的，因为各种的私钥都在内存中，也不会通过网络传输。
具体如下图：
7：服务器发送 DH 算法密钥对的公钥（序号15），双方协商出只有他们才知道的会话密钥。
8：客户端发送一个 New Keys 数据包（序号16），表示双方构建了一个加密通道。
上述就是ssh登录的第一阶段，第二阶段中产生的数据都会用会话密钥进行加密了。
第二阶段相对很简单，就是客户端决定验证方式，如果是口令验证，就是将口令加密发送给服务器，如果服务器确认了，就成功登录，具体如下图：
最后一个问题，这种方式登录安全吗？相对是安全的，因为口令并不是明文传输的。
但这种方式会遇到中间人攻击，还记得那个指纹吗？其实很少人会去确认这个指纹是不是属于“真实ssh服务器”的，一大串数字，还要你手动根据服务器发送的公钥计算指纹，然后再比较，真的很考验人。
如果你不确认，可能真的会有风险，想想看，如果在连接的时候，某个黑客截获了你的数据包，然后发送了他密钥对的公钥，而你没有确认指纹，那么后续所有的ssh数据包都是和黑客在通讯，他就会成功知道服务器口令了。
危险在于，你以为在和“真实ssh服务器”在通信，可实际上是和黑客在通信，有什么好的解决办法吗？如果是口令登录，确实没有，所以后面我会介绍另外一种登录验证方式。
ssh能防范中间人攻击吗，需不需要数字证书
其实SSH已经有自己的一套验证方式了，可以阻拦大不部分的攻击，当然有人撞库尝试密码，你只有设置防火墙或者做其它的安全措施了。
从客户端来看，SSH提供两种级别的安全验证。
第一种级别（基于口令的安全验证）
只要你知道自己帐号和口令，就可以登录到远程主机。所有传输的数据都会被加密，但是不能保证你正在连接的服务器就是你想连接的服务器。可能会有别的服务器在冒充真正的服务器，也就是受到“中间人”这种方式的攻击。
第二种级别（基于密匙的安全验证）
需要依靠密匙，也就是你必须为自己创建一对密匙，并把公用密匙放在需要访问的服务器上。如果你要连接到SSH服务器上，客户端软件就会向服务器发出请求，请求用你的密匙进行安全验证。服务器收到请求之后，先在该服务器上你的主目录下寻找你的公用密匙，然后把它和你发送过来的公用密匙进行比较。如果两个密匙一致，服务器就用公用密匙加密“质询”（challenge）并把它发送给客户端软件。客户端软件收到“质询”之后就可以用你的私人密匙解密再把它发送给服务器。
用这种方式，你必须知道自己密匙的口令。但是，与第一种级别相比，第二种级别不需要在网络上传送口令。第二种级别不仅加密所有传送的数据，而且“中间人”这种攻击方式也是不可能的（因为他没有你的私人密匙）。但是整个登录的过程可能需要10秒。
0条大神的评论