VPS 如何加固 SSH 安全設定？

為何 SSH 是首要加固項目

SSH 是您控制伺服器的管道，這使其成為所有攻擊者首要嘗試破解的鎖。VPS 一旦上線，掃描器便會立即開始針對 22 埠嘗試猜測使用者名稱與密碼。您可以在幾分鐘內透過日誌觀察到此現象。加固 SSH 的核心在於移除攻擊者可猜測的因素：徹底停用密碼登入、停用 root 登入，並僅允許加密金鑰存取。完成這些設定後，持續的猜測攻擊將無法成功，因為系統已不存在可供破解的密碼。

此步驟假設您已能正常使用 SSH。只要您能登入，就能進行加固。請依序執行步驟，並保持目前的連線開啟，直到確認新的連線運作正常，以避免因設定錯誤而將自己鎖在伺服器外。

步驟 1：確保金鑰驗證運作正常

金鑰驗證以金鑰對取代密碼：私鑰保留在您的電腦上，公鑰則放置於伺服器。伺服器會在私鑰不離開您機器的情况下，驗證您是否持有該私鑰。在停用密碼登入前，請務必確認金鑰驗證已生效，否則您將無法登入伺服器。

若您尚未建立金鑰，請在您的電腦上執行：

ssh-keygen -t ed25519

將公鑰複製到伺服器：

ssh-copy-id user@your-server

接著開啟新的 SSH 連線。若系統未要求輸入密碼即可登入，代表金鑰運作正常，您可以安全地停用密碼驗證。若系統出現 Permission denied (publickey) 錯誤，該錯誤可能源自五種不同的原因，請先查看 ssh -v 的輸出訊息以釐清問題，切勿在未排除故障前進行其他變更。若您對金鑰尚不熟悉，或使用多台電腦，SSH 金鑰管理基礎 說明了完整的運作模型：包含每台裝置使用獨立金鑰、sshd 所需的權限設定，以及當筆記型電腦遺失時如何撤銷金鑰。

步驟 2：使用 drop-in 檔案強化 sshd

請勿直接編輯 /etc/ssh/sshd_config。Ubuntu 24.04 會從 /etc/ssh/sshd_config.d/ 讀取 drop-in 檔案，在此處建立小檔案較為乾淨，不僅能避免套件升級時被覆蓋，若發生問題也易於移除。檔案命名至關重要：sshd 會採用讀取到的第一個設定值，而 Ubuntu 雲端映像檔在此目錄中預設包含 50-cloud-init.conf 以及 PasswordAuthentication yes。請將您的檔案命名為 00-，使其排序優先於該檔案並生效；若命名為 99- 則會被靜默忽略。建立檔案：

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

填入以下內容：

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

每一行設定都在關閉一道門。PasswordAuthentication no 是最關鍵的一項：停用密碼後，暴力破解攻擊將無從下手。KbdInteractiveAuthentication no 則關閉了另一種密碼驗證途徑。PermitRootLogin no 意味著攻擊者必須同時知道您的使用者名稱並持有您的金鑰，而非僅能針對每台機器上都存在的 root 帳號進行攻擊。

步驟 3：測試設定並重新載入

在套用設定前請先檢查是否有誤，避免因拼字錯誤導致服務中斷：

sudo sshd -t

若未輸出任何訊息，代表設定檔有效。請重新載入 SSH：

sudo systemctl reload ssh

接著檢查 sshd 實際使用的設定，以確認是否有設定檔被其他檔案覆蓋：

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

兩者皆應顯示 no。現在，請勿關閉目前的連線，並從另一個終端機開啟新的連線。若能透過金鑰成功登入，即代表設定完成。若有任何問題，您仍可透過第一個連線進行修復。此重疊機制是您的安全防護網，請務必執行。

步驟 4：選用的非標準連接埠

將 SSH 從 22 埠移至 2222 等連接埠並不會實質提升安全性，因為決心入侵的攻擊者會掃描所有連接埠。此舉僅能減少日誌中的雜訊，因為大多數自動化掃描器只會嘗試 22 埠。若您有此需求，請將 Port 2222 加入您的 drop-in 檔案，先在防火牆中放行新連接埠，接著執行 sudo systemctl daemon-reload && sudo systemctl restart ssh.socket，並使用 ssh -p 2222 進行連線。在 Ubuntu 24.04 上，ssh.socket 會接管監聽埠，因此單純執行 reload ssh 無法將 sshd 從 22 埠移開；必須重新啟動 socket 才能套用新連接埠。請將此視為整理環境，而非防護手段。

