如何管理多台 Linux 伺服器？依規模推薦工具

您的建置目標

並非單一工具，而是根據您的實際伺服器數量來選擇的技術棧。伺服器數量是唯一的關鍵指標，但大多數「Linux 伺服器管理工具」的彙整清單都忽略了這一點。常見的錯誤是針對 4 台 VPS 採用了適用於 200 台伺服器的方案，導致您花費一個月在維護工具，而非管理伺服器。另一個常見錯誤是擁有 18 台伺服器的人仍手動透過 SSH 連線，並以 18 種略有不同的方式套用「相同」的變更。

因此，本指南依據規模進行分類：2 至 5 台、5 至 20 台，以及超過 20 台。此外，還包含適用於所有規模且鮮少被提及的核心層：資產清單、金鑰管理、統一的存取方式，以及經過實際復原測試的備份。針對每種工具，您將獲得三個資訊：它取代了什麼、設定所需時間（以分鐘計），以及一個真正會造成困擾的陷阱。我經營 VPS 主機服務已有 15 年經驗；下表列出的是在凌晨 2 點發生故障時仍能穩定運作的方案，而非僅適合演示的工具。

前置作業與注意事項

您必須先完成所有伺服器的 key-based SSH 設定（若仍需輸入密碼，請先解決此問題 — 這只需 10 分鐘，且下述所有步驟皆假設已使用 SSH keys）。此外，需具備一個非 root 的 sudo 使用者，且伺服器需執行較新版本的作業系統。此處指令以 Ubuntu 24.04 為基準，但除 apt 以外，並無內容僅限於 Ubuntu。

在介紹工具前，有兩點誠實的警告。首先，工具過多本身就是一種管理問題：每安裝一個 agent，就代表每台機器都多了一個需要修補的 daemon，因此新增工具的標準應是「這能取代我本週進行的手動工作」，而非「這看起來很有用」。其次，此處所有工具皆為自由軟體，真正的成本在於設定時間，因此每個工具都標註了預估分鐘數 — 若預估需要一個下午，請務必以此為準。

2 到 5 台伺服器：~/.ssh/config 是您手中最被低估的工具

取代對象： IP 位址清單、從 shell-history 考古（ssh 203.0 後按 Ctrl-R 並祈禱），以及永無止盡地輸入 -p 2222 -i ~/.ssh/other_key。設定成本： 僅需 15 分鐘。注意事項： 過時的 multiplexing sockets，詳見下文。

在此規模下，您不需要額外軟體；您只需要正確配置現有的 client。~/.ssh/config 能將每台伺服器轉換為單一單字名稱，並編寫路由規則，讓您無需再費神處理：

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h-%p
    ControlPersist 10m

Host bastion
    HostName 10.0.0.10
    User matt

Host web1
    HostName 10.8.0.11
    User matt
    ProxyJump bastion

Host db1
    HostName 10.8.0.12
    User matt
    Port 2222
    ProxyJump bastion

三個設定即可完成任務。ProxyJump 可透過 bastion 進行單跳 (one hop) 路由，因此從咖啡廳進行的 ssh db1 會透明地透過 bastion 建立隧道——無需 agent forwarding，也無需 ProxyCommand 咒語，且私有伺服器完全不需要開啟公網 SSH port（詳見後續章節）。ControlPersist 搭配 ControlMaster auto 可在單個 TCP session 上進行 multiplexing，因此第二次及之後的 ssh、scp 或 rsync 連線至同一主機時會立即連線，而非重新協商——當使用 Ansible 時，這種差異會非常顯著。由於 scp、rsync 與 Ansible 都讀取同一個檔案，您在此定義的所有名稱皆可於各處使用。

注意事項：master connection 可能會超出其用途壽命，且有兩種不同的失效模式。當伺服器重啟或 Wi-Fi 中斷時，master process 會持續持有一個尚未察覺已斷開的 dead TCP session，導致下一個 ssh web1 在無效的 socket 上靜默掛起。另外，sshd 會限制每個 connection 的 session 數量為 10（sshd_config 中的 MaxSessions），因此連向同一主機的第 11 個 multiplexed session 會顯示：

mux_client_request_session: session request failed: Session open refused

兩者的解決方案相同：ssh -O exit web1 會終止 master，下一次連線將啟動新的連線。您有時也可能看到 ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing——這是無害的：兩個 session 發生競爭，連線仍可運作，只是變成了 unmultiplexed 模式。

