SSH-Port von 22 ändern: was es behebt und was nicht

Die ehrliche Zusammenfassung

SSH von 22 wegzuziehen senkt Ihr Volumen fehlgeschlagener Anmeldungen über Nacht um rund 90%. Es ist zugleich keine Sicherheitsmaßnahme, und es als solche zu behandeln ist die Art, wie Server von Administratoren kompromittiert werden, die dachten, sie seien fertig.

Beide Aussagen stimmen, weil sie verschiedene Fragen beantworten. Der Volumenrückgang ist real, messbar und nützlich. Der Schutz liegt nahe null gegenüber jedem, der dreißig Sekunden mit Nachsehen verbringt.

Lohnt es sich? Meist ja — als Rauschunterdrückung, neben einer echten Abwehr, nie an deren Stelle.

Was es tatsächlich stoppt

Der überwiegende Teil des SSH-Angriffsverkehrs stammt von ungezielten Scannern, die eines tun: sich über große IP-Bereiche mit Port 22 verbinden und Zugangsdaten probieren, wo etwas antwortet. Sie scannen keine Ports, denn einen Port über das ganze Internet zu prüfen kostet Größenordnungen weniger als 65.535, und auf 22 gibt es mehr als genug Maschinen.

Ziehen Sie auf 52200 um, und Sie fallen komplett aus dieser Population heraus. Die Kurve bricht ein, das Authentifizierungsprotokoll rotiert nicht mehr alle paar Stunden, und ein echtes Ereignis darin zu finden wird wieder möglich.

Dieser letzte Punkt wird unterschätzt. Ein lesbares Protokoll ist während eines Vorfalls bares Geld wert, und bei dreitausend Fehlschlägen am Tag haben Sie keines.

Was es nicht stoppt

Wer den gesamten Portbereich scannt, findet Sie in Minuten. SSH kündigt sich im Klartext an — der Versionsbanner ist das Erste, was der Dienst sendet —, ein Scanner, der alle Ports durchgeht und Banner liest, benennt Ihren Dienst also beim ersten Mal korrekt.

Shodan und Censys tun genau das fortlaufend und veröffentlichen die Ergebnisse als durchsuchbaren Index. Ihr abweichender SSH-Port steht dort, für jeden auffindbar, binnen Tagen.

Gegen einen ungezielten Bot funktioniert der Portwechsel also. Gegen jemanden, der Sie ausgewählt hat, kostet er ein paar Minuten. Und er ändert gar nichts an schwachen Passwörtern, einem geleakten Schlüssel, einem ungepatchten sshd oder einer verwundbaren Anwendung auf demselben Host.

Es gibt auch einen aktiven Nachteil: Ungewöhnliche Ports brechen Dinge. Firmenfirewalls, die ausgehend 22 erlauben, blockieren ausgehend 52200, und Sie erfahren das von einer Kollegin, die nicht deployen kann.

Umstellen, ohne sich auszusperren

Zwei Schritte fehlen in den meisten Anleitungen, und beide sperren Sie auf einer modernen Distribution aus: SELinux-Portkennzeichnung in der RHEL-Familie und systemd-Socket-Aktivierung in aktuellem Debian und Ubuntu, wo sshd nicht mehr selbst lauscht.

Halten Sie Ihre aktuelle Sitzung durchgehend offen und arbeiten Sie das der Reihe nach ab:

NEWPORT=52200

# 1. ZUERST die Firewall — bevor sshd irgendwohin umzieht
sudo ufw allow ${NEWPORT}/tcp                                          # Debian/Ubuntu mit ufw
sudo firewall-cmd --permanent --add-port=${NEWPORT}/tcp && sudo firewall-cmd --reload   # RHEL-Familie

# 2. SELinux: Port kennzeichnen, sonst weigert sich sshd zu binden (RHEL)
sudo semanage port -a -t ssh_port_t -p tcp ${NEWPORT} || \
  sudo semanage port -m -t ssh_port_t -p tcp ${NEWPORT}

# 3. sshd Bescheid geben. 22 vorerst behalten — zwei Ports, damit Sie nicht abgeschnitten werden
printf 'Port 22\nPort %s\n' "$NEWPORT" | sudo tee /etc/ssh/sshd_config.d/20-port.conf
sudo sshd -t                            # Syntaxprüfung vor jedem Reload

# 4. Socket-Aktivierung: in aktuellem Debian/Ubuntu bindet sshd nicht selbst
systemctl is-enabled ssh.socket 2>/dev/null && \
  echo 'ssh.socket ist aktiv — ListenStream dort überschreiben, siehe Hinweis unten'

sudo systemctl reload ssh               # 'sshd' in der RHEL-Familie

Den Umzug abschließen

Jetzt aus einem zweiten Terminal auf dem neuen Port prüfen — ssh -p 52200 user@server —, bevor Sie sonst etwas anfassen. Erst wenn das klappt, Port 22 aus der Konfiguration nehmen, erneut reloaden und die alte Firewall-Regel schließen.

Dann alles aktualisieren, was den alten Port gespeichert hat: Einträge in ~/.ssh/config, Deploy-Skripte, CI-Runner, Ansible-Inventare, Monitoring-Prüfungen, Backup-Jobs und die Dokumentation Ihres Teams. Ein Portwechsel, der das nächtliche Backup zerstört, ist schlimmer als gar keiner.

Entfernen Sie Port 22 nicht, bevor Sie bestätigt haben, dass der neue Port von außerhalb Ihres Netzes funktioniert. Im LAN funktioniert beides — und genau so überzeugen sich Leute, dass alles in Ordnung ist.

Womit es zu kombinieren ist

Ein Portwechsel reduziert Rauschen. Irgendetwas muss die ankommenden Versuche trotzdem behandeln — und nach einem Portwechsel kommen die von jemandem, der gezielt nach Ihnen gesucht hat, also genau die, die Sie interessieren.

SSH Protector ermittelt den echten SSH-Port aus sshds wirksamer Konfiguration, statt 22 anzunehmen — ein bereits verlegter Server ist also ohne jede Konfiguration abgedeckt, und die Regeln werden neu gebaut, wenn sich der Port erneut ändert.

Ändern Sie den Port für ein lesbares Protokoll. Behalten Sie eine Abwehr für den Verkehr, der Sie trotzdem findet.