一、SSH的定义

1. SSH——secure shell；
2. SSH为计算机网络协议，用于计算机之间的加密通信，通过加密和认证机制实现安全的访问、远程登录和文件传输等业务；
3. SSH协议的默认端口号为22；
4. SSH协议通过对网络数据进行加密和验证，建立SSH客户端和SSH服务器之间的安全隧道，在不安全的网络环境中为网络服务提供了安全的传输通道。
5. “在SSH协议出现之前，Telnet广泛应用于远程登录场景，为远程管理网络设备提供了极大便利，而FTP作为常用的文件传输协议，兼具操作简单和传输效率高的优点，但它们都存在相同的问题，即明文传输数据带来的安全隐患。SSH采用加密传输数据、提升认证强度等手段，克服了Telnet和FTP应用中的安全性问题，实现了安全的远程登录和文件传输业务。” ——CSDN：ssh详解–让你彻底学会ssh
   

二、SSH的对称加密通信、非对称加密通信、对称加密+非对称加密通信原理概述

2.1 对称加密原理概述

1. 想要通信的两个计算机A、B，由A生成一个密钥key，A将密钥key发送给B，使得A、B双方知晓同一用于数据加密解密的key，A发送数据时使用key加密，B接受数据后使用key解密。古时的凯撒密码便是采用此种加密方式。
2. 优缺点
   1. 优点
      1. 原理简单易懂
   2. 缺点
      1. 一方产生密钥key后，需将密钥key告知通信的另一方，一旦被他人截获密钥key，则加密后信息将不再安全。
         

2.2 非对称加密原理

1. 为了解决互通密钥过程中密钥被截获后数据加密不再安全的问题，我们可采用公钥/私钥机制。
2. 欲通信的两个计算机A、B，主机A和B分别生成各自的一副公/私钥，如public_keyA、private_keyA；public_keyB、private_keyB；
3. 在非对称加密数据传输中公钥public_keyA与私钥private_keyA的关系
   1. 公钥public_keyA相当于一个只能由私钥private_keyA打开的锁，而私钥private_keyA相当于一把只能打开由公钥public_keyA锁上(加密)的数据的钥匙，即公钥public_keyA与私钥private_keyA相当于配套的一对锁和钥匙。
   2. 在主机A中生成公钥public_keyA和私钥private_keyA后，主机A只向外界告知生成的公钥public_keyA，而私钥private_keyA则保存在主机A内存中，属于隐私信息，即主机A告诉外界：“想要和我说悄悄话，就把悄悄话用只有我能解开的锁子锁上并发送给我。”
   3. 主机B若想和主机A进行安全数据通信，则主机B只需在得到主机A的公钥public_keyA后，使用公钥public_keyA加密将要传输给主机A的数据，这相当于给将要传输到主机A的数据加上了一个只能由主机A的私钥private_keyA打开的锁。因此，如果没有私钥private_keyA，则使用公钥public_keyA加密后的数据将不可被截获该数据包的设备解密。
   4. 由于私钥private_keyA仅保存在主机A内存中且未向外界传输，因此解决了对称加密中由于密钥在不可靠信道中传输从而隐含对称密钥被截获后产生的数据加密不安全问题。
4. 综上所述，两个计算机A、B想要进行安全数据通信，只需在将要发送给对方的数据上加一个只能由对方私有的钥匙打开的锁。锁，即public_key；钥匙，即private_key。
5. 疑问：公钥只能用于加密，而私钥只能用于解密吗？
   1. 公钥和私钥都可用于加密和解密，即公钥加密的信息可由私钥解密，私钥加密的信息同样可以用公钥解密。不同场景使用不同的密钥来加/解密，规则如下：
      1. 私钥用于数字签名、公钥用于验签
         1. 数字签名和加密作用不同，数字签名并不是为了保密，是为了保证这个数字签名是由特定的某个人签名的，而不是被其它人伪造的数字签名，所以私钥的私有性就适合用在数字签名用途上。
         2. 使用私钥对数据进行数字签名后，只能由对应的公钥解密，由于公钥是公开的（很多人可持有），所以拥有公钥的用户在使用公钥解密数字签名后，即可判断出该数字签名的唯一制作者，因此验证了身份合法性。
      2. 公钥用于加密、私钥用于解密，这才能起到加密作用
         1. 因为公钥是公开的，所以很多人可以持有公钥。若用私钥加密，那么所有持有公钥的人都可以进行解密，这对于隐私数据传输来说是不安全的！
         2. 若用公钥加密，则只能由私钥解密，而由于私钥是私有不公开的，只能由特定的私钥持有人解密，因此可保证数据的安全性。
