伺服器安全基礎：新 VPS 到手先做這 6 件事（2026）

官網核實最後核驗：2026-11-13 · 依據：Ubuntu、OpenSSH 與 Fail2ban 官方文件的公開轉述

一句話結論：新 VPS 到手，按更新、金鑰登入、非 root 使用者、防火牆、登入防護、備份的順序做 6 件事；順序有講究——先驗證金鑰能登入再禁用密碼，先放行 SSH 再啟用防火牆。

核驗資訊：本文為官網核實，未實測。6 件事的做法來自 Ubuntu 官方伺服器文件、OpenSSH 官方手冊與 Fail2ban 官方文件的公開轉述，命令與配置項名以官方文件為準；本文不貼整段配置檔案。逐條來源見研究筆記。

下表是 6 件事的總覽，正文按順序逐件說明做什麼、為什麼、官方做法是什麼。本文以 Ubuntu 為例，其他發行版以各自官方文件為準。

順序	事項	關鍵動作
1	系統更新	更新全部軟體包，並啟用自動安全更新
2	金鑰登入	生成金鑰、驗證登入，再禁用密碼登入
3	非 root 使用者	新建日常使用者加 sudo，禁用 root 直接登入
4	防火牆	預設拒絕入站，只放行需要的埠
5	登入防護	Fail2ban 或等效防護，攔截反覆失敗的登入嘗試
6	備份與快照	拍快照、做備份，並確認備份能恢復

第 1 件：系統更新

做什麼：登入後先更新軟體包列表並升級全部軟體包，升級完成後按提示決定是否重啟。接著啟用自動安全更新，讓系統每天自動安裝安全補丁。

為什麼：新例項的系統映象製作於部署之前，軟體包可能已落後於最新安全補丁；伺服器暴露在公網上，補丁越晚打，暴露視窗越長。

官方做法：Ubuntu 官方文件的做法是使用 apt 更新與升級，並用 unattended-upgrades 實現自動安全更新：安裝後用 dpkg-reconfigure 配置，預設只自動安裝安全更新；自動重啟由 50unattended-upgrades 裡的 Automatic-Reboot 與 Automatic-Reboot-Time 控制，核心更新生效需要重啟。

第 2 件：金鑰登入

做什麼：在自己的電腦上生成 SSH 金鑰對，把公鑰裝到伺服器對應使用者的 authorized_keys 檔案裡，用金鑰登入驗證成功後，再禁用密碼登入。整個過程中保持當前 SSH 會話不斷開。

為什麼：密碼可以被反覆猜測，公網伺服器的 SSH 埠每天都會收到大量密碼猜測嘗試；金鑰登入用金鑰檔案驗證，禁用密碼登入後，這類猜測就沒有了可猜的目標。

官方做法：Ubuntu 官方文件推薦 Ed25519 演算法生成金鑰（ssh-keygen），並用 ssh-copy-id 把公鑰複製到伺服器；RSA 4096 位是備選。禁用的關鍵配置項是 PasswordAuthentication，設為 no；同時確認 PubkeyAuthentication 為 yes；鍵盤互動認證由 KbdInteractiveAuthentication 單獨控制，是否一併禁用，取決於伺服器是否依賴它做多因素認證。OpenSSH 對多數配置項取第一個讀到的值，而 Ubuntu 的主配置檔案會包含 sshd_config.d 目錄下的片段檔案，雲廠商映象可能已在該目錄預置配置；改完後用 sshd -t 檢查語法、用 sshd -T 檢視實際生效值，確認無誤再重啟 SSH 服務。

第 3 件：非 root 使用者

做什麼：新建一個日常使用者，加入 sudo 組，讓它可以透過 sudo 執行管理命令；把 SSH 金鑰裝到這個使用者，確認能用金鑰登入；然後禁用 root 賬戶的 SSH 直接登入。

為什麼：root 賬戶擁有全部許可權，誤操作沒有二次確認，賬戶被盜用的後果也是全部許可權。日常用非 root 使用者、需要時用 sudo 提權，誤操作的範圍被限制在普通許可權內。

