ssh服务认证类型主要有两个:
基于口令的安全验证:
基于口令的安全验证的方式就是大家一直在用的,只要知道服务器的ssh连接账户、口令、IP及开发的端口,默认22,就可以通过ssh客户端登陆到这台远程主机上。此时,联机过程中所传输的数据都是加密的。
基于密钥的安全验证:
基于密钥的安全验证方式是指,需要依靠密钥,也就是必须事先建立一对密钥对,然后把公钥放在需要访问的目标服务器上,另外,还需要把私钥放到ssh的客户端或对应的客户端服务器上。
此时,如果想要连接到这个带有公钥的ssh服务器,客户端ssh软件或客户端服务器就会向ssh服务器发出请求,请求用联机的用户密钥进行安全验证。ssh服务器收到请求后,会先在ssh服务器上连接的用户家目录下寻找放上去的对应用户的公钥,然后把它和连接的ssh客户端发送过来的公钥进行比较,如果两个密钥一致,ssh服务器就用密钥加密“质询”并把它发给ssh客户端。ssh客户端收到“质询”之后就可以用自己的私钥解密,再把它发给ssh服务器。使用这种方式,需要知道联机用户的密钥文件,与地中基于口令验证的方式相比,第二种方式不需要再网络上传送口令密码,所有安全性更高了,这时我们也要注意保护我们的密钥文件,特别是私钥文件,一旦被黑客获取了,危险就很大了。
案例:批量分发管理(一把钥匙开多把锁)
测试场景:
主机名:nfs-server 网卡eth0:192.168.43.117 用途:中心分发服务器
主机名:lamp01 网卡eth0:192.168.43.118 用途: 接收客户端服务器
主机名:lamp02 网卡eth0:192.168.43.119 用途: 接收客户端服务器
主机名:backup 网卡eth0:192.168.43.200 用途: 接收客户端服务器
=================================================================
首先需要更改局域网机器的主机名与IP地址都要对应到hosts文件里去,方便访问解析快。
![](https://i-blog.csdnimg.cn/blog_migrate/4810460f30c054a57cd76eba6e50e7df.png)
通过scp命令发向其他机器上。
scp -r /etc/hosts root@192.168.43.200: /etc
创建一个分发管理用户
![](https://i-blog.csdnimg.cn/blog_migrate/b7e27470c3cb8acbfb3f53620f041478.png)
创建一个密钥对:(分发机器上创建,切换到分发用户下创建一对密钥)
rsa与dsa密钥类型的区别:
rsa即可以进行加密,也可以进行数字签名实现认证,而dsa只能用于数字签名从而实现认证。
su – bqh01
ssh-keygen –t dsa
ssh-keygen是生产密钥的工具,-t参数指建立密钥的类型,这是是建立dsa类型密钥,也可以建立rsa类型密钥。
![](https://i-blog.csdnimg.cn/blog_migrate/82e3c5a30e71bbafdd8b5e77b53ae331.png)
也可以用此命令直接生成一对密钥:ssh-keygen -t dsa -P "" -f ~/.ssh/id_dsa
此时我们需要把产生的公钥(锁)发给局域网中的各个机器上:
ssh-copy-id -i .ssh/id_dsa.pub bqh01@192.168.43.118
ssh-copy-id -i .ssh/id_dsa.pub bqh01@192.168.43.119
ssh-copy-id -i .ssh/id_dsa.pub bqh01@192.168.43.200
![](https://i-blog.csdnimg.cn/blog_migrate/3674858fd065e5027253c1e7a9ec606e.png)
如果ssh修改了特殊端口,如8886,那么用上面的ssh-copy-id命令就无法进行分发公钥了,如果仍要用ssh-copy-id的话,可以用:
ssh-copy-id –I id_dsa.pub “-p 8886 bqh01@192.168.43.118” //特殊端口分发,要适当加引号。
我们可以上118服务器上查看是否分发过来了:
![](https://i-blog.csdnimg.cn/blog_migrate/06bef2118fed28ba04c614a677983e7c.png)
ok。
此时我们就可以批量管理各个机器了:
例如查看各个机器上的ip地址:可以写一个简单脚本
vi fenfa.sh
ssh -p22 bqh01@192.168.43.118 /sbin/ifconfig eth0
ssh -p22 bqh01@192.168.43.119 /sbin/ifconfig eth0
ssh -p22 bqh01@192.168.43.200 /sbin/ifconfig eth0
简单脚本:
#!/bin/sh
for n in 118 119 200
do
ssh –p22 bqh01@192.168.43.$n /sbin/ifconfig eth0
done
![](https://i-blog.csdnimg.cn/blog_migrate/5313718b2fd92c2334e507b9b88a11e2.png)
ok。
接下来我们分发一个文件:先要把分发的文件拷贝到普通用户家目录下
vi fenfa.sh
scp -P22 hosts bqh01@192.168.43.118:~
scp -P22 hosts bqh01@192.168.43.119:~
scp -P22 hosts bqh01@192.168.43.200:~
简单脚本:
#!/bin/sh
for n in 118 119 200
do
scp –P22 hosts bqh01@192.168.43.$n:~
done
![](https://i-blog.csdnimg.cn/blog_migrate/96939ed5db9797a31e076fa7b4f54266.png)
我们从其他机器上查看是否分发过去了:
![](https://i-blog.csdnimg.cn/blog_migrate/64ca32a74efb8a266a54e9fa58594785.png)
ok。
当我们批量分发到远程机器的其他目录下会出现以下错误提示:
![](https://i-blog.csdnimg.cn/blog_migrate/70ba112c84235b9414defc2dde4affc4.png)
错误:原因是bqh01没有/etc下的权限。批量分发时需要注意权限问题。
我们可以通过以下方法来解决:
1、 利用root做ssh key验证
2、 利用普通用户如bqh01sudo提权来做
3、设置suid对固定命令授权
例如:利用普通用户如bqh01来做,sudo提权拷贝分发的文件发到远程对应权限的目录下
把普通用户加入到sudoers里去,并授予rsync权限(注意:在所有机器上操作)
echo ‘bqh01 ALL=(ALL) NOPASSWD:/usr/bin/rsync’ >>/etc/sudoers
visudo -c
![](https://i-blog.csdnimg.cn/blog_migrate/5b492531d7c509c2774e9bd5c9179c89.png)
我们切换到普通用户下推送一下hosts到/etc/ceshi下试试看:
![](https://i-blog.csdnimg.cn/blog_migrate/2e8569b86eaa1e356510472d22334b3b.png)
出现Connection to 192.168.43.118 closed.这种提示表表示执行成功
我们再从其他机器上查看是否推送过来了:
![](https://i-blog.csdnimg.cn/blog_migrate/367a910aa5577623f71fd0c5587a86c4.png)
ok。
可以写一个分发脚本:
![](https://i-blog.csdnimg.cn/blog_migrate/b79bb243c0ebb0cb4a2ab7419728de5f.png)
脚本优化:
#!/bin/sh
. /etc/init.d/functions
if [ $# -ne 2 ]
then
echo "USAGE:$0 localfile remotedir"
exit 1
fi
for n in 118 119 200
do
echo ===============192.168.43.$n==============
scp -P22 -r $1 bqh01@192.168.43.$n:~ &>/dev/null &&\
ssh -t bqh01@192.168.43.$n sudo rsync $1 $2 &>/dev/null
if [ $? -eq 0 ]
then
action "fenfa $1 ok" /bin/true
else
action "fenfa $1 failed" /bin/false
fi
done
执行脚本后效果如下:
![](https://i-blog.csdnimg.cn/blog_migrate/7c2bb7fcc6472103550020410c2ff854.png)
我们从其他机器上查看是否分发过来了:
![](https://i-blog.csdnimg.cn/blog_migrate/4f9253d6d96f3c23c32f66d8efbbf9a5.png)
ok。
当然我们可以用隧道模式传输:rsync -avz hosts -e 'ssh -p 22' bqh01@192.168.43.200:~
例如:设置suid对固定命令授权(同上方法,只是不用sudo提权,而是设置suid权限)
我们先去除之前推送过去的文件:
![](https://i-blog.csdnimg.cn/blog_migrate/2c228e66f9eeb494491dce8a7234e075.png)
将目标主机上的rsync命令增加s权限(存在危险)
chmod 4755 /usr/bin/rsync
sh fenfa.sh hosts /etc/ceshi/
![](https://i-blog.csdnimg.cn/blog_migrate/f5cd066208656505d7905d0665a48045.png)
我们从其他机器上查看是否分发过来了:
![](https://i-blog.csdnimg.cn/blog_migrate/e3e4e2c000ad3e49d02b9cf0d6a7b500.png)
ok。
ssh批量分发与管理方案小结:适用于(5-70台服务器)
1、利用root做ssh key验证
优点:简单,易用
缺点:安全差,同时无法禁止root远程连接这个功能。
企业应用:80%的中小型企业在用此方法。
2、利用普通用户如bqh01来做
先把分发的文件拷贝到服务器用户家目录下,然后sudo提权拷贝分发的文件发到远程对应权限的目录下
优点:安全,无需禁用root远程连接这个功能。
缺点:配置比较复杂。
3、同方法2,只是不用sudo,而是设置suid对固定命令授权
优点:相对安全
缺点:复杂,安全性较差。任何人都可以处理带有suid权限的命令。
在生产场景中ssh适用于:批量分发数据、代码、管理等用途。
=================================================================