Swap Datei unter Linux erstellen und SSH absichern: Wie geht das?

Was ist eine Swap Datei und wozu braucht ein Linux Server sie?

Eine Swap Datei ist eine gewöhnliche Datei auf der Festplatte, in die der Linux Kernel selten genutzte Speicherseiten auslagert, sobald der Arbeitsspeicher knapp ist. Sie ersetzt keinen RAM. Stattdessen fängt sie kurze Lastspitzen ab, damit der Kernel nicht wegen Speichermangel einen Prozess beendet.

Dieser Leitfaden behandelt zwei Aufgaben, die meist in der ersten Stunde auf einem neuen VPS anstehen. Zunächst richten wir eine Swap Datei Schritt für Schritt ein. Danach sichern wir den SSH Zugang ab: mit Schlüsseln, einer begrenzten Benutzerliste und einer Konfiguration, die Sie vor dem Neustart testen.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hosting Anbieter. Deshalb stützen sich alle Befehle und Einstellungen auf Primärquellen: die Handbuchseite von swapon, die Dokumentation des Linux Kernels und das OpenSSH Handbuch. Weicht Ihre Distribution ab, vergleichen Sie jeden Schritt mit deren offizieller Dokumentation.

Kann Swap den Arbeitsspeicher ersetzen?

Nein. Selbst eine schnelle NVMe SSD arbeitet deutlich langsamer als RAM. Daher bremst ein Server, der ständig auslagert, spürbar ab: Seiten laden langsamer, und Datenbankabfragen stauen sich.

Die eigentliche Aufgabe von Swap ist ein Sicherheitspuffer. Zum Beispiel kann ein nächtliches Backup oder ein kurzer Besucheransturm den Speicher für einige Minuten überlasten. Ohne Swap beendet der Kernel bei Speichermangel einen Prozess, und das trifft oft die Datenbank, weil sie am meisten Speicher belegt. Mit Swap läuft der Server langsamer, bleibt aber erreichbar.

Außerdem kann der Kernel ungenutzte Seiten auslagern und so mehr Platz für den Dateicache schaffen. Somit bleiben häufig gelesene Dateien länger im Speicher. Allerdings gleicht dieser kleine Vorteil echten RAM Mangel nicht aus.

Kurz gesagt: Swap ist wie ein Notrad. Es bringt Sie nach Hause, aber Sie fahren damit nicht jeden Tag. Lagert Ihre Website dauerhaft aus, liegt die echte Lösung in mehr RAM oder einer schlankeren Anwendung. Typische Ursachen beschreibt unser Beitrag warum eine Website langsam ist.

Wie prüfen Sie, ob Ihr Server bereits Swap hat?

Beginnen Sie mit einem Blick auf den aktuellen Zustand. Manche VPS Images bringen schon eine Swap Datei mit, andere haben gar keine. Drei Befehle genügen:

swapon --show
free -h
cat /proc/swaps

Der erste Befehl listet aktive Swapbereiche mit Typ und Größe. Bleibt die Ausgabe leer, hat das System keinen aktiven Swap. Der zweite zeigt dann RAM und Swap in lesbaren Einheiten. Der dritte liest den Eintrag des Kernels direkt, also die Quelle der beiden anderen.

Danach achten Sie auf den Verlauf. Dauerhaft hohe Swapnutzung bei niedrigem Wert in der Spalte „available“ bedeutet Speicherdruck. Andererseits ist eine stabile Nutzung von einigen hundert Megabyte für sich genommen kein Problem. Der Kernel hat dann vermutlich nur ungenutzte Seiten ausgelagert.

Prüfen Sie zudem den freien Plattenplatz, denn eine Swap Datei belegt Speicher auf der Festplatte. Der Befehl df -h / zeigt den freien Platz im Wurzeldateisystem. Ist die Platte fast voll, räumen Sie zuerst auf.

Wie groß sollte die Swap Datei sein?

Eine allgemeingültige Zahl gibt es also nicht. Die passende Größe hängt vom RAM, von der Last und davon ab, ob Sie den Ruhezustand (Hibernation) nutzen. Server nutzen den Ruhezustand praktisch nie; deshalb passen Faustregeln vom Desktop nur bedingt.