6. 非对称加密的缺点
   1. 使用非对称加密解密的运算过程耗费时间较长，因此实际数据传输应用中，通常使用“非对称加密+对称加密原理【会话密钥】”模式。

2.3 非对称加密+对称加密【会话密钥】原理

1. 首先说明，在【非对称加密+对称加密【会话密钥】方法中，使用会话密钥用于双方通信数据加密，而客户端和服务器端生成的公/私密钥仅用于生成会话密钥和通信双方的身份认证。
2. 客户端和服务器端分别生成各自的公/私钥；
3. 客户端向服务器端发起SSH连接请求后，通信双方互相交换公钥并基于密钥交换算法(如ECDH算法)生成会话密钥(对称密钥)，完成建立安全数据通道工作，在此过程中同时完成客户端对服务器端的身份认证(身份认证过程将在第三节详解)。会话密钥的简易生成过程举例如下：
   1. Alice 生成一对公/私钥：
   2. Bob 生成一对公/私钥：
   3. Alice 和 Bob 通过不可靠信道（比如互联网）交换各自的公钥
   4. Alice 计算共享密钥(会话密钥)： sharedKey = bobPubKey * alicePrivKey
   5. Bob 计算共享密钥(会话密钥)：sharedKey = alicePubKey * bobPrivKey
   6. Alice 和 Bob 即拥有相同的共享密钥 sharedKey == bobPubKey * alicePrivKey == alicePubKey * bobPrivKey
   7. 后续的传输数据均使用会话密钥sharedKey加密。
4. 若服务器端要求客户端使用【用户密码】方式登录服务器端，则客户端使用会话密钥将【用户密码】加密后发送给服务器端。
5. 服务器端使用会话密钥解密客户端发来的数据后提取到【用户密码】，随后服务器端使用获取到的【用户名+密码信息】确定客户端登录信息是否正确。若信息正确，反馈登录状态并建立连接，反之，反馈信息错误。
6. 建立连接后，客户端和服务器端数据通信采取对称加密方式，用于加密的密钥为会话密钥。
7. 综上所述，可以明显得出“在非对称加密+对称加密【会话密钥】”方法中，会话密钥用于数据加密，而客户端或服务器端生成的公/私密钥仅用于生成会话密钥和相互认证(如数字签名)”这一结论。
8. 使用“非对称加密+对称加密【会话密钥】”解决了如下问题
9. 对称加密中由于密钥在不可靠信道中传输从而隐含对称密钥被截获后产生的数据加密不安全问题。
10. 非对称加密通信时，数据加密和解密运算量过大的问题。
11. 当前实际网络中，常常采用“非对称加密+对称加密【会话密钥】”的方式进行SSH连接与数据通信。

三、SSH的工作原理详解

1. SSH协议运行在TCP协议之上，因此SSH客户端和服务器端首先需建立TCP链接；
2. 其次，SSH客户端和服务器端协商双方使用的SSH协议版本号及支持的算法；
   1. 协议版本协商
      1. 当前SSH协议有SSH1.X和SSH2.0版本，因此SSH客户端和服务器需先确保双方使用同一版本SSH协议
   2. 算法协商
      1. SSH协议工作时的算法包括：用于产生会话密钥的密钥交换算法、用于数据信息加密的对称加密算法、用于进行数字签名和认证的公钥算法及用于数据完整性保护的HMAC算法。
      2. SSH客户端和服务器互相向对方发送自己支持的算法，双方依次协商每种算法类型中具体使用的算法，最终匹配出双方均支持的算法用于SSH协议运行；若每类算法均匹配成功，则完成算法协商工作；若某类算法匹配失败，则会导致SSH客户端和服务器之间断开连接。
