Linux-Server verwalten: Tools nach Serveranzahl

Was Sie aufbauen

Kein einzelnes Tool, sondern einen kurzen Stack, ausgewählt nach der tatsächlichen Anzahl Ihrer Server. Diese Zahl ist die einzige relevante Eingabe. Genau diese Zahl ignoriert jede Übersicht zu „Linux server management tools“. Der klassische Fehler besteht darin, eine Lösung für 200 Server auf vier VPS anzuwenden und einen Monat lang das Tool zu füttern, statt die Server zu verwalten. Der zweite klassische Fehler besteht darin, dass jemand mit 18 Servern weiterhin jeden Server einzeln per SSH verwaltet und „dieselbe“ Änderung auf 18 leicht unterschiedliche Arten durchführt.

Deshalb ist dieser Leitfaden nach der Größe der Serverflotte gegliedert: 2 bis 5 Server, 5 bis 20 Server und mehr als 20 Server. Hinzu kommt eine übergreifende Ebene, die für jede Größe gilt und die niemand dokumentiert: ein Inventar, eine saubere Schlüsselverwaltung, ein einheitlicher Zugangsweg und Backups, die Sie tatsächlich wiederhergestellt haben. Für jedes Tool erhalten Sie drei Informationen: was es ersetzt, wie viele Minuten die Einrichtung kostet und welcher konkrete Stolperstein in der Praxis Probleme verursacht. Ich betreibe seit 15 Jahren einen VPS-Host. Die folgende Liste basiert auf dem, was einen Ausfall um 2 Uhr morgens übersteht, und nicht auf dem, was sich in einer Demo gut präsentiert.

Voraussetzungen und wichtige Einschränkungen

Sie benötigen bereits eine funktionierende SSH-Authentifizierung per Schlüssel für jeden Server. Wenn Sie noch Passwörter eingeben, beheben Sie das zuerst. Das dauert zehn Minuten, und alle folgenden Schritte setzen Schlüssel voraus. Außerdem benötigen Sie einen sudo-Benutzer, der nicht root ist, sowie Server mit aktueller Software. Die Befehle in diesem Abschnitt setzen Ubuntu 24.04 voraus. Die einzige Ubuntu-spezifische Ausnahme ist apt.

Vor den Tools zwei wichtige Hinweise. Erstens ist eine zu große Zahl an Tools selbst ein Verwaltungsproblem: Jeder installierte Agent ist ein weiterer Daemon, der auf jedem System gepatcht werden muss. Die Hürde für die Installation sollte daher sein: „Er ersetzt manuelle Arbeit, die ich diese Woche erledigt habe“, nicht: „Er sieht nützlich aus.“ Zweitens ist alles hier freie Software. Die tatsächlichen Kosten entstehen durch die Einrichtungszeit. Deshalb enthält jedes Tool eine Schätzung in Minuten. Wenn die Schätzung einen Nachmittag angibt, sollten Sie damit rechnen.

2 bis 5 Server: ~/.ssh/config ist das am meisten unterschätzte Tool, das Sie bereits haben

Was es ersetzt: die Textdatei mit IP-Adressen, die Archäologie in der Shell-History (ssh 203.0, dann Ctrl-R drücken und hoffen) sowie das endlose Eingeben von -p 2222 -i ~/.ssh/other_key. Einrichtungsaufwand: 15 Minuten, einmalig. Der Haken: veraltete Multiplexing-Sockets, die weiter unten behandelt werden.

In dieser Größenordnung benötigen Sie keine zusätzliche Software. Sie müssen nur den bereits vorhandenen Client passend konfigurieren. ~/.ssh/config macht aus jedem Server einen Namen aus einem Wort und hinterlegt das Routing, sodass Sie sich nie wieder darum kümmern müssen:

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

