本文翻譯自：A Guide to Securing the SSH Daemon

SSH（Secure Shell）是一種能夠讓使用者安全訪問遠端系統的網路協議，它為不安全網路中的兩臺主機提供了一個強加密資料通訊通道。SSH是Linux、UNIX系統管理員操作和管理主機的首選方式。雖然SSH比其他通訊方式更加安全，但是錯誤的配置也可能導致其出現安全問題。這篇文章的目的就是提供一個幫助你加固SSH的指南。

這篇指南將涉及到很多選項，但這些選項並不適合所有的伺服器，只有你自己瞭解自己的環境配置、使用者基礎以及資料的重要性，因此到底哪些配置適合於你的系統，完全取決於你、你公司的安全策略或者是你組織內的某些人。

目錄

• 寫在前面
• 僅使用SSHv2 協議
• 關閉或者延遲壓縮
• 限制身份驗證最大嘗試次數
• 禁用root賬戶登入
• 顯示最後一次登入的日期和時間
• 結束空閒的SSH會話
• 禁用空密碼
• 禁用基於受信主機的無密碼登入
• 禁用基於已知主機的訪問
• 禁用基於主機的身份認證
• 禁用X11Forwarding
• 使用非常規埠
• 將服務繫結到指定IP
• 保護SSH金鑰
  • 保護主機私鑰
  • 保護主機公鑰
• 檢查使用者特定的配置檔案
• 防止特權升級
• 使用金鑰進行身份驗證
• 禁用不使用的身份驗證方法
  • 禁用 GSSAPI 認證
  • 禁用Kerberos認證
  • 禁用口令認證
  • 禁用金鑰認證
• 使用符合FIPS 140-2標準的密碼
• 使用符合FIPS 140-2標準的MAC
• 配置主機防火牆過濾傳入的SSH連線
  • 使用iptables過濾SSH連線
  • 通過Firewalld過濾SSH連線
  • 使用UFW過濾SSH連線
• 設定一個Banner
• 其他可選程式
• 總結

寫在前面

以下內容適用於本指南，除非另有說明

• 本文所編輯的SSH配置檔案指的是sshd_config檔案，而不是ssh_config（注意ssh後面的有個d）。
• 任何對SSH配置的修改都需要重啟服務後生效。
• 我們所要討論的絕大多數選項已經寫在sshd_config檔案中了，在進行配置前最好確認是否已經設定了該選項，盲目設定將會導致衝突。
• SSH配置檔案中有許多帶有註釋的行（註釋以#開頭），註釋掉的選項將不會在服務中啟用，若要使其生效，需要刪除前面的#。
• 註釋通常顯示為該選項的預設值。

僅使用SSHv2 協議

SSHv1是已知的對於SSH協議的不安全實現，為了確保系統的完整性，應當將SSH服務配置為僅接受SSHv2連線。

通過取消以下行配置的註釋，來配置SSH服務僅接受SSHv2協議。

Protocol 2

備註：RedHat和CentOS在7.4版本之後使用SSHv2作為預設配置，但是“我”仍喜歡將該行寫入配置檔案。

關閉或者延遲壓縮

SSH可以使用gzip演算法壓縮資料，如果壓縮軟體中存在漏洞，就可能影響到系統。

關於在快速連線上是否需要啟用壓縮，已經進行了很多討論，普遍認為壓縮實際上會減慢處理速度，除非你使用慢速連線（調變解調器、ISDN等）。如果必須使用壓縮功能，請使用延遲功能來確保在壓縮開始前對使用者進行身份驗證。

關閉壓縮功能（推薦）：

Compression no

要將壓縮延遲到身份認證後，則需要修改為：

Compression delayed

這裡的“快速連線”和“慢速連線”沒太理解，原文為“fast connections”、“slow connection”，可能指的就是通訊通道的傳輸速率吧。

限制身份驗證最大嘗試次數

限制使用者失敗認證的最大次數是一個緩解暴力攻擊的好方法。將MaxAuthTries設定為比較小的數字（x），將會在使用者x次失敗嘗試後強制斷開會話。

限制最大身份驗證嘗試次數，請修改sshd_config中的配置為如下：

MaxAuthTries 3

You can set this number as low as you like, but 3 is a good balance between security and convenience in my opinion.

你可以任意調低這個數字，但是我認為“3”是在安全和便利之間較為平衡的設定。

