SSH－原理
社内研修，重新整理了一下SSH的原理
（如果有不正确的地方，请留言指出，以后完善。）
基础
概念
SSH 是 Secure Shell 的缩写，提供了安全性的远程访问别的机器的机制。
目的
相比Telnet和Ftp实现，安全的数据传输
如何实现安全
加密的两种方式，对称加密 和 非对称加密
对称加密；方法使用同一个密钥，一旦泄露，所有的安全均不可靠
非对称加密；使用公钥和私钥的两个密钥，只能使用私钥解密
一般用非对称加密的方式实现最初的会话连接，之后再用对称加密传输数据，所以会感觉，ssh连接的时候比较慢，而传输数据会比较快一些。
非对称加密的原理；
- 远程服务端接受客户端连接请求，服务端将自己的公钥发给客户端
- 客户端使用该公钥加密自己的密码，并将码文发给服务器
- 服务器用私钥解密码文，并验证其合法性，将结果回送给客户端
上面的连接有一个最大的问题，就是第一步的客户端接收公钥，怎么能确认是目标服务器发送过来的呢，如果中间被拦截，第三方给我的公钥，之后的数据发送都将处于危险之中。
处理方式
解决上面的问题，不同的协议有不同的解决方式，目的就是验证服务器给的公钥合不合法？
HTTPS
该协议方式是采用 CA 认证的方式，别文整理。
SSH
在该协议中，由于公钥和私钥都是自己生成的，所以没办法进行第三方的公证。
-
方式一；基于口令的认证
第一次连接服务器时，通常会有类似下面的信息The authenticity of host ‘127.0.0.1 (127.0.0.1)’ can’t be established.
ECDSA key fingerprint is SHA256:t2817qI47Br/fqAMFVBYt20TZMPKcu8Rj/+U+O12345.
ECDSA key fingerprint is MD5:3b:d5:0d:df:16:6c:15:f0:3f:e2:ed:44:f2:22:22:22.
Are you sure you want to continue connecting (yes/no)?意思时，这是第一次连接该服务器，无法确认真实性，已经拿到了服务器的指纹（由于公钥太长，通常1024位，基本采用通过公钥生成hash值，传递hash的方式），要连接吗?
选择 yes 后，认为已识别了该服务器，并追加到 known_hosts 文件中，然后输入密码，用得到的公钥加密密码，传给服务器端。 -
方式二；基于公钥认证
由于每次都要输入密码进行验证，比较麻烦，可以采用一种方便的做法，免去每次都要输入密码，下面详细说明。
原理
使用key交换的方式，保证安全性。
交换原理图；
左侧-客户端
右侧-服务器
通过SSH命令访问服务器的时候，到底发生了什么，是怎么样连接上服务器的呢？
前提
要让服务器端允许客户端来连接，双方必须事先约定一个公开键一个私有键，
键的生成方式，可以选择客户端生成（客户端做成公开键，传给服务器），也可以选择服务器端生成（ec2等的连接方式，服务器端生成键，秘密键传给客户端）。
-
客户端生成private key 和 public key
ssh-keygen -t rsa -f [文件名]
-t 指定暗号化方式，采用rsa
-f 指定生成的文件名，默认是 id_isa
-N “” 指定无密码，不然设置密码后每次都要输密码此时同时生成两个文件 id_isa （秘密键）和 id_isa.pub （公开键）
-
将生成的公开键传给服务器
scp [文件名].pub [host名]:/home/[用户目录]
-
服务器端将公钥保存到文件 ~/.ssh/authorized_keys 中
这样客户端的准备工作都已经完成，AWS是生成秘密键之后，通过下载的方式把秘密键保存在客户端，AWS做好了ec2-user和公开键的匹配
流程
- 客户端通过命令访问服务器
ssh [用户名]@[服务器名]
- 服务器接到请求后，先在 authorized_keys 中匹配客户端的公钥pubKey，生成一个随机数R，然后用客户端的公钥加密随机数作成暗号pubKey®，传给客户端
- 客户端用私钥解密得到随机数R，然后利用MD5生成随机数R和会话sessionId的摘要，发送给服务器
- 服务器端采用同样的MD5方式对随机数R和sessionId生成摘要，验证客户端传来的摘要和自己生成的摘要是否一致，实现验证
最简便的连接
如何简化每次都要在命令中指定名用户和密码连接，直接输入服务器名连接
修改文件
~/.ssh/config
Host [host名，用户名等]
HostName [host名]
User [用户名]
IdentityFile ~/.ssh/[privateKey文件名]
ssh [host名，用户名等]