Die ersten acht. MRMedia ist neu — null Bewertungen, null Referenzen. Deshalb bekommen die ersten acht Kunden den ersten Monat geschenkt, für Tarife bis 6,99 € im Monat. Keine Verlängerungsfalle: nach dem Gratismonat kommt eine normale Rechnung, und zahlst du sie nicht, endet der Vertrag von selbst. Läuft bis 31.08.2026 oder bis die Plätze weg sind.

Noch 7 von 8 PlätzenCode NEW8Schreib mir

← Wiki

Erste Schritte auf dem eigenen VPS: SSH und Firewall

Stand: 12. August 2026 · Anleitung · VPS · Einsteiger

Nach der Bestellung kommt eine Mail mit IP-Adresse und root-Passwort. Der erste Kontakt läuft per SSH:

ssh root@DEINE-IP

Dauerhaft als root zu arbeiten ist keine gute Idee — ein Tippfehler im falschen Moment reicht. Deshalb gleich einen eigenen Benutzer mit sudo-Rechten anlegen:

adduser <benutzername>
usermod -aG sudo <benutzername>

Ab hier lohnt sich ein SSH-Key statt Passwort. Auf dem eigenen Rechner ein Schlüsselpaar erzeugen und auf den Server kopieren:

ssh-keygen -t ed25519
ssh-copy-id <benutzername>@DEINE-IP

In /etc/ssh/sshd_config anschließend PasswordAuthentication auf no und PermitRootLogin auf no setzen, dann den SSH-Dienst neu laden:

sudo systemctl reload sshd

Firewall

ufw ist auf Debian schnell installiert und macht aus einer Handvoll Befehlen eine funktionierende Firewall. Wichtig ist die Reihenfolge: erst SSH erlauben, dann scharf schalten — sonst sperrt man sich selbst aus.

sudo apt install ufw
sudo ufw allow OpenSSH
sudo ufw enable

Jeder weitere Dienst bekommt seine eigene Freigabe, wenn er gebraucht wird — ein Webserver den Port 80/443, ein Minecraft-Server 25565, ein TS3-Server seine drei Ports. Alles andere bleibt zu.

Das ist die Basis für die anderen Anleitungen hier: eigene Webseite, Minecraft, Discord-Bot, TeamSpeak. Jede davon setzt voraus, dass SSH-Zugang und Firewall schon so stehen.

Der Fehler, der am häufigsten passiert

Sich selbst aussperren. Wer PasswordAuthentication abschaltet, bevor der SSH-Key nachweislich funktioniert, kommt nicht mehr hinein — und ein VPS hat keine Tastatur, an die man sich setzen könnte. Die sichere Reihenfolge ist deshalb immer: Key hochladen, eine ZWEITE SSH-Sitzung parallel öffnen und mit ihr den Key-Login testen, und erst wenn der klappt in der ersten Sitzung die Passwort-Anmeldung abschalten. Die alte Sitzung bleibt offen und ist die Rückfahrkarte, falls etwas schiefgeht.

Dasselbe gilt für die Firewall: erst OpenSSH freigeben, dann scharf schalten. Andersherum trennt ufw die laufende Verbindung mitten im Befehl.

Automatische Sicherheitsupdates

Ein Server, den niemand aktualisiert, wird mit der Zeit unweigerlich angreifbar — und zwar nicht durch einen gezielten Angriff, sondern durch automatisierte Scanner, die bekannte Lücken abklopfen. Debian und Ubuntu bringen dafür ein Paket mit, das Sicherheitsupdates ohne Zutun einspielt:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Das deckt Sicherheitsaktualisierungen ab, keine Versionssprünge des Betriebssystems. Ein Neustart nach Kernel-Updates bleibt deine Entscheidung.

Anmeldeversuche ausbremsen

Sobald ein Server öffentlich erreichbar ist, laufen dauernd fremde Anmeldeversuche auf Port 22 auf. Mit Key-Login statt Passwort sind die praktisch aussichtslos, aber sie füllen das Log und kosten Rechenzeit. fail2ban sperrt auffällige IP-Adressen nach mehreren Fehlversuchen automatisch aus:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Nachsehen, was tatsächlich offen ist

Eine Firewall hilft nur gegen das, was sie kennt. Der ehrliche Blick geht deshalb auf die wirklich lauschenden Dienste — nicht auf die Regelliste, sondern auf den Server selbst:

sudo ss -tulpn
sudo ufw status verbose

Alles, was hier auf 0.0.0.0 lauscht und keinen Grund dafür hat, gehört entweder abgeschaltet oder an 127.0.0.1 gebunden. Eine Datenbank, die nur die eigene Anwendung braucht, muss nicht aus dem Internet erreichbar sein — das ist die häufigste Ursache dafür, dass ein sonst sauber eingerichteter Server doch übernommen wird.

Wenn du gar keinen Server pflegen willst

Alles oben ist einmalige Arbeit von etwa einer halben Stunde und danach Routine. Wer aber nur einen Gameserver oder einen Discord-Bot betreiben will, braucht diesen Unterbau nicht: bei den fertigen Produkten übernehmen wir Betriebssystem, Absicherung und Updates, und du siehst nur das Kontrollpult.