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) und das ständige Eingeben von -p 2222 -i ~/.ssh/other_key. Einrichtungsaufwand: 15 Minuten, einmalig. Der Haken: veraltete Multiplexing-Sockets, wie weiter unten beschrieben.

Bei dieser Größe 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 Schritt über einen Bastion-Host weiter. Dadurch tunnelt ssh db1 aus einem Café transparent über bastion, ohne Agent-Forwarding, ohne ProxyCommand-Befehle. Die privaten Server benötigen überhaupt keine öffentlichen SSH-Ports (mehr dazu im übergreifenden Abschnitt). ControlMaster auto verwendet zusammen mit ControlPersist eine TCP-Sitzung für mehrere Verbindungen. Dadurch wird die zweite und jede weitere ssh-, scp- oder rsync-Verbindung zum selben Host sofort hergestellt, statt die Aushandlung erneut durchzuführen. Mit Ansible wird dieser Unterschied besonders deutlich. Da scp, rsync und Ansible dieselbe Datei einlesen, funktioniert jeder hier definierte Name überall.

Der Haken: Die Master-Verbindung kann weiterlaufen, obwohl sie nicht mehr verwendbar ist. Die beiden Fehlerbilder sehen unterschiedlich aus. Wenn der Server neu startet oder die WLAN-Verbindung abbricht, hält der Master-Prozess weiterhin eine tote TCP-Sitzung. Er hat den Abbruch noch nicht erkannt. Die nächste ssh web1-Verbindung hängt dann still an einem Socket, der ins Leere führt. Unabhängig davon begrenzt sshd die Anzahl der Sitzungen pro Verbindung auf 10 (MaxSessions in sshd_config). Die elfte Multiplexing-Sitzung zu einem Host gibt Folgendes aus:

mux_client_request_session: session request failed: Session open refused

Beide Fälle lassen sich gleich beheben: ssh -O exit web1 beendet den Master-Prozess. Die nächste Verbindung startet dann eine neue Master-Verbindung. Gelegentlich sehen Sie auch ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing. Das ist harmlos: Zwei Sitzungen wurden gleichzeitig gestartet. Die Verbindung funktioniert weiterhin, aber ohne Multiplexing.

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

Eine gemeinsame Alias-Datei erspart Ihnen, Ihre zwölf bevorzugten Einzeiler auf jedem System erneut einzugeben. Legen Sie eine .bash_aliases in einem git-Repository ab und übernehmen Sie sie auf jeden Server. Der Haken: Die Datei weicht sofort ab, wenn Sie sie direkt auf einem Server statt im Repository bearbeiten. Das vermittelt Ihnen auch den ersten Eindruck davon, warum die nächste Stufe erforderlich ist.

5 bis 20 Server: Konfiguration als Code oder die Konfigurationsabweichung setzt sich durch

Ab mehr als fünf Servern ist „Ich mache das einfach auf jedem System“ keine Methode mehr, sondern eine Selbsttäuschung. Die Werkzeuge in dieser Größenordnung bekämpfen alle denselben Gegner: Konfigurationsabweichungen.

Ansible ersetzt die Shell-Schleife über Hostnamen, die Wiki-Seite mit dem Titel „neuen Server einrichten“, die drei Schritte 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 einem Management-System (apt liefert eine ältere Ansible-Version, die für alle hier beschriebenen Aufgaben ausreicht; der im Tutorial beschriebene pipx-Weg installiert aktuelle Versionen), keine Agents auf den Servern und alles über die bereits eingerichtete SSH-Konfiguration. 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 dafür geeignete Inventory aus:

[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 verwendet, gilt die im letzten Abschnitt erstellte ~/.ssh/config bereits. Ein Inventory mit einfachen Namen wie web1 würde ohne Variablen funktionieren. Die Variablen oben machen das Inventory stattdessen in sich geschlossen. Das ist besonders nützlich, wenn Sie es später von einem anderen System als Ihrem Laptop aus ausführen.

Testen Sie es mit ansible all -i inventory.ini -m ping. Bei einem korrekten Ergebnis wird für jeden Host "ping": "pong" in grüner Farbe ausgegeben. Der erste Fehler, auf den Sie wahrscheinlich stoßen, sieht 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 aus demselben Grund fehl. Beheben Sie zuerst immer SSH. Ansible ist nur so zuverlässig wie die darunterliegende Schicht. Der einzige weitere typische Stolperstein: Ansible benötigt auf beiden Seiten Python. Ein wirklich minimales Image kann daher mit /usr/bin/python3: not found antworten. Installieren Sie einmal apt install python3, danach tritt das Problem nicht mehr auf.

unattended-upgrades ersetzt Sie als die Person, die Sicherheitsupdates auf N Servern einspielt. Ubuntu Server 24.04 enthält es standardmäßig bereits und hat es normalerweise schon für Sicherheitsupdates aktiviert. Ihre Aufgabe besteht daher darin, die Konfiguration zu prüfen, nicht das Paket zu installieren:

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

Beide Zeilen sollten mit "1" enden. Einige minimale und Cloud-Images liefern das Paket deaktiviert aus. Mit sudo dpkg-reconfigure -plow unattended-upgrades können Sie die Datei bei Bedarf neu schreiben. Einrichtungsaufwand: zwei Minuten zur Prüfung pro Server oder eine Ansible-Aufgabe für alle Server. Der wichtige Punkt: Standardmäßig führt das Werkzeug keinen Reboot durch. Sicherheitsupdates für den Kernel bleiben daher teilweise angewendet, bis Sie den Server neu starten. Die separate Anleitung zu unattended-upgrades behandelt automatische Reboots, die Auswahl der zu installierenden Updates und die Auswertung der Logs.

Zentrale Überwachung ersetzt die Information durch einen Kunden. Das ist das teuerste Überwachungssystem, das je entwickelt wurde. Zwei Werkzeuge, jeweils eine Zeile zum richtigen Einsatz: Uptime Kuma beantwortet die Frage „Ist der Dienst verfügbar?“. Es prüft HTTP, TCP und Ping, sendet Alarme 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 und benötigt realistisch einen Nachmittag für die Einrichtung. Beginnen Sie mit Kuma. Fügen Sie Zabbix hinzu, sobald „verfügbar, aber beeinträchtigt“ Kosten verursacht. Bei beiden Werkzeugen ist der Bereitstellungsort der entscheidende Punkt. Deshalb wird er im folgenden Abschnitt zu den typischen Fehlern behandelt.

Ein Webpanel nur bei echtem Bedarf. Webmin erspart Ihnen die Suche nach den Stellen, an denen Ubuntu seine Konfiguration ablegt. Für ein Team mit unterschiedlichen Kenntnissen oder einen Server, den Sie nur zweimal pro Jahr verwalten, ist es tatsächlich nützlich. Die Einrichtung dauert zehn Minuten. Der entscheidende Punkt: Webmin ist eine Webanwendung mit Root-Rechten und lauscht auf Port 10000. Das Internet scannt diesen Port ständig. Wenn Sie Webmin einsetzen, binden Sie es an localhost oder an eine VPN-Adresse, 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.