Distributionen veröffentlichen eigene Empfehlungen und passen sie mit der Zeit an. Konkret enthält etwa die Dokumentation zu Red Hat Enterprise Linux 9 eine Tabelle nach RAM Größe. Daher empfehlen wir, die Zahl aus der aktuellen offiziellen Dokumentation Ihrer Distribution zu nehmen, nicht aus einem Blogartikel.

Trotzdem helfen Ihnen diese Fragen bei der Entscheidung:

• Schwankt der Speicherbedarf Ihrer Anwendung stark, oder bleibt er konstant?
• Läuft die Datenbank auf demselben Server, und wie viel Speicher hat sie?
• Wie viel freien Plattenplatz können Sie für Swap abzweigen?
• Begrenzt Ihr Anbieter Schreibzugriffe oder IOPS?

Auf einem kleinen VPS fahren Sie besser, wenn Sie mit einer moderaten Größe starten und free -h einige Tage beobachten. Genau das ist der Vorteil einer Swap Datei: Sie ändern die Größe später ohne großen Aufwand.

Swap Datei oder Swap Partition: Was passt besser?

Linux unterstützt beides. Eine Swap Partition ist ein eigener Bereich auf der Platte, eine Swap Datei dagegen eine normale Datei in einem bestehenden Dateisystem. Auf einem VPS lassen sich Partitionen nachträglich nur mühsam ändern, also ist die Datei meist die praktischere Wahl.

Bei aktuellen Kerneln entscheidet die Leistung für die meisten Anwendungen nicht zwischen beiden. Vielmehr zählt die Flexibilität. Die folgenden Schritte gelten für eine Swap Datei.

Wie erstellen Sie eine Swap Datei Schritt für Schritt?

Das Anlegen einer Swap Datei umfasst vier Schritte: Datei reservieren, Rechte einschränken, Swapsignatur schreiben und aktivieren. Das Beispiel unten erzeugt eine Datei mit 2 GB. Passen Sie die Größe an Ihre Entscheidung an; es handelt sich um einen Beispielwert, keine Empfehlung.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Die erste Zeile reserviert 2 GB auf der Platte. Die zweite erlaubt nur root das Lesen und Schreiben. Das ist wichtig, denn Swap enthält Daten aus dem Arbeitsspeicher, die andere Benutzer nie lesen dürfen.

Danach schreibt die dritte Zeile die Swapsignatur. Mit der vierten aktivieren Sie den Bereich sofort. Schließlich bestätigt der letzte Befehl das Ergebnis; in der Ausgabe sollte eine Zeile mit /swapfile stehen.

Jetzt läuft Swap, allerdings nur bis zum nächsten Neustart. Für einen dauerhaften Betrieb folgt im nächsten Abschnitt der Eintrag in fstab. Außerdem funktioniert fallocate nicht auf jedem Dateisystem reibungslos; den Grund erklären wir direkt im Anschluss.

Sollten Sie fallocate oder dd verwenden?

Beide Befehle legen die Datei an, aber auf unterschiedliche Weise. fallocate reserviert den Platz sofort, ohne Nullen zu schreiben, und ist daher sehr schnell. dd füllt die Datei dagegen vollständig mit Nullen, was bei großen Dateien Minuten dauern kann.

Die Handbuchseite von swapon macht einen wichtigen Punkt: Der Kernel möchte direkt in die Swap Datei schreiben, ohne Hilfe des Dateisystems. Deshalb lehnt swapon Dateien mit Löchern ab. Laut Handbuch können vorab mit fallocate reservierte Dateien je nach Dateisystem wie Dateien mit Löchern wirken. Als portabelste Methode nennt das Handbuch dd mit /dev/zero.

Die Dokumentation von Red Hat hält fallocate dagegen auf modernen Dateisystemen wie ext4 oder XFS für vorzuziehen. In der Praxis gehen wir so vor: Probieren Sie zuerst fallocate. Meldet swapon ein Problem mit Löchern, löschen Sie die Datei und legen sie mit dd neu an.

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Btrfs ist allerdings ein Sonderfall. Laut Handbuch unterstützt Btrfs Swapdateien nur mit dem Attribut nocow. Folgen Sie unter Btrfs also den eigenen Schritten in der Dokumentation Ihrer Distribution.