3. 紧接着通信双方运行密钥交换算法并完成客户端对服务器端的身份认证：SSH客户端向服务器端发送客户端公钥，服务器端生成会话密钥后，向客户端发送服务器端公钥及数字签名，客户端接受服务器端公钥后生成与服务器端相同的会话密钥并完成客户端对服务器端的身份认证。
   1. SSH服务器和客户端通过密钥交换算法(称为密钥协商算法或许更合适)，动态生成共享的会话密钥和会话ID，建立加密通道。
   2. 会话密钥主要用于后续数据传输的加密，会话ID用于在认证过程中标识该SSH连接。
   3. 会话密钥的生成过程举例可见如下链接：知乎：ECDH 密钥交换 概念+例程 - 写给开发者的实用密码学（电子书翻译）
   4. 在运行密钥交换算法期间，客户端完成对服务器端的身份认证
      1. 服务器端使用服务器私钥将【服务器端公钥信息+附加信息】进行数字签名，随后将【服务器端公钥信息+附加信息+数字签名】数据包并发送给客户端。
      2. 客户端接受到服务器端发来的数据后得到【服务器端公钥信息+附加信息+数字签名】，客户端再使用得到的服务器公钥验证数字签名，从而完成客户端对服务器的身份认证，同时利用服务器端公钥信息可完成共享密钥(会话密钥)的计算。
      3. 注意：服务器端主机作为服务器在SSH连接中自动产生的公/私密钥对存储在“/etc/ssh/”目录下，当该目录下产生一次公/私密钥后，无论哪个客户端后续与该服务器建立SSH连接，服务器端均使用存储在“/etc/ssh/”目录下的同一个公/私密钥用于和客户端进行身份认证及计算共享密钥，即自动生成的公/私密钥存有缓存文件
