SSH-Port ändern, ohne sich auszusperren: sshd, Socket-Aktivierung und SELinux

Der Wechsel des SSH-Ports ist eine der meistgegebenen und am schlechtesten begründeten Empfehlungen der Serveradministration. Er hat einen echten Nutzen, aber einen anderen als den, der ihm üblicherweise zugeschrieben wird, und er hat eine Nebenwirkung: Zwischen dem Moment, in dem der Dienst den alten Port loslässt, und dem, in dem der neue durch alle Paketfilter erreichbar ist, klafft eine Lücke. Wer sie nicht einplant, findet sie.

Diese Anleitung führt den Wechsel so durch, dass die Lücke gar nicht erst entsteht: Der Server lauscht während des Umbaus gleichzeitig auf dem alten und dem neuen Port, und der alte fällt erst weg, wenn der neue nachweislich funktioniert.

Alle Angaben beziehen sich auf Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS und Ubuntu 22.04 LTS. Ein eigener Abschnitt behandelt SELinux auf RHEL-Systemen wie AlmaLinux und Rocky Linux. Die Befehle sind für den Betrieb als root geschrieben. Wenn Sie als normaler Benutzer arbeiten, stellen Sie jedem Befehl sudo voran. Als Beispielport dient 2222, als Beispieladresse 203.0.113.10.

Was ein anderer Port bringt, und was nicht

Kein Sicherheitsgewinn. Ein vollständiger Portscan über alle 65.535 Ports findet den Dienst trotzdem, und die Versionskennung, die OpenSSH beim Verbindungsaufbau sendet, verrät auch auf Port 51022 sofort, worum es sich handelt. Der Portwechsel ersetzt keine der Maßnahmen, die tatsächlich wirken: Schlüsselanmeldung statt Passwort, abgeschaltete Passwortanmeldung, ein enger Paketfilter.

Weniger Log-Rauschen, und das ist nicht wenig. Der überwiegende Teil dessen, was auf Port 22 auftrifft, ist ungezieltes Massenscannen. Diese Werkzeuge probieren Port 22 und sonst nichts, weil sich ein Vollscan über das gesamte Internet nicht lohnt. Verlegen Sie den Dienst, verschwindet diese Verkehrsklasse aus dem Journal, und der einzelne, gezielte Anmeldeversuch fällt überhaupt erst auf.

Kosten, die man einkalkulieren muss. Jedes Werkzeug braucht künftig die Portangabe: Sicherungsskripte, Bereitstellungsläufe, Überwachung. Und ein Punkt, den fast alle Anleitungen unterschlagen: Firmennetze, Hotel-WLANs und manche Mobilfunktarife lassen ausgehend nur wenige Ports zu, meist 22, 80 und 443. Aus solchen Netzen kommen Sie danach unter Umständen gar nicht mehr auf Ihren Server.

Kurz: Machen Sie es, wenn Sie ruhige Logs wollen. Machen Sie es nicht in der Annahme, damit ein Sicherheitsproblem gelöst zu haben.

Der Rückweg, bevor Sie irgendetwas ändern

1. Die Konsole im Kundenbereich einmal öffnen

Jeder KVM-Rootserver und jeder Dedicated Server bei KernelHost hat im Kundenbereich eine VNC-Konsole. Sie sitzt auf der Bildschirmausgabe des Systems und ist vom Netzwerkstapel des Servers unabhängig, eine falsche Firewall-Regel kann sie deshalb nicht blockieren. Melden Sie sich dort einmal vorher an und vergewissern Sie sich, dass Sie das root-Passwort kennen. Ein Rettungsweg, den man erst im Notfall ausprobiert, ist keiner.

2. Zwei Sitzungen, und die erste bleibt offen

Melden Sie sich ein zweites Mal an, bevor Sie beginnen. Bestehende SSH-Verbindungen überleben sowohl einen Neustart des Dienstes als auch das Schließen des alten Ports in der Firewall, weil der Verbindungszustand bereits etabliert ist. Sie behalten also selbst dann eine Root-Shell, wenn Sie sich für neue Verbindungen längst ausgesperrt haben. Genau das ist die Falle: Es sieht alles in Ordnung aus, bis Sie das Fenster schließen.