Wie machen Sie Swap mit /etc/fstab dauerhaft?

Der Befehl swapon wirkt nur bis zum nächsten Neustart. Damit Swap danach automatisch startet, ergänzen Sie eine Zeile in /etc/fstab. Legen Sie zuvor eine Kopie an, denn ein Tippfehler in fstab kann den Systemstart stören.

sudo cp /etc/fstab /etc/fstab.bak
echo '/swapfile none swap defaults 0 0' | sudo tee -a /etc/fstab

Die Zeile ist zudem leicht zu lesen. Das erste Feld nennt den Pfad, das zweite den Einhängepunkt (none bei Swap), das dritte den Typ und das vierte die Optionen. Die beiden Nullen schalten Dump und die Prüfreihenfolge ab. Manche Dokumentationen schreiben „sw“ als Option; beide Formen sind üblich.

Testen Sie die Änderung dann ohne Neustart:

sudo swapoff /swapfile
sudo swapon -a
swapon --show

swapon -a aktiviert alle Swapeinträge aus fstab. Taucht Ihr Swap in der Liste auf, stimmt die Zeile. Die Dokumentation von Red Hat empfiehlt auf Systemen mit systemd zudem systemctl daemon-reload nach jeder Änderung an fstab. So erkennt systemd den neuen Eintrag sofort.

Noch ein Hinweis: Fügen Sie dieselbe Zeile nicht zweimal ein. Haben Sie den Befehl versehentlich wiederholt, prüfen Sie das mit grep swap /etc/fstab.

Was ist Swappiness und wie stellen Sie den Wert ein?

Swappiness legt fest, wie bereitwillig der Kernel unter Speicherdruck auslagert. Laut Dokumentation des Linux Kernels liegt der Wert zwischen 0 und 200, der Standard ist 60. Niedrige Werte signalisieren teure Swapzugriffe, hohe Werte günstige.

Bei 100 übt der Kernel laut Dokumentation gleichen Druck auf den Seitencache und auf ausgelagerte Seiten aus. Bei 0 beginnt er erst mit dem Auslagern, wenn freie und dateibasierte Seiten unter eine bestimmte Schwelle fallen. Das heißt: 0 bedeutet nicht „Swap aus“.

So lesen Sie den aktuellen Wert und ändern ihn vorübergehend:

cat /proc/sys/vm/swappiness
sudo sysctl vm.swappiness=10

Die 10 ist hier nur ein Beispielwert. Damit die Änderung einen Neustart übersteht, legen Sie eine Datei unter /etc/sysctl.d an:

echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Sollten Sie den Wert also senken? Auf Datenbankservern ist ein niedrigerer Wert eine verbreitete Wahl, weil häufig genutzte Daten im RAM bleiben sollen. Treffen Sie die Entscheidung allerdings auf Basis von Messungen, nicht nach Faustregel. Beobachten Sie vorher und nachher einige Tage free -h und die Antwortzeiten Ihrer Anwendung. Hinweise zur Datenbank finden Sie in unserem Beitrag MySQL unter Ubuntu installieren.

Wie entfernen oder vergrößern Sie Swap?

Zum Entfernen gehen Sie den Weg rückwärts. Sie schalten Swap ab, löschen den Eintrag in fstab und entfernen erst dann die Datei. Die Reihenfolge zählt; löschen Sie nie eine aktive Swap Datei.

1. Schalten Sie Swap mit sudo swapoff /swapfile ab. Dabei wandern ausgelagerte Seiten zurück in den RAM.
2. Öffnen Sie /etc/fstab in einem Editor und löschen Sie die Zeile mit /swapfile.
3. Entfernen Sie die Datei mit sudo rm /swapfile.
4. Prüfen Sie das Ergebnis mit swapon --show und free -h.

Denken Sie daran: swapoff holt alle ausgelagerten Daten zurück in den Speicher. Fehlt dafür Platz im RAM, scheitert der Befehl, oder der Server gerät unter starken Druck. Führen Sie swapoff deshalb in einer ruhigen Stunde aus.