Drei Einstellungen erledigen die Arbeit. ProxyJump leitet Verbindungen in einem Sprung über einen Bastion-Host, sodass ssh db1 aus einem Café transparent durch bastion getunnelt wird. Dafür sind weder Agent-Forwarding noch ProxyCommand-Befehle erforderlich, und die privaten Server benötigen überhaupt keine öffentlichen SSH-Ports (mehr dazu im übergreifenden Abschnitt). ControlMaster auto mit ControlPersist multiplexed Verbindungen über eine TCP-Sitzung. Dadurch verbindet sich die zweite und jede weitere ssh-, scp- oder rsync-Verbindung zum selben Host sofort, statt die Verbindung neu auszuhandeln. Der Unterschied wird besonders deutlich, sobald Ansible zum Einsatz kommt. Da scp, rsync und Ansible dieselbe Datei einlesen, funktioniert jeder hier definierte Name überall.

Der Haken: Die Master-Verbindung kann länger bestehen bleiben, als sie noch verwendet werden kann. Die beiden Fehlerbilder unterscheiden sich. Wenn der Server neu startet oder die WLAN-Verbindung abbricht, hält der Master-Prozess weiterhin eine inzwischen unterbrochene TCP-Sitzung. Er hat den Abbruch noch nicht erkannt. Die nächste ssh web1-Verbindung wartet dann still auf einem Socket, der ins Leere führt. Separat begrenzt sshd die Anzahl der Sitzungen pro Verbindung auf 10 (MaxSessions in sshd_config). Die elfte multiplexed Sitzung zu einem Host gibt Folgendes aus:

mux_client_request_session: session request failed: Session open refused by peer

Beide Probleme lassen sich gleich beheben: ssh -O exit web1 beendet den Master. Die nächste Verbindung startet einen neuen Master. Gelegentlich sehen Sie außerdem ControlSocket /home/matt/.ssh/cm-matt@10.8.0.11-22 already exists, disabling multiplexing. Das ist unkritisch: Zwei Sitzungen wurden gleichzeitig gestartet, und die Verbindung funktioniert weiterhin, nur ohne Multiplexing.

Zwei weitere Werkzeuge sind in dieser Größenordnung hilfreich. tmux auf jedem Server ersetzt nohup, verhindert den Verlust laufender Arbeit bei einem WLAN-Abbruch und erspart Ihnen die Situation: „Ich kann meinen Laptop nicht schließen, eine Migration läuft.“ Einrichtungsaufwand: sudo apt install -y tmux, zwei Minuten, zuzüglich der Gewöhnung an tmux new -s work und tmux attach -t work. Der Haken ist die Verschachtelung: tmux innerhalb von tmux fängt Ihre Prefix-Taste ab. Starten Sie tmux deshalb auf dem Server oder auf dem Laptop, nicht auf beiden. Wenn Sie langlebige Agent-Sitzungen ausführen, ist das besonders wichtig. Es handelt sich um dasselbe Muster wie bei Claude Code in tmux auf einem VPS ausführen, bei dem die Sitzung die SSH-Verbindung überdauern muss.

Eine gemeinsame Alias-Datei erspart Ihnen, Ihre zwölf bevorzugten Einzeiler auf jedem System erneut einzugeben. Legen Sie ein .bash_aliases in einem git-Repository ab und holen Sie es auf jeden Server. Der Haken: Die Datei läuft auseinander, sobald Sie sie direkt auf einem Server statt im Repository bearbeiten. Das ist zugleich Ihr erster Eindruck davon, warum die nächste Stufe existiert.

5 bis 20 Server: Konfiguration als Code, oder Drift gewinnt

Ab mehr als fünf Servern ist „Ich richte es einfach auf jeder Maschine ein“ keine Methode mehr, sondern eine Selbsttäuschung. Alle Werkzeuge in dieser Größenordnung bekämpfen denselben Gegner: Drift.