3. Ein Zeitschalter, der die Änderung selbst zurücknimmt

Falls beide Sitzungen wegbrechen, etwa weil Ihr Anschluss ausfällt, rollt dieser Auftrag die Portänderung nach fünfzehn Minuten zurück:

systemd-run --on-active=15min --unit=ssh-portrollback /bin/sh -c 'rm -f /etc/ssh/sshd_config.d/20-port.conf /etc/systemd/system/ssh.socket.d/override.conf; systemctl daemon-reload; systemctl try-restart ssh.socket ssh.service'

Kontrolle: systemctl list-timers ssh-portrollback.timer zeigt den Auslösezeitpunkt. Hat alles funktioniert, brechen Sie den Auftrag ab, sonst fällt Ihre Änderung später mitten im Betrieb zurück:

systemctl stop ssh-portrollback.timer

Die Reihenfolge, die nicht aussperrt

Diese Abfolge ist so gebaut, dass zu keinem Zeitpunkt der alte Weg schon zu und der neue noch nicht offen ist.

1. Port auswählen und prüfen, dass er frei ist.
2. Firewall zuerst: neuen Port öffnen, alten offen lassen.
3. sshd auf beiden Ports lauschen lassen.
4. Bei Socket-Aktivierung zusätzlich die Socket-Unit anpassen.
5. Neu starten und am geöffneten Socket prüfen.
6. Mit einer dritten, frischen Sitzung über den neuen Port anmelden.
7. Erst jetzt Port 22 entfernen und die Werkzeuge nachziehen.

Schritt 1: Den Port auswählen

Nicht 2222. Dieser Port ist die häufigste Ausweichwahl und wird von Massenscannern längst mitgeprüft. Wir verwenden ihn hier nur als gut lesbares Beispiel.

Unterhalb von 32768 bleiben. Der Bereich, aus dem der Kernel Quellports für ausgehende Verbindungen vergibt, steht hier:

cat /proc/sys/net/ipv4/ip_local_port_range

Üblich ist die Ausgabe 32768 60999. Ein Port aus diesem Bereich kann von einer ausgehenden Verbindung vorübergehend belegt werden. Meist geht das gut, aber nach einem Neustart, wenn andere Dienste vor sshd starten, scheitert der Bindeversuch mit Address already in use, und der Server kommt ohne SSH hoch. Das tritt sporadisch auf und ist unangenehm zu finden.

Unter 1024 hat einen echten Vorteil. Ports unterhalb 1024 darf nur root belegen. Fällt sshd aus, kann sich dort also kein unprivilegierter Benutzer einhängen und einen gefälschten SSH-Dienst betreiben, der Zugangsdaten mitschreibt. Bei mehreren Benutzerkonten ist das ein Argument, bei einem einzigen Administrator eher theoretisch.

Kontrolle: Der Port darf weder belegt noch für einen Dienst vorgesehen sein, den Sie später betreiben wollen. Beide Befehle sollen nichts ausgeben:

ss -tlnp | grep -E ':2222 '
grep -w 2222 /etc/services

Schritt 2: Die Firewall zuerst

Dieser Schritt kommt vor der sshd-Konfiguration, nicht danach. Ein offener Port ohne Dienst dahinter ist harmlos, ein Dienst ohne offenen Port sperrt Sie aus.

ufw allow 2222/tcp comment 'SSH neu'
ufw status verbose

Kontrolle: In der Ausgabe müssen jetzt beide Ports stehen, und zwar je zweimal, einmal für IPv4 und einmal mit dem Zusatz (v6). Fehlt die IPv6-Zeile, ist der neue Port über IPv6 nicht erreichbar, und moderne Clients versuchen IPv6 zuerst. Einzelheiten in unserer Anleitung zur UFW-Firewall.