Zum Vergrößern folgen Sie demselben Weg. Schalten Sie Swap ab, legen Sie die Datei in neuer Größe an, und wiederholen Sie dann chmod, mkswap und swapon. Die Zeile in fstab bleibt gleich, weil sich der Pfad nicht ändert. Alternativ können Sie eine zweite Datei ergänzen, allerdings bleibt eine einzige Datei meist übersichtlicher.

Warum lässt sich auf manchen VPS kein Swap anlegen?

Auf manchen VPS meldet swapon einen Fehler wie „Operation nicht erlaubt“. Der häufigste Grund ist die Art der Virtualisierung. Bei containerbasierter Virtualisierung teilt sich Ihr Server den Kernel mit dem Host. Folglich verwaltet der Anbieter Einstellungen auf Kernelebene wie Swap, nicht Sie.

Zudem schränken manche Anbieter Swap in ihren Bedingungen ein, etwa wegen Plattenverschleiß oder geteilter Speicherleistung. Dann verstoßen Sie unter Umständen gegen die Regeln Ihres Tarifs, selbst wenn Swap technisch funktioniert.

Was können Sie tun?

• Prüfen Sie in der Dokumentation des Anbieters die Virtualisierung und die Regeln für Swap.
• Suchen Sie im Kundenpanel nach einer fertigen Swapoption.
• Ist Swap nicht erlaubt, erhöhen Sie den RAM oder senken Sie den Speicherbedarf der Anwendung.
• Wählen Sie bei der Tarifwahl ein Angebot mit Vollvirtualisierung.

Die Unterschiede zwischen VPS, VDS und Cloud Server vergleichen wir in VPS oder Cloud Server. Weitere Fragen an einen Anbieter finden Sie im Leitfaden Webhosting auswählen.

Welche Einstellungen zur SSH Absicherung sind am wichtigsten?

Swap kümmert sich um den Speicher; SSH ist die Haustür des Servers. Jeder SSH Port im Internet erhält schon bald automatisierte Passwortversuche. Deshalb lautet das erste Ziel: Passwörter überflüssig machen und die Tür verengen.

Konkret empfehlen wir diese Reihenfolge:

1. Erzeugen Sie auf Ihrem eigenen Rechner ein SSH Schlüsselpaar und hinterlegen Sie es auf dem Server.
2. Prüfen Sie, ob die Anmeldung per Schlüssel mit einem Benutzer ohne root, aber mit sudo, klappt.
3. Schalten Sie Passwortanmeldung und tastaturinteraktive Anmeldung ab.
4. Verbieten Sie die direkte Anmeldung als root.
5. Beschränken Sie den Zugang mit AllowUsers auf bestimmte Konten.
6. Testen Sie die Konfiguration mit sshd und prüfen Sie sie in einer zweiten Sitzung.
7. Ergänzen Sie weitere Schichten wie Firewall und Fail2ban.

Die Tabelle zeigt die Standardwerte laut Handbuch zu sshd_config von OpenSSH und unser Ziel. Die Konfiguration Ihrer Distribution kann einige Standards bereits überschreiben.

Wie richten Sie die Anmeldung per SSH Schlüssel ein?

Bei der Anmeldung per Schlüssel ersetzt ein Schlüsselpaar das Passwort. Der private Schlüssel bleibt auf Ihrem Rechner, der öffentliche landet in der Datei authorized_keys auf dem Server. Weil nie ein Passwort über das Netz geht, laufen Brute Force Versuche ins Leere.

Die offizielle Dokumentation von Ubuntu zum OpenSSH Server zeigt das Erzeugen eines Schlüssels vom Typ Ed25519. Führen Sie diese Befehle auf Ihrem eigenen Rechner aus:

ssh-keygen -t ed25519
ssh-copy-id deploy@203.0.113.10

Der erste Befehl erzeugt das Schlüsselpaar und fragt nach einer Passphrase. Lassen Sie sie nicht leer, denn sie schützt den Schlüssel, falls jemand Ihren Laptop stiehlt. Der zweite Befehl trägt den öffentlichen Schlüssel in authorized_keys des Benutzers ein. Die Adresse im Beispiel stammt aus einem Dokumentationsbereich; setzen Sie die Adresse Ihres Servers ein.

