SSH-Härtung mit Schlüsseln, Portstrategie und AllowLists

SSH ist auf vielen Ubuntu-Servern der wichtigste Admin-Zugang. Genau deshalb ist es einer der ersten Dienste, die sauber gehärtet werden sollten. In der Praxis geht es dabei nicht um übertriebene Geheimrezepte, sondern um ein paar sehr wirkungsvolle Grundlagen: Schlüssel statt Passwörter, eine klare Portstrategie und bewusst gesetzte AllowLists.

In dieser Anleitung härten wir OpenSSH auf Ubuntu Schritt für Schritt, ohne uns selbst auszusperren. Wir schauen uns an, wie du Schlüssel einsetzt, welche Einstellungen in sshd_config wirklich wichtig sind und wie du SSH sinnvoll auf bestimmte Netze oder Zugriffswege begrenzt.

1. Was SSH-Härtung in der Praxis bedeutet

SSH-Härtung heisst nicht, jede erdenkliche Option maximal aggressiv zu setzen. Ziel ist vielmehr:

• unbefugte Anmeldungen erschweren oder verhindern
• Passwortangriffe vermeiden
• nur klar definierte Benutzer zulassen
• Zugriff möglichst auf sichere Netze oder Wege beschränken
• bei Änderungen trotzdem nicht den eigenen Notfallzugang verlieren

Gerade der letzte Punkt ist entscheidend. Die beste SSH-Härtung nützt nichts, wenn du dich danach selbst vom Server ausgesperrt hast.

2. Bevor du etwas änderst: Sicherheitsnetz aufbauen

Vor jeder SSH-Änderung solltest du mindestens:

• eine bestehende SSH-Sitzung offen lassen
• einen zweiten Testlogin vorbereiten
• wissen, ob du einen Zugriff über Provider-Konsole, VPS-Panel oder Hypervisor hast
• deinen Benutzer und vorhandene Schlüssel sauber prüfen

Wenn du direkt produktive Zugangsmethoden umbaust, ohne Rückfallmöglichkeit, ist das unnötig riskant.

3. Schlüssel statt Passwort verwenden

Der wichtigste Schritt ist fast immer: Public-Key-Authentisierung statt Passwort-Login.

Ubuntu dokumentiert für OpenSSH die übliche Methode, einen öffentlichen Schlüssel im Zielsystem unter ~/.ssh/authorized_keys zu hinterlegen. Heute ist ed25519 für viele Setups eine sehr gute Standardwahl.

Auf deinem Client erzeugst du zum Beispiel einen Schlüssel:

ssh-keygen -t ed25519 -a 100

Danach kopierst du den öffentlichen Schlüssel auf den Server, zum Beispiel mit:

ssh-copy-id user@server

Oder manuell in die Datei:

~/.ssh/authorized_keys

Wichtig ist, dass du den Login mit Schlüssel zuerst erfolgreich testest, bevor du Passwortanmeldung abschaltest.

4. Zentrale Einstellungen in sshd_config

Die OpenSSH-Serverkonfiguration liegt in der Regel unter:

/etc/ssh/sshd_config

Typisch sinnvolle Härtungsoptionen sind:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes

Die genaue Datei und einzelne Defaults können je nach Ubuntu-Version leicht variieren. Wichtig ist vor allem die Grundlogik:

• kein direkter Root-Login
• keine Passwortanmeldung, sobald Schlüssel sauber funktionieren
• nur bewusst gewünschte Authentisierung aktiv lassen

5. Root-Login deaktivieren

Direkter Root-Login per SSH ist für die meisten Setups unnötig. Besser ist ein normaler Benutzer mit sudo. Setze dafür:

PermitRootLogin no

So wird ein besonders attraktives Angriffsziel direkt entschärft. Wichtig ist natürlich, dass dein Admin-Benutzer wirklich sauber mit sudo arbeiten kann.

6. Passwortanmeldung abschalten, aber erst nach Test

Sobald Schlüsselzugang funktioniert, ist das Abschalten von Passwortanmeldung einer der grössten Sicherheitsgewinne gegen automatisierte Angriffe:

PasswordAuthentication no

Ich würde das aber nie blind setzen und sofort die einzige SSH-Sitzung schliessen. Besser:

1. Schlüsselzugang testen
2. zweite Sitzung erfolgreich öffnen
3. dann erst Passwortanmeldung deaktivieren
4. Konfiguration prüfen und Dienst neu laden