Wer nftables von Hand pflegt, trägt den Port in seiner Regeldatei nach, lädt sie neu und prüft am geladenen Regelsatz mit nft list ruleset | grep 2222. Auf RHEL-Systemen mit firewalld:

firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload
firewall-cmd --list-ports

Zwei Stellen werden übersehen. Erstens fail2ban: Greift dort eine Sperre, blockiert sie nach dem Wechsel weiterhin nur Port 22, während die Versuche auf dem neuen Port durchgehen. Tragen Sie den Port in /etc/fail2ban/jail.local nach:

[sshd]
enabled = true
port    = 2222

Die Erkennung arbeitet weiter, weil fail2ban die Anmeldeversuche aus dem Journal liest und nicht am Port festmacht. Nur die Sperrwirkung hängt an dieser Zeile, siehe unsere Anleitung zu fail2ban. Zweitens ein vorgelagerter Paketfilter außerhalb des Servers, sonst suchen Sie den Fehler an der falschen Stelle.

Schritt 3: sshd_config und die Falle sshd_config.d

Fassen Sie /etc/ssh/sshd_config nicht an. Alle vier Systeme lesen zusätzliche Konfiguration aus /etc/ssh/sshd_config.d/, und eine eigene Datei dort überlebt Paketaktualisierungen ohne Rückfragen. Sehen Sie zuerst nach, was schon da ist:

ls -l /etc/ssh/sshd_config.d/
grep -n '^Include' /etc/ssh/sshd_config

Die Include-Zeile steht bei Debian und Ubuntu ab Werk ganz oben, üblicherweise in Zeile 12. Das ist wichtiger, als es aussieht: Bei den meisten Direktiven gewinnt der erste gefundene Wert, nicht der letzte. Weil der Include oben steht, schlagen die Dateien im Verzeichnis alles, was weiter unten in sshd_config folgt. Wurde er ans Dateiende verschoben, kehrt sich das um und Ihre Datei bleibt wirkungslos.

Bei Port gilt eine Ausnahme, und genau sie macht den gefahrlosen Wechsel möglich: Mehrere Port-Zeilen ersetzen einander nicht, sie summieren sich. sshd lauscht dann auf allen genannten Ports. Ebenso wichtig ist die Kehrseite: Der Standardwert 22 gilt nur, solange überhaupt keine Port-Zeile existiert. Sobald Sie eine schreiben, ist 22 weg, wenn Sie ihn nicht ausdrücklich mit aufführen.

tee /etc/ssh/sshd_config.d/20-port.conf >/dev/null <<'EOF'
Port 22
Port 2222
EOF
chmod 644 /etc/ssh/sshd_config.d/20-port.conf

Kontrolle: erst die Syntax, dann die wirksame Gesamtkonfiguration mit aufgelösten Include-Dateien:

sshd -t
sshd -T | grep -E '^(port|listenaddress) '

Erwartet werden zwei Zeilen, port 22 und port 2222. Erscheint zusätzlich eine listenaddress-Zeile, ist das der zweite Ort, an dem Ports stehen können: ListenAddress darf eine Adresse samt Port angeben und schränkt dann ein, worauf gelauscht wird. Eine übersehene Zeile wie ListenAddress 127.0.0.1 erklärt die meisten Fälle, in denen der Port sauber konfiguriert ist, von außen aber niemand ankommt.

Meldet sshd -t stattdessen Missing privilege separation directory: /run/sshd, lief der Dienst seit dem Systemstart nie, und mkdir -p /run/sshd räumt das aus.

Schritt 4: Socket-Aktivierung, wo der Port nicht in sshd_config steht

Hier trennen sich die Distributionen, und hier passieren die meisten Unfälle. Ubuntu setzt seit 22.10 auf Socket-Aktivierung: Nicht sshd hält den Port, sondern systemd. Es lauscht stellvertretend und startet erst bei einer eingehenden Verbindung einen sshd-Prozess. Der Port steht dann in der Unit ssh.socket unter ListenStream, und eine Port-Zeile in der sshd-Konfiguration kann wirkungslos bleiben.