Öffnen Sie dann ein neues Terminal und verbinden Sie sich mit ssh deploy@203.0.113.10. Kommen Sie nur mit der Passphrase des Schlüssels hinein, ohne Serverpasswort, ist der Schritt erledigt. Die Dokumentation von Ubuntu rät außerdem, dass authorized_keys für andere nicht beschreibbar sein darf; dafür genügt chmod go-w ~/.ssh/authorized_keys.

Legen Sie Ihren privaten Schlüssel nie auf den Server, in eine E-Mail oder in einen geteilten Ordner. Jedes Teammitglied erzeugt einen eigenen Schlüssel; verlässt jemand das Team, löschen Sie nur seine Zeile.

Wie schalten Sie PasswordAuthentication und den Root Login ab?

Sobald die Anmeldung per Schlüssel klappt, schalten Sie die Passwortanmeldung ab. Die zentrale Datei ist /etc/ssh/sshd_config. Laut Ubuntu steht ganz oben in dieser Datei eine Include Zeile, die alle .conf Dateien unter /etc/ssh/sshd_config.d einliest.

Dieses Detail ist vor allem wichtig. Laut OpenSSH Handbuch gilt für jedes Schlüsselwort der zuerst gelesene Wert, und Include Dateien laden in lexikalischer Reihenfolge. Steht also in der Hauptdatei „no“, eine früher gelesene Datei in sshd_config.d sagt aber „yes“, dann gewinnt diese. Manche Cloud Images legen dort eine Datei ab, die Passwörter wieder erlaubt.

Deshalb empfehlen wir eine eigene Datei, deren Name alphabetisch zuerst kommt:

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

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Für PermitRootLogin kennt das Handbuch vier Werte: yes, prohibit-password, forced-commands-only und no. Der Standard prohibit-password verbietet root die Anmeldung per Passwort, erlaubt aber Schlüssel. Mit „no“ sperren Sie die direkte Anmeldung als root vollständig; Verwaltungsaufgaben erledigen Sie dann über sudo.

Listen Sie zudem die übrigen Dateien im Ordner mit ls /etc/ssh/sshd_config.d/ auf. Finden Sie eine widersprüchliche Einstellung, korrigieren Sie auch diese.

Wie begrenzen Sie den SSH Zugang mit AllowUsers?

AllowUsers legt ausdrücklich fest, wer sich per SSH anmelden darf. Laut Handbuch dürfen sich nach dem Setzen nur Benutzernamen anmelden, die zu einem der Muster passen. Das heißt: Andere Konten auf dem Server bleiben bestehen, kommen aber nicht mehr per SSH hinein.

Wollen Sie zum Beispiel nur deploy und admin zulassen, ergänzen Sie diese Zeile:

AllowUsers deploy admin

Muster akzeptieren auch die Form benutzer@host. So erlauben Sie einem Benutzer den Zugang nur von einer bestimmten Adresse, etwa AllowUsers deploy@198.51.100.25. Allerdings sollten Sie das nur mit fester IP tun. Ändert sich die Adresse Ihres Anschlusses zu Hause oder unterwegs, sperren Sie sich aus. Details zu einer Adresse zeigt unser Tool zur IP Abfrage.

Der häufigste Fehler bei AllowUsers: Man vergisst den eigenen Benutzernamen. Halten Sie daher die aktuelle Sitzung offen und testen Sie mit einer neuen. Möchten Sie lieber über Gruppen steuern, funktioniert AllowGroups laut Handbuch nach demselben Prinzip.

Wächst das Team, gewinnt auch die Dokumentation an Gewicht: Wer darf auf welchen Server? Das ist ebenso eine Frage der Organisation wie der Technik.

Bringt ein anderer SSH Port mehr Sicherheit?

Nur begrenzt. Ein Port abseits von 22 hält die meisten automatisierten Scanner fern und reduziert das Rauschen in den Logs. Allerdings findet ein gezielter Angreifer den neuen Port per Portscan schnell. Somit ist ein Portwechsel eine Maßnahme gegen Rauschen, kein Schutz.