步驟 5：部署進階防禦層

強化後的 SSH 金鑰是基礎，在此之上還能疊加兩層防禦。

Fail2ban 會監控您的日誌，並封鎖持續驗證失敗的位址，這能過濾掃描器的雜訊並提前將其排除。它與僅限金鑰驗證的機制搭配效果極佳：請參閱 在 Ubuntu 上使用 Fail2ban 阻擋 SSH 攻擊。

更強大的做法是將 SSH 完全移出公用網際網路。若您將 SSH 放置於 WireGuard VPN 後方 並將防火牆的 22 埠限制在隧道內，VPN 以外的任何人都無法觸及該埠，暴力破解攻擊將變得不可能，而不僅僅是變得困難。上述所有措施皆假設底層已設定預設拒絕（default-deny）的防火牆，請參閱 在 VPS 上設定 UFW。

SSH 只是完整檢查清單中的一環：新 VPS 的前 10 分鐘 說明了各步驟的先後順序，而 Ubuntu 自動安全性更新 則確保伺服器後續能持續修補漏洞。鎖上大門對門後的服務毫無幫助，因此若同一台 VPS 執行了密碼庫，Vaultwarden 加固指南 將涵蓋金鑰驗證無法觸及的兩個關鍵點：管理權杖（admin token）與備份檔案。

FAQ

如何在 Ubuntu 24.04 上停用 SSH 密碼登入？

在 /etc/ssh/sshd_config.d/00-hardening.conf 建立一個設定檔（使用 00 作為前綴，確保其排序優先於 50-cloud-init.conf，因為 sshd 會優先採用讀取到的第一個值，而 PasswordAuthentication yes 會覆蓋後續設定），內容包含 PasswordAuthentication no 與 KbdInteractiveAuthentication no。執行 sudo sshd -t 檢查語法，接著執行 sudo systemctl reload ssh。在依賴此設定前，請務必開啟新的連線測試金鑰登入是否正常。編輯額外的設定檔而非直接修改 sshd_config，可確保升級套件時設定不會被覆蓋，且易於還原。

我應該停用 SSH 的 root 登入嗎？

應該。設定 PermitRootLogin no 以禁止任何人直接以 root 身分登入。請以一般使用者帳號登入，並使用 sudo 執行管理任務。Linux 系統皆存在 root 帳號，若開放遠端存取，等於提供攻擊者一個已知的目標帳號。停用後，攻擊者必須同時知道您的帳號名稱並持有您的金鑰才能入侵。

更改 SSH 連接埠能提升伺服器安全性嗎？

效果有限。將連接埠移出 22 號埠可避開僅掃描 22 埠的自動化腳本，減少日誌中的雜訊，但真正的攻擊者會掃描所有連接埠並找到它。僅使用金鑰認證才是防止入侵的關鍵。若要更改連接埠，請先在防火牆開啟新連接埠，再執行 sudo systemctl daemon-reload && sudo systemctl restart ssh.socket；在 Ubuntu 24.04 上，socket 負責監聽，僅執行 reload 無法將 sshd 從 22 號埠移出。

如果我使用 SSH 金鑰，還需要 Fail2ban 嗎？

這是選用的，但仍有幫助。在僅限金鑰認證的情況下，密碼猜測攻擊無法成功，因此 Fail2ban 並非防禦入侵的主要手段。它能針對單一來源的重複失敗嘗試進行速率限制，從而減少日誌中的掃描雜訊並封鎖重複攻擊者；不過，緩慢且分散式的攻擊通常仍會低於其封鎖門檻。建議在金鑰認證之上部署 Fail2ban，並盡可能將 SSH 服務隱藏在 VPN 之後。

如果我不小心將自己鎖在 SSH 之外，該如何復原？

請使用雲端服務商提供的網頁控制台，透過序列埠或 VNC 連線存取伺服器，這些連線不經過 SSH。登入後，您可以修正 sshd 的設定檔並重新載入服務。這正是為什麼在關閉當前連線前，必須先在第二個終端機測試新 SSH 設定的原因，也是為何在停用密碼前應先確保金鑰認證已運作正常的原因。