Raten Sie nicht, sondern fragen Sie das System:

systemctl is-enabled ssh.socket ssh.service

Die Tabelle beschreibt den Auslieferungszustand, nicht zwingend Ihren Server: Abbilder verschiedener Herkunft weichen ab, und ein aktualisiertes System behält seine bisherige Einstellung. Ist ssh.socket aktiv, zeigt systemctl cat die Unit samt aller Ergänzungsdateien mit ihren Pfaden, auch der automatisch erzeugten:

systemctl cat ssh.socket

Den neuen Port hinterlegen Sie als eigene Ergänzungsdatei. Die erste, leere ListenStream=-Zeile löscht die vorhandenen Werte, danach zählen ausschließlich Ihre. Ohne diese Rücksetzzeile kämen die Vorgaben zusätzlich dazu:

mkdir -p /etc/systemd/system/ssh.socket.d
tee /etc/systemd/system/ssh.socket.d/override.conf >/dev/null <<'EOF'
[Socket]
ListenStream=
ListenStream=0.0.0.0:22
ListenStream=[::]:22
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222
EOF
systemctl daemon-reload

Auch hier stehen beide Ports nebeneinander, aus demselben Grund wie in Schritt 3. Eine Datei unter /etc/systemd/system/ hat Vorrang vor allem, was das System selbst erzeugt.

Kontrolle: systemctl cat ssh.socket führt Ihre Datei nun als eigenen Block auf.

Sind ssh.service und ssh.socket gleichzeitig aktiv, streiten sie sich um denselben Port. Das äußert sich in fatal: Cannot bind any address. oder ssh.socket: Socket service ssh.service already active, refusing. Entscheiden Sie sich dann für eine der beiden Betriebsarten, die Hintergründe behandelt unsere Anleitung zur SSH-Absicherung.

Schritt 5: Neu starten und am Socket prüfen

Ein Befehl, der auf allen vier Systemen richtig ist, weil try-restart nur neu startet, was tatsächlich läuft, und die jeweils andere Einheit unangetastet lässt:

sshd -t && systemctl try-restart ssh.socket ssh.service

Verwenden Sie kein reload: Auf Systemen mit Socket-Aktivierung quittiert es mit fatal: Cannot bind any address., und der Dienst hat danach seinen Port losgelassen. Und kein einzelnes systemctl restart ssh.socket: Auf Debian scheitert es, auf Ubuntu 22.04 stellt es den Host unbemerkt auf Socket-Betrieb um. Bestehende Sitzungen überstehen den Neustart in jedem Fall.

Kontrolle, und zwar die einzige, die wirklich zählt:

ss -tlnp | grep -E ':(22|2222) '

Erwartet werden vier Zeilen: 0.0.0.0:22, [::]:22, 0.0.0.0:2222 und [::]:2222. Fehlen die IPv6-Zeilen, erreichen Sie den Server über IPv6 nicht.

Eine Eigenheit, die zu unnötiger Panik führt: In der letzten Spalte steht bei Socket-Aktivierung unter Umständen systemd statt sshd, weil systemd den lauschenden Socket hält, solange kein sshd-Prozess läuft. Filtern Sie deshalb nach der Portnummer, nicht nach dem Prozessnamen, sonst halten Sie einen arbeitenden Dienst für tot.

Schritt 6: Die dritte Sitzung, der eigentliche Test

Jetzt, und keinen Schritt früher, öffnen Sie ein neues Terminal. Die beiden alten Sitzungen bleiben offen.

ssh -p 2222 root@203.0.113.10

Klappt das nicht, zeigt ssh -vv -p 2222 root@203.0.113.10, an welcher Stelle es scheitert.

Eine Rückfrage ist dabei normal: SSH fragt erneut nach der Echtheit des Hostschlüssels, obwohl sich am Server nichts geändert hat. Einträge in known_hosts sind nämlich portgebunden und werden für abweichende Ports in der Form [203.0.113.10]:2222 abgelegt. Nachsehen und im Zweifel entfernen:

ssh-keygen -F '[203.0.113.10]:2222'
ssh-keygen -R '[203.0.113.10]:2222'

Ob der Umbau einen Neustart übersteht, prüfen Sie am besten jetzt. Dank der noch offenen Freigabe für Port 22 ist das ungefährlich.

Schritt 7: Port 22 schließen und die Werkzeuge nachziehen

Erst wenn Schritt 6 funktioniert hat, entfernen Sie den alten Port. In 20-port.conf bleibt nur noch eine Zeile:

tee /etc/ssh/sshd_config.d/20-port.conf >/dev/null <<'EOF'
Port 2222
EOF
sshd -t && systemctl try-restart ssh.socket ssh.service

Bei Socket-Aktivierung streichen Sie zusätzlich die beiden Zeilen mit Port 22 aus /etc/systemd/system/ssh.socket.d/override.conf und lassen systemctl daemon-reload folgen. Danach die Firewall:

ufw delete allow 22/tcp
ufw status verbose

Kontrolle: ss -tlnp | grep -E ':(22|2222) ' zeigt jetzt nur noch den neuen Port, wieder in beiden Adressfamilien.

Bleibt der Teil, der am längsten nachhallt: alle Werkzeuge, die den Server ansprechen. Am bequemsten erledigen Sie das ein für alle Mal in ~/.ssh/config:

Host mein-server
    HostName 203.0.113.10
    Port 2222
    User kernel

Wo Sie die Adresse direkt angeben, brauchen Sie die Portangabe, und die Schreibweise unterscheidet sich je Werkzeug. Das ist die klassische Stolperstelle:

rsync --port betrifft übrigens den rsync-Daemon und nicht SSH, es hat hier keine Wirkung. In Ansible steht der Port als ansible_port im Inventar.

SELinux auf RHEL-Systemen

Auf AlmaLinux, Rocky Linux und RHEL ist SELinux ab Werk im Modus enforcing, und das Regelwerk erlaubt sshd ausschließlich Ports, die als ssh_port_t gekennzeichnet sind. Ab Werk ist das nur Port 22. Ohne diesen Zusatzschritt startet der Dienst nicht, und die Meldung sieht irreführend nach einem Rechteproblem aus:

error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.

Zuerst der Blick auf Zustand und vorhandene Kennzeichnung:

getenforce
semanage port -l | grep ssh_port_t

Fehlt semanage, liegt es im Paket policycoreutils-python-utils:

dnf install -y policycoreutils-python-utils

Den neuen Port hinzufügen, und zwar bevor Sie sshd neu starten:

semanage port -a -t ssh_port_t -p tcp 2222

Ist der Port bereits einem anderen Typ zugeordnet, scheitert -a mit dem Hinweis, dass er schon definiert ist. Dann ändern Sie die Zuordnung mit -m, statt eine neue hinzuzufügen.

Kontrolle: semanage port -l | grep ssh_port_t führt nun beide Ports auf. Klemmt danach trotzdem etwas, zeigen die abgelehnten Zugriffe:

ausearch -m avc -ts recent

Debian und Ubuntu haben in der Standardinstallation keine vergleichbare Beschränkung, dort entfällt dieser Abschnitt.

Häufige Fehler und Lösungen

ssh: connect to host 203.0.113.10 port 2222: Connection refused: Die Pakete kommen an, aber niemand lauscht. Der Dienst wurde nicht neu gestartet, die Konfiguration kam nicht an, oder eine ListenAddress-Zeile bindet ihn an eine andere Adresse.

ssh: connect to host 203.0.113.10 port 2222: Connection timed out: Die Pakete kommen gar nicht erst an, fast immer ein Paketfilter auf dem Server oder in Ihrem eigenen Netz. Der Unterschied zur vorigen Meldung ist die wichtigste Diagnoseinformation überhaupt: abgewiesen heißt Dienst fehlt, Zeitüberschreitung heißt Filter.