官方做法：Ubuntu 官方文件的流程是：用 adduser 建立使用者、用 usermod 把使用者加入 sudo 組。禁用 root 直接登入的關鍵配置項是 PermitRootLogin，設為 no；改完後同樣用 sshd -T 確認生效值。注意順序：先建好有 sudo 許可權的使用者並驗證金鑰登入，再禁用 root 登入。

第 4 件：防火牆

做什麼：啟用防火牆，預設拒絕入站連線、預設允許出站連線；放行 SSH 埠，再按實際服務放行埠：Web 服務放行 80 與 443 埠，其他服務按需放行。啟用防火牆之前，必須先放行 SSH 埠。

為什麼：防火牆決定哪些服務能從公網訪問。預設拒絕的策略下，新裝的服務即使預設監聽在全部地址，也不會直接暴露到公網；最小放行把暴露面壓到實際需要的埠。

官方做法：Ubuntu 自帶的防火牆前端是 UFW，官方文件的做法是：設定預設策略為拒絕入站、允許出站，放行 OpenSSH 服務名對應的埠，再啟用防火牆；放行 Web 埠時用埠號加協議的方式指定。UFW 的 limit 規則可以對 SSH 做速率限制，作為登入防護的補充。需要注意，容器工具（如 Docker）會直接改動底層防火牆規則，容器釋出出去的埠可能繞過 UFW 的限制，用容器的伺服器要按容器工具的官方文件單獨核對。

第 5 件：登入防護

做什麼：安裝並啟用 Fail2ban，啟用針對 SSH 的 jail（sshd），讓它監視認證日誌，對短時間內多次登入失敗的來源 IP 做臨時封禁；確認服務在執行、jail 已啟用。不用 Fail2ban 的，也可以用雲廠商的防火牆組、速率限制等效防護代替。

為什麼：禁用密碼登入後，密碼猜測嘗試已經無法成功，但嘗試本身仍會持續產生日誌、佔用連線資源；Fail2ban 把反覆失敗的來源暫時擋在門外，減少無效流量。

官方做法：Fail2ban 官方文件的做法是：從發行版倉庫安裝，自定義配置寫在 jail.local 或 jail.d 目錄下的覆蓋檔案裡，不直接改 jail.conf；關鍵配置項是 bantime（封禁時長）、findtime（統計視窗）、maxretry（失敗次數）與 banaction（封禁動作，如配合 UFW）；用 fail2ban-client status 檢視 jail 狀態。較新的 Ubuntu 與 Debian 預設不再寫傳統的 auth.log，Fail2ban 需要把 backend 設為 systemd 才能讀 systemd 日誌；啟用後檢查 jail 是否真的在監視日誌。

第 6 件：備份與快照

做什麼：大改動前拍快照，長期執行的服務啟用自動備份，網站檔案與資料庫另外存一份在例項之外的副本；做完備份後，確認備份檔案存在、能讀取，並實際驗證一次恢復流程。

為什麼：前面 5 件降低的是被入侵與誤操作的機率，第 6 件處理的是“已經出問題”的情況：配置改壞、檔案誤刪時，沒有備份就只能重建；有備份但沒驗證過恢復流程，等於備份的有效性未知。

官方做法：以 Vultr 為例，官方文件區分了手動快照與自動備份：快照手動拍攝，按儲存量收費；自動備份按計劃自動拍攝，頻率可選每天、隔天、每週或每月，費用為例項費用的 20%，備份內容不包括掛載的塊儲存卷。費用與頻率數字見站內Vultr 建站全流程文章。其他服務商的規則各不相同，以各自官方文件為準；無論用哪家，異地副本與恢復驗證這兩點都不能省。

做完 6 件之後

6 件事做完，伺服器就有了基礎的安全基線；之後定期確認自動更新與防護都在執行，新增服務時確認只放行了需要的埠，改動 SSH 配置時先驗證、再斷開舊會話。拿不準的配置，以官方文件原文為準。

侷限

本文做法以 Ubuntu 與 2026 年 11 月的官方文件口徑為準，其他發行版可能不同。Fail2ban 的 backend 要求與 UFW 的容器繞過問題，來自多家 2026 年指南的轉述，未逐項開啟官方文件原文核對，操作前以官方文件為準。本文只講基礎的 6 件事，不涉及入侵檢測、審計與合規等主題。

更新日誌：
2026-11-13：首發