在此規模下的兩個輔助工具。在每台伺服器上使用 tmux 可取代 nohup、Wi-Fi 中斷導致的工作遺失，以及「我不能關上筆電，因為遷移正在執行」的困境。設定成本為 sudo apt install -y tmux，兩分鐘，外加 tmux new -s work 與 tmux attach -t work 的肌肉記憶。注意事項是巢狀 (nesting) 問題：在 tmux 內執行 tmux 會吞掉您的 prefix key，因此請在伺服器或筆電其中之一執行，不要兩者同時執行。如果您執行長時間運行的 agent sessions，此問題會更加嚴重——這與 在 VPS 的 tmux 中執行 Claude Code 的模式相同，session 必須比 SSH 連線更長久。

共用的 alias 檔案可取代在每台機器上重複輸入 12 個常用指令。將 .bash_aliases 存放在 git repo 中，並將其 pull 到每台伺服器。注意事項：如果您直接在某台伺服器上編輯檔案而非透過 repo，內容就會產生偏差——這也是您初步接觸為何需要更高階管理層級的原因。

5 到 20 台伺服器：使用 IaC，否則配置漂移將會發生

當伺服器數量超過五台時，「我直接在每台機器上操作就好」就不再是方法，而是一個自欺欺人的謊言。此階段的所有工具都在對抗同一個敵人：配置漂移 (drift)。

Ansible 取代了針對主機名稱的 shell 迴圈、過時的「新伺服器設定」Wiki 頁面，以及無法確認 web3 是否已套用修補程式的焦慮感。設定成本：在您的筆記型電腦或管理機上花 30 分鐘即可完成第一個可運行的 playbook —— sudo apt install -y ansible；伺服器端不需要安裝 agent，全部透過您已建立好的 SSH 設定執行（apt 提供較舊的 Ansible 版本，對此處需求已足夠；本教學的 pipx 路徑可取得最新版本）。這是本頁面中最重要的升級，完整指南請參閱 Ansible 第一個 playbook 教學；以下是使其運作的 inventory 結構：

[web]
web1 ansible_host=10.8.0.11
web2 ansible_host=10.8.0.12

[db]
db1 ansible_host=10.8.0.21 ansible_port=2222

[all:vars]
ansible_user=matt
ansible_ssh_common_args='-o ProxyJump=bastion'

由於 Ansible 是透過 OpenSSH 二進位檔執行，您在上一節寫的 ~/.ssh/config 已經適用 —— 僅包含 web1 等純名稱的 inventory 即可運作，無需任何變數。上述變數讓 inventory 具備自包含性，這在您從非筆記型電腦的機器執行時會發揮作用。

使用 ansible all -i inventory.ini -m ping 進行測試；正確結果會為每個 host 印出綠色的 "ping": "pong"。您首先會遇到的錯誤如下：

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: matt@10.8.0.11: Permission denied (publickey).",
    "unreachable": true
}

這不是 Ansible 的問題 —— 單純的 ssh matt@10.8.0.11 也會出現同樣錯誤。請務必先修復 SSH；Ansible 的穩定性取決於其底層層級。另一個注意事項：Ansible 在兩端都需要 Python，因此一個極簡的 image 可能會回答 /usr/bin/python3: not found —— 只要安裝一個 apt install python3，它就不會再困擾您。

unattended-upgrades 取代您親自為 N 台伺服器套用安全性修補程式。標準的 Ubuntu Server 24.04 已預裝此工具，且通常已針對安全性更新啟用，因此此處的工作是驗證而非安裝：

cat /etc/apt/apt.conf.d/20auto-upgrades

兩行指令都應以 "1" 結尾。某些極簡版或雲端 image 預設為關閉狀態，若您的環境是關閉的，sudo dpkg-reconfigure -plow unattended-upgrades 會重寫該檔案。設定成本：每台伺服器檢查兩分鐘，或使用一個 Ansible task 處理所有伺服器。注意事項：預設情況下它不會重新啟動，因此核心 (kernel) 的安全性更新在您手動操作前會處於半套用狀態 —— unattended-upgrades 專用指南 涵蓋了自動重新啟動、選擇修補對象以及閱讀日誌。