禁用root賬戶登入

如果你允許root使用者登入，則不能將操作關聯到使用者，強制使用者使用特定於使用者的賬戶登入可以確保問責機制。此外，這樣設定還可以進一步保護root賬戶免受其他型別的攻擊。

阻止使用者使用root賬戶登入，請修改配置如下：

PermitRootLogin no

強烈建議使用此配置。

顯示最後一次登入的日期和時間

這通常是現代系統中的預設設定，但是檢查其是否正確配置仍然很重要。通過列印最後一次登入的日期和時間，使用者可以意識到未經授權的賬戶登入事件，這將對進一步調查無法識別的訪問提供幫助。

輸出最後一次登入日期和時間，請修改配置如下：

PrintLastLog yes

這是條安全的捷徑。

結束空閒的SSH會話

無限期地將SSH會話保持開啟狀態不是一個好主意，因為使用者可能離開他們的工作站，這給了一個未授權使用者在無人看管的工作站上執行命令的好機會。最好的辦法是在短時間內終止空閒的SSH會話，不給他人留機會。

ClientAliveCountMax選項和ClientAliveInterval選項相互配合，例如要在十五分鐘（900秒）後關閉不活動的會話，修改配置檔案如下：

ClientAliveInterval 900
ClientAliveCountMax 0

更多有關ClientAliveInterval的說明：

設定超時間隔（以秒為單位），在此間隔後，如果未從客戶端接收到任何資料，sshd服務端將通過加密的通道傳送訊息請求客戶端迴應。預設值為0，表示不會執行該操作。

更多有關ClientAliveCountMax的說明：

設定客戶端探活訊息（上文所述操作）的數量，如果傳送客戶端探活訊息達到此閾值，則sshd服務端將斷開客戶端連線，從而終止會話。

指定白名單使用者

你可以通過白名單指定那些經過授權的使用者來連線SSH伺服器，只有在這個列表中的使用者才有權登入SSH，其他人則不行。這樣做好處多多。

若僅允許 "pfloyd"、 "rwaters"和 "dgilmour"這三個 使用者的話，修改配置檔案如下：

AllowUsers pfloyd rwaters dgilmour

你同樣可以使用DenyUsers來禁止某些使用者，比如這樣修改配置檔案：

DenyUsers root ncarter ajmclean hdorough

這個設定並不是總是可用的，如果你的環境可以支援此配置，那肯定會提高安全性的。

禁用空密碼

確保任何SSH連線都需要一個非空的密碼字串（這並不會影響SSH金鑰認證登入模式）。

修改配置檔案如下：

PermitEmptyPasswords no

這是另一個簡單卻重要的配置，建議對所有非特殊情況下使用。

如果你使用密碼認證，實施密碼複雜性規則是一個明智的選擇。這些規則可以是由你的組織制定，或者嘗試以下“最佳實踐”：

• 密碼長度大於x
• 密碼至少包含x個小寫字元
• 密碼至少包含x個大寫字元
• 密碼至少包含x個數字
• 密碼至少包含x個特殊字元
• 密碼不得包含使用者名稱（正向或者反向）

想要了解更多有關設定密碼複雜性的資訊，可以參看《如何在RedHat中強制設定密碼複雜性》，雖然這篇文章針對RedHat的，但是它可以在任何使用最新版的PAM（可插拔身份驗證模組）的Linux系統上執行。

禁用基於受信主機的無密碼登入

rhosts檔案是一種控制系統間信任的關係的方法，如果一個系統信任另一個系統，則這個系統不需要密碼就允許來自受信認系統的登入。這是一個老舊的配置，應當在SSH配置中明確禁用。

確保SSH不允許受信主機連線，請修改配置檔案如下：

IgnoreRhosts yes

rhosts檔案已經很少使用了，建議在多數情況下啟用該配置。

禁用基於已知主機的訪問

known_hosts檔案用於標識伺服器，當用戶啟動SSH連線時，SSH會將伺服器指紋與known_hosts檔案中儲存的指紋進行比較，來確保使用者連線到的是正確的系統。這個配置與rhosts配置相互配合，確保與遠端主機連線時需要密碼（通過設定該選項，來保證每一次連線都將遠端主機視為“非信任”主機）。

在身份驗證時忽略已知主機，請修改配置檔案如下：

IgnoreUserKnownHosts yes

這個配置適用於絕大多數環境。