4. 接下来，服务器端选择对“申请使用SSH协议登录服务器端的客户端用户”的认证方式
   1. 通信双方均生成共享密钥且客户端完成对服务器端的身份认证后，服务器端检索.ssh/目录下的authorized_keys文件。
      1. 若authorized_keys文件中含有“申请使用SSH协议登录服务器端的客户端用户”的公钥信息，则服务器端选择服务器端认证客户端方式为【免密登录】
      2. 若authorized_keys文件中没有“申请使用SSH协议登录服务器端的客户端用户”的公钥信息，则服务器端选择服务器端认证客户端方式为【用户密码登录】
   2. 用户密码（password）认证
      1. 服务器端向客户端发送“输入登录密码”信息
      2. 客户端将使用会话密钥加密后的【登录密码】数据发送给服务器，服务器使用会话密钥解密后得到【登录密码】，并与本地保存的用户名和密码进行对比，最后向客户端返回认证成功或失败的消息。
      3. 密码认证的基本原理是SSH客户端使用会话密钥对【登录密码】进行加密，SSH服务器使用相同的会话密钥解密后验证【登录密码】的合法性；
   3. 密钥（publickey）认证(免密登录)
      1. SSH 密钥认证登录分为以下的步骤。
      2. 预备步骤，主机当前登录用户通过ssh-keygen手动生成当前主机登录用户私有的公钥和私钥（如id_rsa和id_rsa.pub）；
         1. 主机不作为客户端/服务器建立SSH连接时：使用ssh-keygen命令手动生成的公/私密钥对存储在当前登录用户的“/home/【用户名】/.ssh/”目录下，也就是说，不同登录用户使用ssh-keygen命令生成的公/私密钥只能唯一标识该登录用户。
         2. 主机作为服务器/客户端建立SSH连接时：在建立连接的过程中由主机自动生成的公/私密钥对存储在root的“/etc/ssh/”目录下（这里默认主机均为Linux系统），因此该公/私密钥不能唯一标识当前主机登录用户，该公/私密钥只能唯一标识当前ssh/sshd主机。
         3. 总结：通过上述两种方式生成的公/私密钥对的值是不相同的，即“/home/【用户名】/.ssh/”目录下的公/私密钥属于当前主机上的登录用户，“/etc/ssh/”目录下的公/私密钥属于当前ssh/sshd主机。
            
      3. 第一步：手动将“欲作为客户端进行SSH免密登录的”主机当前登录用户的公钥放入远程服务器的.ssh/authorized_keys文件中；
      4. 第二步：主机作为客户端，向服务器发起 SSH 登录的请求。客户端和服务器端生成会话密钥，建立安全数据通道并完成客户端对服务器端的身份认证。
      5. 第三步：服务器查询authorized_keys文件(sshd配置文件规定查找公钥的目录为“.ssh/authorized_keys”)，发现存有客户端公钥信息，服务器端因此生成一些随机数据，接着使用服务器端私钥生成该数据的数字签名，随后使用存储在authorized_keys文件中的客户端公钥对【随机数据+服务器端数字签名】数据包进行加密，再使用会话密钥加密该数据并发送给客户端当前登录用户。
      6. 第四步：客户端收到服务器发来的数据，先使用会话密钥解密传输来的数据包，得到 “服务器使用存储在authorized_keys文件中的客户端公钥加密【随机数据+服务器端数字签名】后产生的数据” ，接着使用存储在“/home/【用户名】/.ssh/”目录下的客户端当前登录用户的私钥(如.ssh/id_rsa)对 “服务器使用存储在authorized_keys文件中的客户端公钥加密【随机数据+服务器端数字签名】后产生的数据”进行解密取得随机数据和服务器端数字签名，在此期间，客户端可使用服务器端公钥解密服务器端数字签名，以确保从服务器端发来的加密数据包确实来源于服务器端且加密数据包在传输过程中没有被修改。
         1. 文章中为什么着重强调 “服务器使用存储在authorized_keys文件中的客户端公钥加密【随机数据+服务器端数字签名】后产生的数据”这个概念呢？
         2. 我们知道，在密钥交换算法运行过程中，客户端和服务器端互相交换了各自存储在“/etc/ssh/”目录下的公钥信息用于计算共享密钥(会话密钥)，然而，服务器端计算出共享密钥后并不保存客户端发送来的存储在客户端“/etc/ssh/”目录下的的公钥信息，而客户端计算出共享密钥后保存“服务器端存储在服务器“/etc/ssh/”目录下的公钥信息”。
         3. 原因：
            1. 客户端保存服务器端公钥信息的目的：1、对后续“从服务器端发来的数据的数字签名”进行认证，从而确保服务器端的真实性及客户端接收到的数据完整性；2、下一次重新与该服务器端建立连接时，无需对该服务器端公钥真实性产生怀疑，这就是为什么客户端保存服务器端公钥的文件名为known_hosts；
            2. 服务器端无需保存“客户端存储在“/etc/ssh/”目录下的公钥信息”的原因：1、服务器端作为被登录方，只需验证“请求和自己连接的客户端”所提交的登录密码信息是否正确即可，服务器端不关心请求登录的客户端的真实身份，登录密码正确：建立连接；登录密码错误：重新输入或断开连接。
         4. 因此，当我们手动将能够唯一标识客户端当前登录用户的独有公钥放入远程服务器的.ssh/authorized_keys文件中后，相当于授权拥有该公钥对应私钥的客户端登录账户能够无需密码便可登录服务器。而服务器端若想验证当前客户端登陆账户是否为“.ssh/authorized_keys”目录下授权的账户，只需拿“.ssh/authorized_keys”目录下的公钥加密一段信息并发送给客户端当前账户，如果客户端能利用客户端当前登录的账户私钥解码，则服务器端认为授权认证文件生效，因此同意该客户端账户免密登录服务器。
      7. 第五步：客户端接着使用会话密钥将解密后的随机数据进行加密并发送给服务器端。
      8. 第六步：服务器收到客户端发来的加密数据后，使用会话密钥解密，然后跟原始生成的随机数据比较。如果一致，则服务器端认为authorized_keys文件中的对应条目有效，因此允许该客户端用户免密登录。
