深入理解ssh的安全机制

怎样理解ssh第一次连接为什么不是可靠连接，后续的通讯又是可靠的？

下图为ssh连接时公私钥交换过程：

ssh第一次连接的时候，ssh server端返回的是公钥，而不是数字证书，因此我们有可能连接到某台伪装成server的主机。
一般连接的时候会有如下提示：
The authenticity of host ‘10.35.82.21 (10.35.82.21)’ can’t be established.
ECDSA key fingerprint is SHA256:wyVXy2BJPTSJdtq6r4nIeZRt76YwrEFqjpM7JHuSJY4.
Are you sure you want to continue connecting (yes/no)?
这是让你确认目标主机的指纹（指纹=hash_func(server的公钥)）是否为wyVXy2BJPTSJdtq6r4nIeZRt76YwrEFqjpM7JHuSJY4，指纹一般网站会有公布。因此在敲下yes的前应当将该指纹和网站公布的指纹作对比，谨慎地确认。

在公司局域网内，一般不可能存在中间人攻击，因此可以忽略这个，直接确认即可,或者通过修改ssh客户端配置文件，让其默认同意通过第一次连接时的指纹验证，目的在于有利于自动化脚本运行。
]# vim /etc/ssh/ssh_config #ssh客户端配置
StrictHostKeyChecking ask ------> StrictHostKeyChecking no
ps:
如果没有做配置，在脚本中可以使用ssh -o StrictHostKeyChecking=no ${remote_host} [command]

为什么不用数字证书来确保公钥的真实性：每台机器因为连接问题都申请数字证书，这不现实。

ssh在第一次连接成功以后，客户端服务器和服务端服务器都会拥有双方的公钥，存放在/etc/ssh/hosts_kowns文件中，因为通讯是基于非对称加密的,所以通讯是可靠的。

ssh基于用户口令登陆和基于密钥登陆原理示意图：

基于密钥登陆配置，使用ssh-copy-id自动生成 authorized_keys 文件：
ssh-copy-id -i ~/.ssh/id_rsa.pub user@ip
user@ip’s password:

实验1： 多台机器（集群环境）彼此key验证，假设有4台机器，ip地址如下10.35.78.25,10.35.78.26,10.35.78.27,10.35.78.28

思路：，四台机器可以看做在地位上是等同的，因此使用同一套公私钥
10.35.78.25：
]# ssh-keygen
]# ssh-copy-id -i ~/.ssh/id_rsa.pub 10.35.78.25
]# scp -pr ~/.ssh/* 10.35.78.26:~/.ssh/
]# scp -pr ~/.ssh/* 10.35.78.27:~/.ssh/
]# scp -pr ~/.ssh/* 10.35.78.28:~/.ssh/

实验2： 现在登录在10.35.78.25上，将10.35.78.26/tmp/test 拷贝到10.35.78.29的/main/soft 下

]# scp 10.35.78.26:/tmp/test 10.35.78.29:/main/soft/

实验3: 使用rsync实现增量复制（只复制修改的文件）

链接

实验4: 在xshell上实现免密登陆服务器

在xshell中点击工具---->用户密钥管理者，生成windows用户的公私钥，将生成的公钥复制到服务器对应用户的 ~/.ssh/authorized_keys文件中即可。
注意：
1.就算服务器密码改变，人员照样可以通过密钥验证的方式登录服务器，因此存在安全隐患。
2.如若私钥丢了，就有人可以伪装成私钥真正的所属人进行登录。

实验5:实现ssh端口转发

链接地址