ssh服務簡介及應用與服務的進程的類型

SSH ，由 IETF 的網絡小組（Network Working Group）所制定；SSH 爲創建在應用層基礎上的安全協議。SSH 是目前較可靠，專爲遠程登陸會話和其餘網絡服務提供安全性的協議。利用 SSH 協議能夠有效防止遠程管理過程當中的信息泄露問題。SSH最初是UNIX系統上的一個程序，後來又迅速擴展到其餘操做平臺。SSH在正確使用時可彌補網絡中的漏洞。SSH客戶端適用於多種平臺。

默認端口號：22  

客戶端：openssh-client     服務端：openssh（linux系統默認客戶端，服務端都安裝了）

dropbear：非開源版的ssh

ssh的客戶端能夠用 XSHELL，Securecrt, Mobaxterm等工具進行鏈接

ssh的功能

1.遠程登陸
2.文件傳輸
3.功能共享
(都是加密實現)

兩個認證
     客戶端驗證服務器端
     服務器端對客戶端的作驗證

ssh獨立守護進程服務（以centos6爲例）
# service sshd start|stop|restart|status
# chkconfig sshd on

客戶端在收到服務器段的公鑰以後，會生成一個密鑰對，而後基於這個密鑰實現安全傳輸
1. 當服務器端啓動了ssh，那麼就會自動生成一個密鑰對
2. 當服務器端收到用戶鏈接請求，那麼就將公鑰文件發送給客戶端
3. 客戶端將收到的公鑰文件保存 ~/.ssh/known_hosts
下次登陸時候，若是有目標主機的公鑰文件，那麼就是對於目標服務器的認證完成
下次登陸時候，若是有目標主機的公鑰不存在文件或者信息有誤，那麼就是對目標服務器的認證失敗
4. 客戶端保存了服務器端公鑰文件後，會馬上產生一個私鑰文件，構成一個密鑰對，而後用公鑰文件加密密鑰對，而後將加密的數據傳遞到服務器端。服務器端解密之後，也就有了這樣的一個密鑰對。
5. 雙方基於這個密鑰對來通訊

ssh基於c/s架構
客戶端：
linux下客戶端：ssh，配置文件：/etc/ssh/ssh_config

服務器端；
名稱：sshd，配置文件：/etc/ssh/sshd_config

 linux下ssh客戶端的使用方法

格式

ssh [-p port] [user@]host [command]

服務器段的配置文件(經常使用配置)
Port 22 指定sshd服務所監聽的端口
ListenAddress 0.0.0.0 指定sshd服務所監聽的IP
UseDNS yes|no 指定是否將主機名稱作解析
PermitRootLogin yes|no 指定是否運行root登陸系統

基於密鑰方式登陸系統

1. 在用戶的家目錄中提早準備密鑰文件（公鑰）
2. 登陸的時候，客戶端會將公鑰文件發送給服務器端，而後服務器會作比對兩個公鑰，若是比對成功，會向客戶端發送一個質詢（該質詢是用傳輸密鑰對中的公鑰加密）
3. 客戶度收到這個質詢以後，會進行解密，而後將解密的結果發送給服務器端

 

案例：實現密鑰方式登陸系統
規劃
server：10.220.5.63
client：10.220.5.67

1.在客戶端器端建立一個密鑰對

-t rsa 指定加密算法

[root@67 ~]# ssh-keygen -t rsa        
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): <<<密鑰對的保存位置
/root/.ssh/id_rsa already exists.
Enter passphrase (empty for no passphrase): <<<對密鑰對加密密碼
Enter same passphrase again:  <<<確認密碼
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:iOndEAzGN3gx6OW8NtxoqRQ5oXEqtfb7besGUqKfpDc root@67managerslave
The key's randomart image is:
+---[RSA 2048]----+
|   .ooo.         |
|  o.*o=.         |
| . B Oo.         |
|. = *o+o         |
| o oo*o=S        |
|  ..=.Xo.        |
|   =.B.o.        |
|  . E  .o        |
|   . o.++.       |
+----[SHA256]-----+

2.查看祕鑰對

id_rsa       私鑰文件

id_rsa.pub   公鑰文件

[root@67 ~]# ls /root/.ssh
id_rsa  id_rsa.pub

3.傳送公鑰到服務器端主機

[root@67 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.220.5.63
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@10.220.5.63'
Number of key(s) added: 1 Now try logging into the machine, with:   "ssh 'root@10.220.5.63'" and check to make sure that only the key(s) you wanted were added.

說明：
-i：指定要傳輸的密鑰文件
root@10.220.5.63：指定傳輸到哪一個主機上面
傳遞到目標主機以後，公鑰文件會被重命名爲authorized_keys，該文件的權限必須600

3.在客戶端能夠直接登陸服務器端

[root@67 ~]# ssh 10.220.5.63
Last failed login: Sun Nov  4 02:00:26 CST 2018 from 10.220.5.67 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Sun Nov  4 00:16:27 2018 from 10.220.5.70
[root@63 ~]# <<<已登陸

linux ssh客戶端工具

ssh  做用：遠程登陸或者遠程執行命令
   格式：ssh -p 端口 用戶@主機 [命令]
scp   做用：傳輸文件
格式：
推送：scp /path/file user@host:/path
拉取：scp user@host:/path/file /path
選項
-P 端口：指定端口號
-r：遞歸傳輸一個目錄及其內部的文件
-p：保留文件的屬性不變
-v：顯示傳輸過程信息
-l：限制傳輸速率

總結：實現給多個主機分發文件
1. 發送端須要有私鑰文件
2. 全部的接收端須要有公鑰文件
3. 全部節點都須要有相同的用戶
4. 公鑰文件和私鑰文件必須有正確的權限

ssh登陸緩慢
啓用對主機名作反解
方式1：修改配置文件，禁止作反解 UseDns no
方式2：修改 /etc/hosts 添加一個主機名稱的解析記錄
方式3：ssh -v 查看登陸過程信息，判斷故障點

將一個文件傳遞到非用戶家目錄下，默認是沒有權限，解決方式
1. 用root身份執行操做
2. 用suid
3. 分兩步走，
第一步：先傳遞到目標主機的用戶的家目錄中
第二步：遠程執行命令，將目標主機家目錄中哪一個文件移動到目標位置（依賴sudo）

案例：web1用scp將文件a.txt傳遞到web2的/root下（以tom身份來傳輸文件）
第一步：在web2上爲tom作sudo受權
# visudo
tom ALL=() /bin/mv

第二步：在web1上執行scp，將a.txt傳遞到web2主機的/home/tom下
# scp a.txt tom@web2:/home/tom

第三步：在web1上執行ssh，將a.txt從tom家目錄中移動到root下
# ssh -t tom@web2 sudo mv /home/tom/a.txt /root/

ssh相關的操做日誌
/var/log/secure

生產環境中，實現文件批量分發方案有 1：基於ssh key+shell 優勢：簡單 缺點：節點數量幾百臺爲宜 2：puppet 優勢：功能強大、支持節點數量不少 缺點：操做複雜 3：saltstack 以上二者的折中方案 4：ftp/http+crotab 非主流方案