5. 完成用户认证后，SSH客户端和服务器端即可建立会话进行数据交互，双方发送的数据均使用会话密钥进行加解密（对称加密）。

四、常用SSH连接工具及使用方法

1. OpenSSH
   1. 在/etc/ssh/sshd_conf中可以通过设置以下两项来禁用root登录及密码登录（使用“#”注释掉即为禁用）
      1. PermitRootLogin yes
      2. PasswordAuthentication yes
   2. 使用命令使ssh服务器配置生效service sshd restart
2. PuTTY

五、SSH连接实例【实例演示中均会使用wireshark配合抓包分析】

5.1 使用windows主机连接CentOS虚拟机

5.1.1 CentOS 设置

1. 在CentOS 7上启用SSH服务器
   1. 启动 SSH 服务器：sudo systemctl start sshd
      1. 如果本机没有SSH服务器端，可使用sudo apt-get install openssh-server命令安装。
      2. 如果启动时报错Failed to start sshd.service Unit sshd.service not found.
         1. 解决方法：使用命令systemctl enable ssh.service：添加系统服务ssh.service
   2. 设置 SSH 服务开机自启：sudo systemctl enable sshd
   3. 检查 SSH 服务状态：sudo systemctl status sshd
      
2. 获取CentOS 7的IP地址
   1. 在本实验中，CentOS 7网络设置为Only-host模式，手动配置IP。
      

5.1.2 从 Windows 使用 SSH 客户端连接 CentOS 服务器（账号密码登录）

1. 输入命令以连接到 CentOS 服务器：ssh [目的连接用户名]@[服务器IP地址]
2. 打开wireShark，第一阶段抓包
   
3. 第一阶段抓包分析：输入ssh [目的连接用户名]@[服务器IP地址]并Enter后的抓包分析
   1. 1~3号包：通过SYN、ACK标志及seq序号信息可以看出建立SSH连接前需建立两个主机的TCP连接；
   2. 4号包：由Src、Dest及info标签页可知，客户端向服务器端发送客户端运行的SSH版本信息，该数据包Len=33；
   3. 5号包：由ACK标志及Ack=34知，服务器端对4号包做了接收确认。
   4. 6号包：由Src、Dest及info标签页可知，服务器端向客户端发送服务器端运行的SSH版本信息，该数据包Len=21；
   5. 7~8号包：由Src、Dest及info标签页可知，客户端和服务器端互相发送自己支持的密钥相关算法信息(客户端在发送支持信息时也会同时猜测服务器支持哪些算法，见各server_to_client字段)，如：用于产生会话密钥的密钥交换算法、用于数据信息加密的对称加密算法等，经过双方协商后即可确定密钥相关算法类型。算法协商规则：在客户端支持的算法列表中，第一个被服务器支持的算法确定为双方协商的算法。
      1. First KEX Pcaket Follow：表示是否要先在服务器提供它的列表并得出协商结果前直接尝试一次客户端自己猜测的交换算法，如果设为 1 ，客户端会在收到消息之前就发出初始化交换算法的请求，如果猜错了服务端会直接无视；
      2. 一个随机数cookie：它将被用来生成session_id，它能唯一确定当前的连接，同时确保双方中的任意一方没有完全的能力控制其初始化的结果；
      3. hassh和hasshServer： 一种新型网络指纹识别标准，可用于识别特定的客户端和服务器SSH，“hassh”和“hasshServer”采用了通过特定算法集设计的MD5哈希结构，目前很多的SSH客户端以及服务器端应用程序都支持这样的架构。
         
   6. 9号包：客户端向服务器端发送公钥（等待服务器端发来服务器端公钥后，客户端使用ECDH算法生成共享密钥）
      1. ECDH ( Elliptic Curve Diffie-Hellman Key Exchange ) 是一种匿名密钥协商方案 。其能让通信的双方在不安全的信道中协商出来一个共享密钥 (shared secret)，即会话密钥 。
         
   7. 10号包：服务器端使用ECDH密钥算法生成会话密钥，接着服务器端使用私钥生成一份数字签名，随后将【服务器端公钥+服务器端数字签名】发送给客户端。
      