Echten Schutz liefern stattdessen Schlüssel, abgeschaltete Passwörter und AllowUsers. Sind diese drei aktiv, bringt ein neuer Port etwas Komfort. Fehlen sie, rettet er nichts.

Wollen Sie den Port trotzdem ändern, halten Sie diese Reihenfolge ein:

• Öffnen Sie zuerst den neuen Port in der Firewall, sonst trennen Sie Ihre eigene Verbindung.
• Ändern Sie die Zeile Port in Ihrer Konfiguration.
• Bei neueren Ubuntu Versionen kann SSH über die Socketaktivierung von systemd laufen. Laut Ubuntu kann dann ssh.socket die Portbindung übernehmen; folgen Sie also der Dokumentation Ihrer Version.
• Öffnen Sie eine zweite Sitzung über den neuen Port und prüfen Sie die Verbindung.
• Schließen Sie zum Schluss den alten Port in der Firewall.

Hat Ihr Cloud Anbieter im Panel eine eigene Netzwerkfirewall, öffnen Sie den neuen Port auch dort.

Wie testen Sie SSH Änderungen, ohne sich auszusperren?

Ein einziger Tippfehler in der SSH Konfiguration kann Sie aussperren. Gehen Sie deshalb bei jeder Änderung gleich vor. Ubuntu empfiehlt zunächst eine schreibgeschützte Kopie der Originaldatei:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
sudo chmod a-w /etc/ssh/sshd_config.original

Nach der Änderung prüfen Sie die Syntax. sudo sshd -t testet Konfiguration und Schlüssel; ist alles in Ordnung, bleibt die Ausgabe leer. sudo sshd -T gibt die gesamte wirksame Konfiguration aus. So sehen Sie, welcher Wert nach den Include Dateien gilt.

sudo sshd -t
sudo sshd -T | grep -i passwordauthentication
sudo systemctl restart ssh.service

Unter Ubuntu heißt der Dienst ssh.service. Bei Distributionen auf Basis von RHEL heißt er meist sshd; prüfen Sie also Ihre Dokumentation.

Die wichtigste Regel: Schließen Sie Ihre aktuelle SSH Sitzung nicht. Ein Neustart des Dienstes lässt offene Sitzungen in der Regel bestehen. Öffnen Sie in einem neuen Terminalfenster eine zweite Sitzung und prüfen Sie die Anmeldung. Erst dann schließen Sie die erste. Geht etwas schief, stellen Sie über die offene Sitzung die Kopie wieder her. Als letzte Rettung sollten Sie außerdem die Webkonsole oder den Rettungsmodus Ihres Anbieters kennen.

Wo passen Fail2ban, 2FA und Firewall ins Bild?

Diese drei Schichten setzen auf den Grundlagen oben auf. Keine ersetzt die Anmeldung per Schlüssel, aber jede verkleinert die Angriffsfläche weiter.

Die Firewall kommt zunächst. Unter Ubuntu mit ufw erlauben Sie zunächst SSH und aktivieren dann die Firewall. Die Reihenfolge ist entscheidend; andersherum trennen Sie Ihre eigene Verbindung.

sudo ufw allow ssh
sudo ufw enable
sudo ufw status

Haben Sie den Port geändert, setzen Sie statt „ssh“ die neue Portnummer ein. Auf Servern mit cPanel ist CSF statt ufw üblich; Details stehen in unserem Beitrag CSF Firewall installieren.

Fail2ban liest Logdateien und sperrt Adressen mit wiederholten Fehlversuchen vorübergehend. Ist die Passwortanmeldung abgeschaltet, dient es vor allem dazu, das Rauschen in den Logs zu senken. Die Einrichtung wiederholen wir hier nicht; unsere Anleitung zu Fail2ban erklärt sie Schritt für Schritt.

Zwei Faktor Authentifizierung ergänzt den Schlüssel um einen zweiten Nachweis. Die OpenSSH Einstellung AuthenticationMethods kann mehrere Verfahren nacheinander verlangen. In der Praxis setzen Teams dafür meist TOTP Module über PAM ein. Allerdings sperrt eine fehlerhafte Einrichtung schnell aus; testen Sie daher zuerst auf einem Testserver.