error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.: Auf RHEL-Systemen SELinux, siehe oben. Auf Debian und Ubuntu tritt die Meldung praktisch nur auf, wenn sshd nicht als root läuft und einen Port unter 1024 belegen soll.

error: Bind to port 2222 on 0.0.0.0 failed: Address already in use.: Ein anderer Prozess hat den Port, ss -tlnp | grep ':2222 ' nennt ihn. Tritt der Fehler nur sporadisch nach einem Neustart auf, liegt der Port im Bereich der dynamischen Quellports, siehe Schritt 1.

fatal: Cannot bind any address.: Keine der angeforderten Adressen ließ sich belegen. Auf Debian und Ubuntu bedeutet das in aller Regel, dass ssh.socket den Port bereits hält und Sie zusätzlich ssh.service darauf starten wollen.

Job for ssh.service failed because the control process exited with error code.: Die Ursache steht im Journal, nicht in dieser Zeile. journalctl -u ssh -n 50 --no-pager zeigt sie, unabhängig von der OpenSSH-Version.

/etc/ssh/sshd_config.d/20-port.conf line 1: Bad configuration option: prot: Ein Tippfehler. sshd -t nennt Datei und Zeilennummer, genau dafür steht der Befehl vor jedem Neustart.

sshd: no hostkeys available -- exiting.: Die Hostschlüssel fehlen oder sind nicht lesbar, ssh-keygen -A erzeugt die fehlenden. sshd -t und sshd -T brauchen Leserechte darauf und müssen deshalb als root laufen.

ssh: connect to host 203.0.113.10 port 22: Connection refused nach erfolgreichem Wechsel: Ihr Client versucht weiterhin den Standardport. Ergänzen Sie ~/.ssh/config oder geben Sie -p mit.

Wenn Sie doch ausgesperrt sind

1. Nicht neu starten. Ein Neustart stellt Firewall-Regeln und Dienstkonfiguration wieder her, der Server kommt genauso verschlossen zurück.
2. VNC-Konsole im Kundenbereich öffnen und als root anmelden. Die Konsolenanmeldung läuft nicht über SSH und ist von Ihrer Änderung nicht betroffen.
3. Fehlerklasse feststellen. ss -tlnp beantwortet das sofort: Steht der Port da, ist es ein Filterproblem. Steht er nicht da, ist es ein Dienstproblem, und journalctl -u ssh -n 50 --no-pager sagt warum.
4. Zurückrollen statt reparieren. rm -f /etc/ssh/sshd_config.d/20-port.conf und, falls angelegt, rm -f /etc/systemd/system/ssh.socket.d/override.conf, danach systemctl daemon-reload und systemctl try-restart ssh.socket ssh.service.
5. War die Firewall die Ursache, hilft ufw disable, gefolgt vom sauberen Wiederaufbau mit der richtigen Portfreigabe.

Kurzfassung

• Firewall zuerst, sshd danach. Der alte Port bleibt offen, bis der neue nachweislich funktioniert.
• Mehrere Port-Zeilen summieren sich, das macht den Übergang gefahrlos. Der Standardwert 22 entfällt, sobald irgendeine Port-Zeile existiert.
• Bei Socket-Aktivierung, ab Werk auf Ubuntu 24.04, steht der Port in ListenStream.
• Maßgeblich ist nie die Konfigurationsdatei, sondern ss -tlnp, gefiltert nach Portnummer.
• Rettungsweg ist die VNC-Konsole im Kundenbereich, dafür das root-Passwort bereithalten.

Nehmen Sie den Server gerade erst in Betrieb, ordnet unsere Checkliste für neue Rootserver diesen Schritt in die übrige Grundeinrichtung ein. Und noch einmal zur Einordnung: Ein anderer Port macht Ihre Logs lesbar. Sicher wird der Zugang durch die Schlüsselanmeldung und die abgeschaltete Passwortanmeldung. Wenn Sie nur eines von beiden umsetzen, nehmen Sie das zweite.