4. 当首次连接到服务器时，系统会询问是否接受服务器的公钥，键入 yes 然后按Enter键
   1. SSH服务器的公钥fingerprint指纹指SSH服务器公钥的哈希值（唯一），所谓"公钥指纹"，是指公钥长度较长（这里采用RSA算法，长达1024位），很难比对，所以对其进行MD5(哈希算法)计算，将它变成一个128位的指纹。
   2. 这里产生一个问题：客户端如何确定服务器端公钥的真实性(即该公钥确实来自于服务器端)呢？
      1. 办法一：服务器端必须在自己的网站上贴出公钥指纹，以便用户自行核对。假定经过风险衡量以后，客户端决定接受这个远程主机的公钥，即输入yes并Enter确认。
      2. 办法二：服务器向客户端发送自己的CA证书(即由第三方可信机构颁发的“认定服务器端公钥是该服务器端公钥”的证书)。
   3. 当服务器端的公钥被接受以后，该公钥就会被保存在主机文件“./.ssh/known_hosts”之中。下次再连接这台服务器时，系统就会认出该服务器的公钥已经保存在本地了，从而跳过警告部分。
   4. 每个SSH客户端用户都有属于自己名下的known_hosts文件，此外ssh系统也有一个这样的文件，通常是/etc/ssh/ssh_known_hosts，保存一些对所有客户端主机用户都可信赖的远程服务器的公钥。
   5. 上文提到，首次进行SSH连接时，客户端需确定服务器端公钥的真实性(即该公钥确实来自于服务器端)。如果在对服务器公钥指纹的确认环节中我们没有核对公钥指纹的正确性，同时也没有CA证书机制，那么就存在一个风险：如果有黑客截获了客户端的登录请求并冒充远程服务器端主机，将伪造的公钥发给客户端，那么客户端就接受了伪造的服务器端公钥。如果攻击者插在客户端与远程服务器端之间（比如在公共的wifi区域），用伪造的公钥，获取客户端的登录密码。再用这个密码登录远程服务器端，那么SSH的安全机制就荡然无存了。这种风险就是著名的"中间人攻击"（Man-in-the-middle attack）
      1. CA证书机制可有效降低"中间人攻击"风险。
5. 第二阶段抓包
   
6. 第二阶段抓包分析：键入 yes 后按Enter键的抓包分析
   1. 12号包：客户端接收到服务器端公钥并使用ECDH算法生成共享密钥(会话密钥)。至此，客户端和服务器端建立安全通信连接，同时客户端完成验证服务器公钥的真实性。以后的数据传输都会使用基于会话密钥的aes128-ctr算法进行加解密操作。并基于[email protected]算法计算MAC值(注意，这里的“MAC”指“Message Authentication Code报文鉴别码”而不是不是链路层的“介质访问控制”)。
   2. 注意：windows主机接收到的来自服务器端的公钥将被存储到C:\Users\【当前登录用户名】\.ssh目录下。
7. 输入想要登录的CentOS用户的密码并按Enter
8. 第三阶段抓包
   
9. 第二阶段抓包分析：输入想要登录的CentOS用户的密码并按Enter后的抓包分析
10. 20~36号包：数据均被加密，理论分析过程可见 “三、SSH的工作原理摘要”。
11. 每次都要输入用户名和密码，能否实现免密码登录呢？请见5.1.3进一步探索

5.1.3 从 Windows 使用 SSH 客户端连接 CentOS 服务器（免密登录）

1. 原理概述
   1. 请见 “三、SSH的工作原理摘要”