Ansible ersetzt die Shell-Schleife über Hostnamen, die Wiki-Seite mit dem Titel „neue Servereinrichtung“, die seit drei Schritten veraltet ist, und die Unsicherheit, ob web3 die Korrektur tatsächlich erhalten hat. Einrichtungsaufwand: 30 Minuten bis zum ersten funktionierenden Playbook, sudo apt install -y ansible auf Ihrem Laptop oder einer Management-Maschine (apt liefert eine ältere Ansible-Version, die für alles hier ausreicht; der im Tutorial beschriebene pipx-Weg installiert aktuelle Versionen), keine Agents auf den Servern und die gesamte Kommunikation über die SSH-Konfiguration, die Sie bereits erstellt haben. Das ist die größte einzelne Verbesserung auf dieser Seite. Die vollständige Anleitung finden Sie im Tutorial zum ersten Ansible-Playbook; so sieht das Inventory aus, mit dem es funktioniert:

[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'

Da Ansible die OpenSSH-Binärdatei aufruft, gilt die im letzten Abschnitt erstellte ~/.ssh/config bereits. Ein Inventory mit einfachen Namen wie web1 würde ganz ohne Variablen funktionieren. Die Variablen oben machen das Inventory stattdessen in sich geschlossen. Das zahlt sich aus, sobald Sie es von einer Maschine ausführen, die nicht Ihr Laptop ist.

Testen Sie es mit ansible all -i inventory.ini -m ping. Ein korrektes Ergebnis gibt für jeden Host "ping": "pong" in grüner Farbe aus. Der erste Fehler sieht wahrscheinlich so aus:

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

Das ist kein Ansible-Problem. Das einfache ssh matt@10.8.0.11 schlägt auf dieselbe Weise fehl. Beheben Sie immer zuerst SSH. Ansible ist nur so zuverlässig wie die darunterliegende Schicht. Der einzige zusätzliche Stolperstein: Ansible benötigt Python auf Ihrer Maschine und bei fast jedem Modul, einschließlich ping, auch auf dem Server. Ein wirklich minimales Image kann daher mit /usr/bin/python3: not found antworten. Ein apt install python3 behebt das dauerhaft. Bei einer ganzen Flotte aus Images ohne Python kann das Modul raw, eines der wenigen Module ohne Python-Anforderung auf dem entfernten System, die Installation für Sie ausführen.

unattended-upgrades übernimmt das Anwenden von Sicherheitsupdates auf N Servern für Sie. Ubuntu Server 24.04 wird standardmäßig mit vorinstalliertem unattended-upgrades ausgeliefert und ist für Sicherheitsupdates normalerweise bereits aktiviert. Hier müssen Sie daher nur prüfen, nicht installieren:

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

Beide Zeilen sollten mit "1" enden. Einige minimale und Cloud-Images liefern es deaktiviert aus. sudo dpkg-reconfigure -plow unattended-upgrades schreibt diese Datei neu, falls das bei Ihnen der Fall ist. Einrichtungsaufwand: zwei Minuten zur Prüfung pro Server oder eine Ansible-Aufgabe für alle Server. Der wichtige Punkt: Standardmäßig führt unattended-upgrades keinen Neustart durch. Sicherheitsupdates für den Kernel bleiben daher unvollständig angewendet, bis Sie den Neustart ausführen. Die ausführliche Anleitung zu unattended-upgrades behandelt automatische Neustarts, die Auswahl der zu installierenden Updates und das Lesen der Logs.

Zentralisiertes Monitoring ersetzt die Information durch einen Kunden. Das ist das teuerste je entwickelte Monitoring-System. Zwei Werkzeuge, jeweils mit einer kurzen Angabe zum Einsatz: Uptime Kuma beantwortet die Frage „Ist der Dienst erreichbar?“. Es prüft HTTP, TCP und Ping, sendet Benachrichtigungen an beliebige Ziele und ist in Docker in zehn Minuten eingerichtet. Zabbix beantwortet die Frage „Droht ein Ausfall?“. Es erfasst Trends für Festplatten, Arbeitsspeicher und CPU über einen Agent auf jedem Host. Die Einrichtung dauert realistisch einen Nachmittag. Beginnen Sie mit Kuma. Fügen Sie Zabbix hinzu, sobald „erreichbar, aber beeinträchtigt“ Kosten verursacht. Bei beiden ist die Platzierung der entscheidende Punkt. Deshalb wird sie im folgenden Abschnitt zu den Fehlern behandelt.

Ein Webpanel, nur wenn es erforderlich ist. Webmin erspart Ihnen die Suche nach den Stellen, an denen Ubuntu seine Einstellungen ablegt. Für ein Team mit unterschiedlichen Kenntnissen oder einen Server, den Sie zweimal pro Jahr verwalten, ist es tatsächlich nützlich. Die Einrichtung dauert zehn Minuten. Der wichtige Punkt: Webmin ist eine Webanwendung mit root-gleichen Rechten, die auf Port 10000 lauscht. Das Internet scannt ständig nach diesem Port. Wenn Sie Webmin einsetzen, binden Sie es an localhost oder eine VPN-Adresse. Binden Sie es niemals an 0.0.0.0 auf einer öffentlichen Schnittstelle. Wenn Sie zu einem Panel greifen, weil sich SSH langsam anfühlt, lesen Sie zuerst den vorherigen Abschnitt erneut. ~/.ssh/config zusammen mit Ansible ist nach der Konfiguration schneller als jedes Panel.

20+ Server: Wo dieser Leitfaden ehrlich endet

Ab mehr als 20 Servern verwalten Sie eine Flotte, und die Toolchain verändert sich: Terraform oder OpenTofu, damit die Server selbst reproduzierbar sind; cloud-init oder Golden Images, damit ein System verworfen statt repariert werden kann; Pull-basierte Konfiguration oder CI-Pipelines, die Ihr Ansible ausführen, weil Push von einem Laptop nicht mehr skaliert; sowie ein professionelles Secrets Management. Ansible selbst versagt nicht ab 20 Servern. Viele Unternehmen setzen es für Hunderte Nodes ein. Die Praktiken rund um Ansible müssen jedoch robuster werden. Das ist ein anderes Thema als die Artikel, die auf dieser Website behandelt werden. Wenn Sie diese Größenordnung erreicht haben, ist der folgende Abschnitt trotzdem für Sie relevant, denn Inventory, Schlüssel und ein disziplinierter Zugriff sind genau die Voraussetzungen, von denen Flotten-Tools ausgehen.

Die nicht dokumentierte Ebene

Vier Maßnahmen gelten unabhängig von der Flottengröße. Wenn sie fehlen, wirkt die Verwaltung von Servern aufwendiger, als sie tatsächlich ist.

Eine Inventardatei, notfalls als Textdatei. Sobald Sie drei Server haben, sollten Sie Folgendes dokumentieren: Name, IP-Adresse, Provider, die darauf ausgeführten Dienste und den Zweck des Servers. Eine servers.md in einem git-Repository reicht aus. Das obige Ansible-Inventar ist jedoch besser, weil es ausführbare Dokumentation ist. Es ersetzt die Frage um 2 Uhr morgens: „Moment, was ist 10.0.0.40?“ Einrichtungsaufwand: zehn Minuten. Der wichtige Punkt: Das funktioniert nur, wenn das Erstellen eines Servers und das Hinzufügen der Zeile denselben Vorgang bilden, niemals zwei getrennte Vorgänge.

Schlüsselverwaltung: jetzt rotieren, bei Bedarf eine SSH-CA. Ermitteln Sie, wo Ihre Schlüssel liegen (cat ~/.ssh/*.pub auf Ihrer Seite, ~/.ssh/authorized_keys auf der Seite jedes Servers). Entfernen Sie ehemalige Laptops und ehemalige Kollegen. Rotieren Sie alle Schlüssel, die so alt sind, dass Sie nicht mehr sagen können, wo sie verwendet wurden. Eine SSH-Zertifizierungsstelle mit kurzlebigen signierten Zertifikaten anstelle statischer Schlüssel ist die professionelle Lösung. Die realistische Empfehlung lautet jedoch: Bei weniger als zehn Servern bietet eine disziplinierte authorized_keys-Verwaltung über Ansible 90% des Nutzens bei 10% des Verwaltungsaufwands.

Ein Zugangsweg statt zwanzig. Jeder öffentlich erreichbare SSH-Port vergrößert die Angriffsfläche, multipliziert mit N. Das skalierbare Muster besteht aus einem Bastion Host oder, besser, einem WireGuard-VPN auf einem VPS unter Ihrer Kontrolle. Binden Sie SSH auf allen anderen Servern ausschließlich an deren private Adresse. Die ProxyJump-Zeilen in der obigen Konfiguration setzen dieses Muster bereits voraus. Alles, was öffentlich erreichbar bleiben muss, sollte grundsätzlich mit fail2ban geschützt werden. Einrichtungsaufwand: einmalig eine Stunde. Der wichtige Punkt: Prüfen Sie, ob Ihr Fallback funktioniert, also der Konsolenzugriff des Providers, bevor Sie Port 22 überall schließen, nicht danach.

Backups durch Wiederherstellung testen. Ein nicht getestetes Backup ist nur eine Annahme. Unabhängig davon, welchen Mechanismus Sie verwenden, Provider-Snapshots, restic oder rsync auf einen zweiten Server: Entscheidend ist der Kalendereintrag, an dem Sie einen Server auf einem neuen VPS wiederherstellen und prüfen, ob er bootet und Dienste bereitstellt. Jede Geschichte über einen fehlgeschlagenen Restore, die ich in fünfzehn Jahren Hosting gehört habe, enthält den Satz: „Wir hatten Backups.“

Die Fehler

Die Fehlerquellen bei mehreren Servern sind keine Fehler der Werkzeuge, sondern schlechte Gewohnheiten. Vier davon erklären fast alle Probleme.

Schneeflockenserver. Jeder Server wurde manuell konfiguriert, unterscheidet sich geringfügig von den anderen, und niemand kann ihn neu aufbauen. Das fällt bei einem Festplattenausfall auf. Die Lösung ist unspektakulär: Jede Änderung läuft über Ansible oder wird zumindest im Abschnitt dieses Servers im Inventardokument ergänzt. Jeder Server, den Sie heute Nachmittag nicht anhand Ihrer Notizen neu aufbauen könnten, ist technische Schuld mit einem Fälligkeitsdatum, das Sie nicht selbst bestimmen.

„Temporäre“ Firewall-Lücken. ufw allow 5432, um etwas zu untersuchen, und achtzehn Monate später ist Postgres immer noch aus dem Internet erreichbar. Prüfen Sie jeden Server mit sudo ufw status numbered oder alle Server in einem Schritt mit ansible all -i inventory.ini -a "ufw status numbered" --become. Löschen Sie alle Regeln, für die Sie keinen aktuellen Grund nennen können. Wenn eine Regel tatsächlich temporär ist, führen Sie den passenden ufw delete im selben tmux-Fenster aus, bevor Sie es schließen.

Monitoring auf einem überwachten Server. Wenn Uptime Kuma auf dem Server läuft, den es überwacht, ist auch der Alarm „alles ist ausgefallen“ ausgefallen. Damit haben Sie eine kleinere und amüsantere Version von dem ineffizientesten Rechenzentrum der Welt gebaut. Das Monitoring muss in einer anderen Ausfallzone liegen. Ein günstiger VPS bei einem anderen Anbieter ist die klassische Lösung. Mindestens sollte eine externe Prüfung aus einem kostenlosen Tarif den Monitoring-Dienst überwachen.

Root-SSH überall. Ein gemeinsamer Root-Schlüssel für die gesamte Serverflotte bedeutet, dass ein einziges abhandengekommenes Notebook Zugriff auf alles ermöglicht. Außerdem gibt es keine Protokollspur, aus der hervorgeht, wer was getan hat. Verwenden Sie Benutzerkonten pro Person, sudo und PermitRootLogin no in /etc/ssh/sshd_config auf jedem Host. Auch das ist wieder eine dreizeilige Ansible-Aufgabe statt eines Abends voller manueller Eingaben.

Wenn die Serverflotte über eine Handvoll Server hinauswächst, automatisiert Ihr erstes Ansible-Playbook die wiederkehrenden Aufgaben.

FAQ

Was ist das beste kostenlose Tool zur Verwaltung mehrerer Linux-Server?

Für 2 bis 5 Server ist ein gut geschriebener ~/.ssh/config zusammen mit tmux besser als alles, was Sie installieren könnten. Ab ungefähr fünf Servern ist Ansible die Standardantwort: agentenlos, kostenlos, verwendet das bereits vorhandene SSH und macht aus der Servereinrichtung Dateien in git. Ergänzen Sie Uptime Kuma für Up/Down-Warnungen. Alle in diesem Leitfaden genannten Tools sind freie Software.

Kann ich mehrere Linux-Server ohne Ansible verwalten?

Ja. Bei weniger als ungefähr fünf Servern reichen eine gute SSH-Konfiguration, eine gemeinsam verwendete Alias-Datei und Disziplin aus. Viele Administratoren arbeiten jahrelang auf diese Weise. Bei mehr Servern ist die Alternative zu Ansible nicht „nichts“, sondern undokumentierte Abweichung: achtzehn Server, die jeweils von Hand etwas anders konfiguriert wurden. Wenn Ansible zu umfangreich wirkt, beginnen Sie mit einem Playbook, das nur authorized_keys und unattended-upgrades verwaltet. Das allein rechtfertigt bereits den Lernaufwand.

Wie führe ich denselben Befehl gleichzeitig auf mehreren Linux-Servern aus?

ansible all -i inventory.ini -a "uptime" ist die saubere Lösung und benötigt keine Playbooks, sondern nur die Inventory-Datei. Für interaktive Arbeiten nebeneinander kann tmux mit setw synchronize-panes on Tastatureingaben an jedes Pane übertragen. Betrachten Sie das jedoch als Spielerei. Das Übertragen interaktiver Befehle an Produktivserver führt schnell dazu, dass aus einem Tippfehler ein Ausfall mit dem Faktor N wird.

Benötige ich ein Control Panel wie Webmin zur Verwaltung von Linux-Servern?

Nein. Alles, was ein Panel erledigt, können SSH und Ansible reproduzierbarer erledigen. Webmin ist sinnvoll, wenn Personen mit unterschiedlichen Kenntnisständen dieselben Server verwalten oder wenn Sie einen Server so selten bearbeiten, dass das erneute Auffinden von Konfigurationspfaden spürbar Zeit kostet. Wenn Sie Webmin einsetzen, behandeln Sie es wie die Root-Webanwendung, die es ist: Binden Sie es an localhost oder eine VPN-Adresse, niemals an eine öffentliche Schnittstelle.

Wie viele Linux-Server kann eine Person realistisch verwalten?

Bei manueller Verwaltung sinkt die Qualität irgendwann bei weniger als zehn Servern. Mit Konfiguration als Code, automatischer Patch-Installation und zentralem Monitoring kann eine sorgfältige Person 20 bis 50 Server als Teilzeitaufgabe betreiben. Die Einschränkung ist dann nicht die routinemäßige Pflege, sondern wie häufig etwas Unbekanntes ausfällt. Entscheidend ist nicht die Anzahl der Server pro Administrator, sondern die Anzahl der individuell abweichenden Server pro Administrator. Halten Sie diese Zahl nahe bei null, ist die Obergrenze hoch.