ssh服務認證類型主要有兩個： 基於口令的安全驗證： 基於口令的安全驗證的方式就是大家一直在用的，只要知道伺服器的ssh連接賬戶、口令、IP及開發的埠，預設22，就可以通過ssh客戶端登陸到這台遠程主機上。此時，聯機過程中所傳輸的數據都是加密的。 基於密鑰的安全驗證： 基於密鑰的安全驗證方式是指， ...
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文件里去，方便訪問解析快。
通過scp命令發向其他機器上。
scp -r /etc/hosts [email protected]: /etc
創建一個分發管理用戶
創建一個密鑰對：（分發機器上創建，切換到分發用戶下創建一對密鑰）
rsa與dsa密鑰類型的區別：
rsa即可以進行加密，也可以進行數字簽名實現認證，而dsa只能用於數字簽名從而實現認證。
su – bqh01
ssh-keygen –t dsa
ssh-keygen是生產密鑰的工具，-t參數指建立密鑰的類型，這是是建立dsa類型密鑰，也可以建立rsa類型密鑰。
此時我們需要把產生的公鑰（鎖）發給區域網中的各個機器上：
ssh-copy-id -i .ssh/id_dsa.pub [email protected]
ssh-copy-id -i .ssh/id_dsa.pub [email protected]
ssh-copy-id -i .ssh/id_dsa.pub [email protected]
如果ssh修改了特殊埠，如8886，那麼用上面的ssh-copy-id命令就無法進行分發公鑰了，如果仍要用ssh-copy-id的話，可以用：
ssh-copy-id –I id_dsa.pub “-p 8886 [email protected]” //特殊埠分發，要適當加引號。
我們可以上118伺服器上查看是否分發過來了：
ok。
此時我們就可以批量管理各個機器了：
例如查看各個機器上的ip地址：可以寫一個簡單腳本
vi fenfa.sh
ssh -p22 [email protected] /sbin/ifconfig eth0
ssh -p22 [email protected] /sbin/ifconfig eth0
ssh -p22 [email protected] /sbin/ifconfig eth0
簡單腳本： #!/bin/sh for n in 118 119 200 do ssh –p22 [email protected].$n /sbin/ifconfig eth0 done
ok。
接下來我們分發一個文件：先要把分發的文件拷貝到普通用戶家目錄下
vi fenfa.sh
scp -P22 hosts [email protected]:~
scp -P22 hosts [email protected]:~
scp -P22 hosts [email protected]:~
簡單腳本： #!/bin/sh for n in 118 119 200 do scp –P22 hosts [email protected].$n:~ done
我們從其他機器上查看是否分發過去了：
ok。
當我們批量分發到遠程機器的其他目錄下會出現以下錯誤提示：
錯誤：原因是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
我們切換到普通用戶下推送一下hosts到/etc/ceshi下試試看：
出現Connection to 192.168.43.118 closed.這種提示表表示執行成功
我們再從其他機器上查看是否推送過來了：
ok。
可以寫一個分發腳本：
腳本優化：
#!/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 [email protected].$n:~ &>/dev/null &&\
ssh -t [email protected].$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
執行腳本後效果如下：
我們從其他機器上查看是否分發過來了：
ok。
當然我們可以用隧道模式傳輸：rsync -avz hosts -e 'ssh -p 22' [email protected]:~
例如：設置suid對固定命令授權（同上方法，只是不用sudo提權，而是設置suid許可權）
我們先去除之前推送過去的文件：
將目標主機上的rsync命令增加s許可權（存在危險）
chmod 4755 /usr/bin/rsync
sh fenfa.sh hosts /etc/ceshi/
我們從其他機器上查看是否分發過來了：
ok。
ssh批量分發與管理方案小結：適用於（5-70台伺服器）
1、利用root做ssh key驗證
優點：簡單，易用
缺點：安全差，同時無法禁止root遠程連接這個功能。
企業應用：80%的中小型企業在用此方法。
2、利用普通用戶如bqh01來做
先把分發的文件拷貝到伺服器用戶家目錄下，然後sudo提權拷貝分發的文件發到遠程對應許可權的目錄下
優點：安全，無需禁用root遠程連接這個功能。
缺點：配置比較複雜。
3、同方法2，只是不用sudo，而是設置suid對固定命令授權
優點：相對安全
缺點：複雜，安全性較差。任何人都可以處理帶有suid許可權的命令。
在生產場景中ssh適用於：批量分發數據、代碼、管理等用途。
=================================================================