2. 首先我们在windows命令行中运行命令ssh-keygen -t rsa，其中参数“-t”指明生成密钥算法。
   1. “SSH服务器的密钥fingerprint指纹”指SSH服务器公钥的哈希值(唯一)，所谓"公钥指纹"，是指公钥长度较长（这里采用RSA算法，长达1024位）很难比对，所以对其进行MD5(哈希算法)计算，将它变成一个128位的指纹。
   2. 在这里我们指明使用RSA算法生成windows客户端当前登录用户的密钥；
   3. 密钥对存储路径为C:\Users\[当前登录用户名]\.ssh；
   4. 运行后查看.ssh目录，，id_rsa是私钥文件，id_rsa.pub是公钥文件，这两个文件均在“C:\Users[当前登录用户名].ssh”目录下；
3. 我们使用命令行完成windows客户端当前登录用户公钥文件从windows到CentOS的传输
   1. 使用scp命令进行windows到CentOS的公钥文件复制：scp C:\Users\asus\.ssh\id_rsa.pub [目的用户名]@[IP地址]:[目的主机的目的复制地址]，如scp C:\Users\asus\.ssh\id_rsa.pub [email protected]:/home/yuxinghai/.ssh/，回车后输入密码即可完成复制。
   2. 我们也可以使用WinSCP工具分别将客户端和服务器端的公钥文件复制到对方.ssh/目录中。WinSCP工具的使用方法可自行搜索，相信经过了上述过程的思考和学习，使用WinSCP一定会很简单。
4. 在CentOS的.ssh/文件中，我们使用“cp”命令，将id_rsa文件复制并将副本改名为authorized_keys：cp id_rsa.pub authorized_keys
   1. Linux中，设置该文件权限为“仅文件拥有者拥有读写权限”，对应命令为chmod 600 [authorized_keys文件路径]，其中，600指代Linux权限“-rw --- ---”。
5. 检查并确认无误后，在windows命令行中使用命令ssh [CentOS用户名]@[IP地址]测试免密登录。
6. 成功实现免密登录。
   

5.1.4 【authorized_keys】、【known_hosts】、【id_rsa】、【id_rsa.pub】文件的区别

1. authorized_keys：SSH服务器授权的可免密登录的客户端主机用户独有的公钥信息。
2. known_hosts：该文件用来记录主机当前账户作为客户端连接过的远程服务器公钥信息。每连接一个新的远程服务器，known_hosts文件都会被追加产生一条新的数据记录，包括远程机器ip、远程机器公钥。
3. id_rsa与id_rsa.pub：主机当前登录用户使用ssh-keygen -t rsa命令后“在/home/【用户名】/.ssh/文件夹下”生成的独属于该用户的公/私密钥。详情请见 “三、SSH的工作原理摘要”

六、后记

6.1 致谢

感谢 @鹭雨 对我的冗杂问题的耐心解答，正是因为你的帮助，才使我能够及时走出困惑，得以继续前行。

6.2 更新

1. 本文章的深度及广度将持续拓展更新。
2. 如有读者发现文章的错误之处，非常欢迎您在评论区或私信的批评，我将及时修正内容。

参考资料

1. Info-Finder：什么是SSH？
2. CSDN：ssh详解–让你彻底学会ssh
3. 网道：SSH 密钥登录
4. ssh使用的RSA，DSA和ECDSA密钥之间有什么区别？
5. linux公钥在机器哪里（详解ssh密钥的存放位置）
6. CSDM：SSH协议中的对称加密和非对称加密
7. CSDN：Windows系统下：SSH 远程连接 Linux 服务器的完整指南
8. 博客园：rsa公钥和私钥到底哪个才是用来加密，哪个用来解密？
9. CSDN：通过ssh协议实现Windows与Linux之间的文件互传
10. CSDN：PKI - SSH建立安全信道的过程
11. 知乎：重新认识SSH（一）
12. 知乎：ECDH 密钥交换 概念+例程 - 写给开发者的实用密码学（电子书翻译）
13. [计算机网络：自顶向下方法 第8版]