7. Portstrategie: ändern oder nicht?

Die Frage nach einem alternativen SSH-Port wird oft emotional diskutiert. Wichtig ist: Ein anderer Port ersetzt keine echte Härtung. Er kann aber Lärm im Log reduzieren und simple Massen-Scans etwas ausbremsen.

Wenn du den Port ändern willst, zum Beispiel auf 2222, dann in sshd_config:

Port 2222

Danach musst du natürlich auch Firewall, Monitoring und eigene Admin-Abläufe anpassen.

Meine pragmatische Einschätzung:

• wenn SSH öffentlich erreichbar bleibt, kann ein anderer Port sinnvoll sein
• wenn SSH sowieso nur über Tailscale, VPN oder AllowLists erreichbar ist, ist die Portfrage viel weniger wichtig

Der grössere Hebel liegt fast immer bei Schlüsseln, Netzbeschränkung und sauberer Benutzersteuerung.

8. AllowLists mit AllowUsers oder Netzrestriktionen

OpenSSH erlaubt es, gezielt festzulegen, welche Benutzer sich überhaupt anmelden dürfen. Eine einfache und sehr wirkungsvolle Möglichkeit ist:

AllowUsers admin deploy

Damit sind nur diese Benutzer für SSH zugelassen. Wenn auf dem System viele System- oder Anwendungsbenutzer existieren, reduziert das die mögliche Angriffsfläche deutlich.

Zusätzlich kannst du SSH per Firewall oder Netzstrategie nur aus bestimmten Bereichen erlauben, etwa:

• nur aus internem LAN
• nur über Tailscale
• nur über VPN
• nur von festen Admin-IP-Bereichen

Gerade diese Netz-AllowLists sind oft wirksamer als viele exotische SSH-Tweaks.

9. SSH nur über Tailscale oder definierte Netze

Für viele moderne Self-Hosted-Server ist das eine sehr starke Strategie:

• Port 22 nicht öffentlich im Internet
• SSH nur über Tailscale-IP oder VPN
• zusätzlich Schlüssel-Authentisierung und AllowUsers

Dadurch reduzierst du die sichtbare Angriffsfläche massiv. Wenn du diesen Weg wählst, dokumentiere aber unbedingt einen Notfallzugang ausserhalb von Tailscale oder VPN.

10. Konfiguration testen, bevor du neu lädst

Bevor du den SSH-Dienst neu lädst, prüfe die Konfiguration:

sudo sshd -t

Wenn hier kein Fehler erscheint, kannst du neu laden:

sudo systemctl reload ssh

Danach testest du sofort mit einer neuen Sitzung den Zugang. Die bestehende funktionierende Sitzung lässt du dabei offen.

11. Typische Fehler

• Passwortanmeldung deaktivieren, bevor Schlüssel sauber getestet sind
• Root-Login abschalten, obwohl der eigentliche Admin-Benutzer nicht sauber eingerichtet ist
• Port ändern und Firewall-Regel vergessen
• AllowUsers zu eng setzen und sich selbst ausschliessen
• keinen Notfallzugang dokumentieren

Die meisten SSH-Probleme entstehen nicht durch Härtung an sich, sondern durch ungetestete Änderungen.

12. Was ich für viele Ubuntu-Server empfehlen würde

• ed25519-Schlüssel
• PermitRootLogin no
• PasswordAuthentication no nach sauberem Test
• AllowUsers für echte Admin-Benutzer
• SSH möglichst nur über Tailscale, VPN oder definierte Netze
• Firewall-Regel bewusst dokumentieren

Damit hast du für viele kleine und mittlere Self-Hosted-Setups bereits eine sehr starke Basis.

13. Fazit

SSH-Härtung auf Ubuntu ist vor allem eine Frage sauberer Grundlagen: Schlüssel statt Passwörter, kein Root-Login, klare Benutzer- und Netzbeschränkung und Änderungen nur mit Sicherheitsnetz. Genau diese wenigen Punkte bringen in der Praxis am meisten.

Wenn du zusätzlich Tailscale, VPN oder feste AllowLists nutzt, wird SSH deutlich robuster und ruhiger betreibbar als mit einem offen erreichbaren Standard-Setup.

Tipp:
Wenn du heute nur einen einzigen Schritt umsetzen willst, dann richte zuerst Schlüsselzugang sauber ein und deaktiviere danach Passwortanmeldung. Das ist oft der stärkste unmittelbare Sicherheitsgewinn.