Wann sollten Sie Swap und SSH lieber dem Hoster überlassen?

Sie müssen nicht jede Servereinstellung selbst vornehmen. Bei verwaltetem oder geteiltem Hosting liegen Swap und SSH ohnehin beim Anbieter. Eigene Änderungen können dort sogar den Supportanspruch gefährden.

In diesen Fällen raten wir, die Aufgabe dem Hoster oder einem erfahrenen Systemadministrator zu übergeben:

• Sie wissen nicht, wie Sie per Webkonsole oder Rettungsmodus auf den Server kommen.
• Auf dem Server läuft ein aktiver Onlineshop, und Ausfälle sind nicht akzeptabel.
• Ihr containerbasierter VPS erlaubt keinen Swap.
• Interne Compliance Regeln schreiben eine bestimmte SSH Richtlinie vor.
• Sie kopieren Befehle, ohne zu verstehen, was sie tun.

Verwalten Sie dagegen Ihren eigenen VPS und fühlen sich im Terminal wohl, sind die Schritte in diesem Leitfaden Routine. Entscheidend sind eine Sicherung vor jeder Änderung und ein Weg zurück. Ihren Plan prüfen Sie mit unserer Website Backup Strategie.

Unser Team plant die Servervorbereitung bei Webdesign und Softwareprojekten von Anfang an mit. Wie wir die Aufgaben mit dem Hoster teilen, beschreiben wir auf den Seiten zu Webdesign und individueller Softwareentwicklung.

Worauf sollten Sie auf Anwendungsebene noch achten?

Eine abgesicherte SSH Konfiguration verschließt die Haustür des Servers. Allerdings ist Ihre Website eine zweite Tür. Eine Lücke in der Webanwendung kann Zugriff verschaffen, ohne SSH überhaupt zu berühren.

Denken Sie Infrastruktur und Anwendungssicherheit deshalb zusammen. Veraltete Plugins, schwache Administratorpasswörter und zu offene Dateirechte gehören zu den häufigsten Risiken. Typische Schwachstellen fassen wir in unserem Beitrag zu den OWASP Top 10 zusammen.

Halten Sie außerdem die Systempakete aktuell. Jedes Paket, auch OpenSSH, erhält von Zeit zu Zeit Sicherheitsupdates. Automatische Sicherheitsupdates unter Ubuntu senken das Risiko, ein Update zu vergessen. Dennoch sollten Sie einplanen, dass ein automatisches Update einen Dienst neu starten kann.

Kurz gesagt: Serversicherheit besteht nicht aus einer Einstellung, sondern aus Schichten. Swap schützt die Stabilität, SSH den Zugang, und Anwendungssicherheit samt Backups runden das Bild ab.

Checkliste: Swap Datei anlegen und SSH absichern

Hier finden Sie alle Schritte in einer Liste. Halten Sie diese Reihenfolge bei einem neuen Server ein:

1. Prüfen Sie den Zustand mit swapon --show und free -h.
2. Legen Sie die Größe der Swap Datei anhand der offiziellen Dokumentation und Ihrer Last fest.
3. Erstellen Sie die Datei mit fallocate oder dd und führen Sie dann chmod 600, mkswap und swapon aus.
4. Ergänzen Sie die Zeile in fstab und testen Sie mit swapon -a.
5. Ändern Sie Swappiness nur auf Basis von Messungen.
6. Erzeugen Sie einen Schlüssel vom Typ Ed25519 und übertragen Sie ihn mit ssh-copy-id.
7. Schalten Sie Passwort und Root Login in einer eigenen Datei unter sshd_config.d ab.
8. Beschränken Sie den Zugang mit AllowUsers.
9. Testen Sie mit sshd -t, prüfen Sie eine zweite Sitzung und starten Sie dann den Dienst neu.
10. Aktivieren Sie die Firewall und ergänzen Sie Schichten wie Fail2ban.

Eine Swap Datei richten Sie in wenigen Minuten ein. SSH abzusichern braucht mehr Sorgfalt, schützt aber lange, wenn es einmal richtig sitzt. Für beides gilt dieselbe Regel: zuerst sichern, dann ändern, danach testen.