禁用基於主機的身份認證

這個功能類似於基於受信主機的認證，但是僅用於SSH-2，在我的經驗裡這個功能很少使用，應當設定為no。

禁用基於基於主機的身份認證，請修改配置檔案如下：

HostBasedAuthentication no

這個選項預設情況下設定為no，但是為了保險起見，我將其顯式新增到配置檔案中。

禁用X11Forwarding

X11Forwarding允許通過SSH會話遠端執行程式，並在客戶端顯式圖形介面。如果沒有特殊需求，則應將其禁用。

禁用X11Forwarding，請修改配置檔案如下：

X11Forwarding no

X11Forwarding很少使用，我建議在大多數系統上禁用該功能。

使用非常規埠

預設情況下，SSH監聽在TCP 22 埠，黑客和指令碼小子經常對這個埠進行掃描，來判斷目標是否執行SSH，另外2222和2121也是常用的監聽埠，最好不要使用這些埠，請使用不常見的高階埠，例如示例中的9222埠。

設定SSH監聽在非常規埠，請修改配置檔案如下；

Port 9222

我通常不修改位於防火牆後面的那些預設埠，但是如果您的主機暴露在網際網路或者其他不受信任的網路中，這樣的設定是必要的。

注意：不要忘記更改防火牆規則，允許流量訪問你自定義的埠。

將服務繫結到指定IP

預設情況下，SSH會監聽本機上配置的所有IP地址，但是你應該指定SSH繫結在特定的IP，最好是在專用VLAN中的地址。

指定繫結地址，請修改配置檔案如下

ListenAddress 10.0.0.5

這個設定通常與埠繫結相互配合。

保護SSH金鑰

保護主機私鑰

你應該保護主機私鑰防止未授權的訪問，如果私鑰洩露，則主機可能會被假冒，因此所有的私鑰檔案都應設定為僅允許root使用者訪問（對應許可權為0600）。

使用ls命令列出/etc/ssh/資料夾下所有的私鑰檔案：