集中化監控 (Centralized monitoring) 取代了從客戶端得知服務中斷，這是史上最昂貴的監控方式。兩款工具及其適用時機：Uptime Kuma 回答「服務是否正常運作？」—— 提供 HTTP、TCP 與 ping 檢查並可發送任何警報，使用 Docker 部署僅需 10 分鐘；Zabbix 回答「服務是否即將崩潰？」—— 透過每台主機上的 agent 監控磁碟、記憶體與 CPU 趨勢 —— 實際設定大約需要一個下午。先從 Kuma 開始；當「運作中但效能下降」開始造成損失時，再加入 Zabbix。這兩者的共同注意事項是部署位置，這點非常重要，因此會出現在下方的錯誤說明章節。

Web 控制面板（僅在必要時使用） Webmin 取代了記憶 Ubuntu 檔案存放位置的需求；對於技能程度不一的團隊或一年僅操作兩次的伺服器，它確實非常有用；設定僅需 10 分鐘。注意事項是它是一個具備 root 等級權限的 Web 應用程式，且監聽於 port 10000，網路掃描工具會不斷搜尋它。如果您運行它，請將其綁定至 localhost 或 VPN 位址 —— 絕不要綁定到公用介面的 0.0.0.0。如果您是因為覺得 SSH 太慢才想使用控制面板，請先重新閱讀前一節；一旦配置完成，~/.ssh/config 加上 Ansible 會比任何控制面板都快。

20+ servers：本指南的實際邊界

當伺服器超過 20 台時，你正在管理一個集群，工具鏈的型態也會隨之改變：你需要使用 Terraform 或 OpenTofu 來實現伺服器本身的具備可重現性；使用 cloud-init 或 golden images 讓主機具備可拋棄性而非修復性；改用 pull-based configuration 或執行 Ansible 的 CI pipelines，因為從筆電進行 push 操作無法滿足擴展需求；此外還需要真正的 secrets management。Ansible 本身在 20 台時不會失效——許多企業對數百個節點執行 Ansible——但相關實務必須更加嚴謹，這與本網站的其他文章主題不同。如果你已達到該規模，下方的章節仍適用於你，因為 inventory、keys 與 access discipline 正是集群工具假設你已經具備的基礎。

沒人記錄的層次

無論規模大小，以下四項實踐皆適用。忽略這些實踐會導致伺服器數量增加時，管理負擔也隨之大幅增加。

一份清單檔案 —— 即使只是純文字檔。 當你擁有三台伺服器時，請記錄：名稱、IP、供應商、執行內容以及用途。將 servers.md 存放在 git repo 中即可；上述的 Ansible inventory 更好，因為它是可執行的文件。這能解決的問題：凌晨 2 點時問「等等，10.0.0.40 是什麼？」的困擾。設定成本：10 分鐘。注意事項：必須在建立伺服器的同時完成新增紀錄，不可將兩者分開執行。