ls -l /etc/ssh/*key

使用chmod命令設定私鑰檔案許可權：

chmod 0600 /etc/ssh/*key

大多數情況下，私鑰檔案儲存在/etc/ssh/資料夾下，但是也有可能儲存在其他目錄中，通過以下命令可以檢索配置檔案中設定的儲存位置：

grep -i hostkey /etc/ssh/sshd_config

保護主機公鑰

雖然公鑰不如私鑰那麼重要，但你還是應該對其進行保護，因為如果公鑰被篡改，則可能會使SSH服務無法正常工作或者拒絕服務，因此需要配置許可權僅允許root賬戶對其進行修改（對應許可權為0644）。

使用ls命令列出/etc/ssh/目錄下所有的公鑰檔案：

ls -l /etc/ssh/*pub

使用chmod命令修改公鑰檔案許可權：

chmod 0644 /etc/ssh/*pub

通常情況下公鑰和私鑰存放在同一目錄下，或者使用上一節的方法查詢存放路徑。

檢查使用者特定的配置檔案

使用者可能會在無意間將自己的home目錄或者其他某些檔案設定成全域性可寫（比如777許可權），在這種情況下，其他使用者將有權修改使用者特定的配置，並以其他使用者的身份登入到伺服器。可以通過使用StrictModes選項來檢查home目錄的配置。

StrictModes設定ssh在接收登入之前是否檢查使用者home目錄和rhosts檔案的許可權和所有權，StrictModes為yes必需保證存放公鑰的資料夾的擁有者與登陸使用者名稱是相同的。

確保啟用嚴格模式，請修改配置檔案如下：

StrictModes yes

建議使用此方法，尤其是對於有大量使用者的系統。

防止特權升級

SSH通過建立一個無特權的子程序來接收傳入的連線，實現許可權分離。使用者身份驗證後，SSH將使用該使用者的許可權建立另一個程序。

在我所瞭解的系統中，這個選項預設都是開啟的，但是為了保險起見，建議還是手動修改配置檔案，顯式指定該配置：

UsePrivilegeSeparation sandbox

使用sandbox可以增加其他限制。

使用金鑰進行身份驗證

該功能並不一定在所有系統上都可用，但是使用SSH金鑰身份驗證有很多優點。金鑰驗證比人類可以輕鬆記住的任何密碼都要強大的多，同時還提供了無需密碼的身份驗證，使用更加便利。

啟用金鑰身份驗證，請修改配置檔案如下：

PubkeyAuthentication yes

該選項在大多數系統上預設為yes。

更多有關SSH金鑰身份驗證的資訊，請參考 How to Setup SSH Key Authentication。

禁用不使用的身份驗證方法

Linux管理員知道優秀的安全實踐是停止並刪除所有用不到的服務，同樣，你也應該禁用SSH中不使用的其他任何身份驗證方法。

在這裡，我將向你展示禁用所有身份驗證的方法，但是請注意：不要全部禁用它們，請保留需要的。

禁用 GSSAPI 認證

通過“通用安全服務應用程式介面”（GSSAPI），可以使用高階配置和其他身份驗證方法（除口令、金鑰認證方式之外的），如果你不使用此功能，則請修改配置檔案如下：

GSSAPIAuthentication no

禁用Kerberos認證

同樣，如果不需要則禁用：

KerberosAuthentication no

禁用口令認證

如果配置了更高階的認證方式，則可禁用口令認證：

PasswordAuthentication no

禁用金鑰認證

如果你使用了其他身份認證方式，則可以禁用金鑰身份認證。相比其他辦法，使用金鑰認證是風險較小的辦法。如需禁用，修改配置檔案如下：

PubkeyAuthentication no

使用符合FIPS 140-2標準的密碼

使用符合FIPS 140-2的規範，避免使用弱加密演算法，請修改配置檔案如下：

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

這樣的設定限制了可用於SSH的加密方式，因此應用前需確認任何可能會用到的老舊客戶端、指令碼或應用程式的相容性。

“FIPS 140-2” 為美國國家標準和技術委員會發布的針對密碼模組的安全需求標準，作為聯邦資訊處理標準在政府機構廣泛採用。

使用符合FIPS 140-2標準的MAC

與上一小節相同，使用符合FIPS 140-2的規範，避免使用弱加密雜湊演算法：

MACs hmac-sha2-256,hmac-sha2-512

配置主機防火牆過濾傳入的SSH連線

檢查傳入SSH連線也是保護SSH的好方法，可以僅允許特定的IP或子網連線到系統，下面將演示通過iptables、firewalld 和 Uncomplicated Firewall (UFW)配置防火牆的方法。

使用iptables過濾SSH連線

允許特定IP連線：

iptables -I INPUT -p tcp -s <指定的IP> --dport 22 -j ACCEPT

允許特定的子網：

iptables -I INPUT -p tcp -s <指定子網> --dport 22 -j ACCEPT

更多有關iptables的使用方法，請參考The Basics of IPTables自己度娘

通過Firewalld過濾SSH連線

允許特定IP連線SSH：

firewall-cmd --permanent --zone=public --add-rich-rule=' rule family="ipv4"   source address="<指定IP>"   port protocol="tcp" port="22" accept'

允許特定子網：

firewall-cmd --permanent --zone=public --add-rich-rule='   rule family="ipv4"   source address="<指定子網>"   port protocol="tcp" port="22" accept'

使用UFW過濾SSH連線

允許特定IP連線SSH：

sudo ufw allow from <指定IP> to any port 22

允許特定子網：

sudo ufw allow from <指定子網> to any port 22

設定一個Banner

以我的經驗來看，這樣做弊大於利，雖然修改Banner（連線提示資訊）可以阻止一些指令碼小子，但是數經驗豐富的老鳥可能會將其視為一種挑釁，因此如果確實要增加Banner，請考慮訊息的語氣。

啟用自定義Banner，請修改配置檔案如下：

Banner /etc/issue

編輯/etc/issue檔案，即可新增連線到SSH後的提示資訊。

其他可選程式

有很多程式可以用來幫我們組織攻擊，其中最著名的是fail2ban，它通過掃描日誌來查詢惡意行為，並通過更新防火牆規則等操作來阻止可疑IP。關於fail2ban的配置不在本文的討論範圍。

總結

在本文中，我介紹了許多選項來幫助保護你的SSH服務，正如我在簡介中所述，每種設定的可用性取決於您，只有您可以權衡這些設定的便利性和安全性。瞭解可用的選項是一個好的開始，我認為本文涵蓋了有關安全方面的大多數選項，如果你使用了本文所有的配置，那麼你的配置將超過《美國國防資訊系統局安全技術資訊指南》的要求。