關鍵維護：現在就進行輪換，痛定思痛後再導入 SSH CA。 列出所有金鑰存放位置（你端的 cat ~/.ssh/*.pub 與每台伺服器端的 ~/.ssh/authorized_keys）、移除舊筆電與離職員工的金鑰，並輪換所有過期且無法追蹤使用紀錄的金鑰。使用 SSH certificate authority（以短效簽章憑證取代靜態金鑰）是成熟的方案；但誠實的建議是，當伺服器少於 10 台時，透過 Ansible 進行嚴謹的 authorized_keys 管理，只需花費 10% 的繁瑣程度即可獲得 90% 的效益。

單一入口，而非二十個。 每個公開的 SSH port 都會使攻擊面乘以 N。可擴展的模式是：使用一台 bastion host —— 或更好的方案，是使用 你控制的 VPS 上的 WireGuard VPN —— 並將其他所有伺服器的 SSH 僅綁定於私有位址。上述 config 中的 ProxyJump 行已預設此結構。任何必須保持公開的服務，都應預設安裝 fail2ban。設定成本：一次性花費 1 小時。注意事項：在關閉所有地方的 port 22 之前，請務必先驗證備援方案（供應商的 console access）是否運作正常，而非事後才檢查。

透過還原來測試備份。 未經測試的備份僅是假設。無論你使用何種機制 —— 供應商的 snapshots、restic、或將 rsync 傳送到第二台機器 —— 真正關鍵的工具是你的行事曆紀錄，內容應包含：將一台伺服器還原至新的 VPS，並確認其能正常啟動並提供服務。在十五年的主機代管經驗中，我聽過的每個備份災難故事，都包含「我們原本是有備份的」這句話。

錯誤行為

多伺服器規模下的失敗模式並非工具問題，而是習慣問題。其中四種行為會導致幾乎所有的問題。

Snowflake servers（獨特伺服器）。 每台機器都是手動配置，細微差異導致無人能重新建置。這通常在磁碟故障時才會被發現。解決方法很簡單：所有變更都必須透過 Ansible 進行——或至少記錄在該伺服器的 inventory doc 區段中。任何在今天下午無法根據筆記重新建置的伺服器，都是無法掌控還款期限的技術債。

「暫時性」的防火牆規則。 為了 ufw allow 5432 進行除錯，結果十八個月後 Postgres 仍暴露在網際網路中。請在每台機器上使用 sudo ufw status numbered 進行稽核，或者直接使用 ansible all -i inventory.ini -a "ufw status numbered" --become 一次完成，並刪除任何無法說明目前用途的規則。如果規則確實是暫時的，請在關閉 tmux 視窗前，將對應的 ufw delete 記錄下來。

將監控程式部署在被監控的機器上。 如果 Uptime Kuma 運行在它所監控的伺服器上，當出現「所有服務皆已斷線」的警報時，該警報本身也會失效——這等於建立了一個縮小版且更滑稽的 世界上效率最低的資料中心。監控應位於不同的故障域（failure domain）：經典做法是使用不同供應商的廉價 VPS，或至少使用外部免費方案來監控監控程式。

處處使用 Root SSH。 在整個集群中使用同一個共享的 root key，代表只要一台筆電外洩，所有權限都會淪陷，且沒有稽核軌跡可以追蹤操作者。應在每台主機上使用個人使用者帳號、sudo 以及在 /etc/ssh/sshd_config 中的 PermitRootLogin no——這只需要三行 Ansible task，而非耗費整個晚上進行手動輸入。

當集群規模超過數台時，請使用 你的第一個 Ansible playbook 來自動化重複性工作。

FAQ

管理多台 Linux 伺服器的最佳免費工具為何？

若僅管理 2 至 5 台伺服器，寫得好的 ~/.ssh/config 搭配 tmux 優於任何安裝套件。若超過約 5 台，Ansible 是標準答案：它不需安裝 agent、完全免費、透過現有的 SSH 執行，並能將伺服器設定轉換為 git 中的檔案。若需主機狀態告警，請搭配 Uptime Kuma；本指南提到的所有工具皆為自由軟體。

我可以不使用 Ansible 來管理多台 Linux 伺服器嗎？

可以。在 5 台伺服器以下，良好的 SSH config、共用的 alias 檔案與嚴謹的操作習慣已足夠，許多人以此方式運作多年。超過此規模，Ansible 的替代方案並非「不使用工具」，而是「未記錄的配置漂移 (undocumented drift)」：即 18 台伺服器每台都經過不同的手動設定。若覺得 Ansible 太過繁重，可以從僅管理 authorized_keys 與 unattended-upgrades 的單一 playbook 開始；這項嘗試就足以抵銷學習成本。

我如何同時在多台 Linux 伺服器上執行相同的指令？

使用 ansible all -i inventory.ini -a "uptime" 是最簡潔的方案，不需要 playbook，只需一份 inventory 檔案。若需進行互動式同步操作，tmux 可透過 setw synchronize-panes on 將按鍵廣播至每個 pane；但請將此視為一種技巧，因為對生產環境伺服器進行互動式指令廣播，會讓單一打字錯誤導致 N 倍的停機事故。

我需要像 Webmin 這樣的控制面板來管理 Linux 伺服器嗎？

不需要。SSH 與 Ansible 的可重現性（reproducibility）優於控制面板。當不同技術層級的人員需管理同一台機器，或是您極少觸碰某台伺服器導致重新尋找設定路徑非常耗時時，Webmin 才具備價值。若您使用控制面板，請將其視為具備 root 權限的 Web App：請將其綁定至 localhost 或 VPN 位址，絕不要對外開放。

一個人實際可以管理多少台 Linux 伺服器？

若採用手動管理，品質會在 10 台以下下降。若採用配置即程式碼 (config as code)、自動化補丁與集中式監控，一名謹慎的管理員可以將 20 到 50 台伺服器視為兼職工作來經營——此時限制因素在於新問題發生的頻率，而非例行維護。關鍵指標並非每位管理員負責的伺服器數量，而是每位管理員面對的「特殊配置 (snowflakes)」數量：將其維持在接近零的程度，管理上限將非常高。