SSH ist die Eingangstür zu Ihrem Server. Automatisierte Bots beginnen innerhalb von Minuten nach dem Start eines VPS, Port 22 anzugreifen. Diese Anleitung führt Sie durch jede sshd_config-Änderung, die nötig ist, um SSH auf Debian 12 (OpenSSH 9.2) und Ubuntu 24.04 (OpenSSH 9.6) abzusichern -- mit einem Verifizierungsschritt nach jeder Änderung, damit Sie wissen, dass es funktioniert hat.

Voraussetzungen

Sie benötigen:

Einen VPS mit Debian 12 oder Ubuntu 24.04 (frisch installiert oder bestehend)
Einen Nicht-Root-Benutzer mit sudo-Zugriff
Ein zweites Terminal oder eine zweite SSH-Sitzung zum Server (Sie brauchen dies, um Änderungen zu testen, ohne sich auszusperren)

Diese Anleitung ist Teil der Serie Linux VPS Security: Bedrohungen, Schutzschichten und Hardening-Guide. Nach der SSH-Härtung hier richten Sie automatisierten Brute-Force-Schutz ein mit Fail2Ban auf einem Linux-VPS installieren und konfigurieren.

Wie generiere ich einen sicheren SSH-Schlüssel für meinen VPS?

Generieren Sie einen Ed25519-Schlüssel auf Ihrem lokalen Rechner (Ihrem Laptop oder Ihrer Workstation, nicht dem Server). Ed25519 erzeugt einen 256-Bit-Schlüssel mit 128 Bit Sicherheit, gleichwertig mit RSA-3072, bei schnellerer Generierung und Verifizierung. Die Signaturen sind deterministisch und haengen nicht von einem Zufallszahlengenerator beim Signieren ab. Das eliminiert eine ganze Klasse von Implementierungsangriffen, die RSA betreffen.

ssh-keygen -t ed25519 -C "yourname@yourmachine"

Sie sehen eine Ausgabe wie diese:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/yourname/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/yourname/.ssh/id_ed25519
Your public key has been saved in /home/yourname/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xR5xGk3TOs4mEfW8sBv7g7LkE2PLxYae2TqfGxpfM3Q yourname@yourmachine

Setzen Sie eine Passphrase. Falls jemand Ihre private Schlüsseldatei stiehlt, ist die Passphrase das Einzige zwischen ihm und Ihren Servern.

Ed25519 vs RSA: Welchen Schlüssel sollte ich verwenden?

	Ed25519	RSA-4096
Schlüsselgröße	256 Bits	4096 Bits
Sicherheitsstärke	~128 Bits	~140 Bits
Schlüsselgenerierung	Sofort	1-5 Sekunden
Signaturverifizierung	Schneller	Langsamer
Private Schlüsseldatei	464 Bytes	~3,3 KB
RNG-Abhängigkeit beim Signieren	Nein (deterministisch)	Ja
Kompatibilität	OpenSSH 6.5+ (2014)	Universal

Verwenden Sie Ed25519, es sei denn, Sie müssen sich mit Systemen verbinden, die OpenSSH älter als 6.5 verwenden -- was 2026 selten ist.

Öffentlichen Schlüssel auf den Server kopieren

Von Ihrem lokalen Rechner:

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@your-server-ip

Falls ssh-copy-id nicht verfügbar ist (einige macOS-Installationen), kopieren Sie manuell:

cat ~/.ssh/id_ed25519.pub | ssh youruser@your-server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Verifizierung: Melden Sie sich von einem neuen Terminal per Schlüsselauthentifizierung an:

ssh -i ~/.ssh/id_ed25519 youruser@your-server-ip

Wenn Sie eine Shell erhalten, ohne Ihr Serverpasswort einzugeben (nur Ihre Schlüssel-Passphrase), funktioniert die Schlüsselauthentifizierung.

Die Include-Direktive verstehen

Bevor Sie sshd_config bearbeiten, beachten Sie Folgendes: Sowohl Debian 12 als auch Ubuntu 24.04 liefern Include /etc/ssh/sshd_config.d/*.conf am Anfang von /etc/ssh/sshd_config aus. OpenSSH verwendet den ersten gefundenen Wert für die meisten Direktiven. Jede .conf-Datei in sshd_config.d/ hat Vorrang vor Einstellungen in der Hauptdatei.

Prüfen Sie, was bereits gesetzt ist:

ls -la /etc/ssh/sshd_config.d/

Auf Ubuntu 24.04 finden Sie typischerweise 50-cloud-init.conf, wenn cloud-init aktiv ist. Lesen Sie alle vorhandenen Dateien, bevor Sie Änderungen vornehmen:

cat /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Wir legen unsere Härtungskonfiguration in einer einzelnen Datei ab, die zuerst geladen wird:

sudo touch /etc/ssh/sshd_config.d/00-hardening.conf
sudo chmod 600 /etc/ssh/sshd_config.d/00-hardening.conf

Das Präfix 00- stellt sicher, dass unsere Datei vor anderen Konfigurations-Snippets gelesen wird. chmod 600 beschränkt den Lesezugriff auf root, da diese Datei steuert, wer sich anmelden kann.

Alle sshd_config-Änderungen in dieser Anleitung kommen in /etc/ssh/sshd_config.d/00-hardening.conf, sofern nicht anders angegeben.

Wie deaktiviere ich die SSH-Passwortauthentifizierung?

Das Deaktivieren der Passwortauthentifizierung erzwingt ausschließlich schlüsselbasierte Anmeldung. Brute-Force-Angriffe werden sinnlos, da es kein Passwort zum Erraten gibt.

Öffnen Sie die Härtungskonfiguration:

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

Fügen Sie hinzu:

PasswordAuthentication no
KbdInteractiveAuthentication no

KbdInteractiveAuthentication ersetzt das veraltete ChallengeResponseAuthentication in OpenSSH 9.x. Deaktivieren Sie beides, um alle passwortbasierten Anmeldewege zu schließen.

Bevor Sie sshd neu starten, validieren Sie immer die Konfiguration und lassen Sie Ihre aktuelle Sitzung offen.

sudo sshd -t

Wenn keine Ausgabe erscheint, ist die Konfiguration gültig. Fehler werden im Terminal angezeigt.

Starten Sie sshd nun neu:

sudo systemctl restart sshd

Verifizierung von einem zweiten Terminal (schließen Sie Ihre aktuelle Sitzung nicht):

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@your-server-ip

Sie sollten Folgendes sehen:

youruser@your-server-ip: Permission denied (publickey).

Das bestätigt, dass die Passwortauthentifizierung deaktiviert ist. Achten Sie genau auf die Ausgabe: Es steht (publickey) als einzige erlaubte Methode. Genau das wollen wir.

Bestätigen Sie nun, dass die Schlüsselanmeldung vom selben zweiten Terminal noch funktioniert:

ssh youruser@your-server-ip

Wenn beide Tests bestanden sind, ist die Passwortauthentifizierung deaktiviert und die Schlüsselanmeldung funktioniert. Falls die Schlüsselanmeldung fehlschlägt, gehen Sie zurück zu Ihrer noch offenen ersten Sitzung und korrigieren Sie die Konfiguration, bevor Sie ausgesperrt werden.

Direkter Root-Login über SSH sollte deaktiviert sein. Selbst bei reiner Schlüsselauthentifizierung gibt ein kompromittierter Root-Schlüssel vollen Systemzugriff ohne Audit-Trail, wer sich angemeldet hat. Verwenden Sie stattdessen einen regulaeren Benutzer mit sudo.

Fügen Sie zu /etc/ssh/sshd_config.d/00-hardening.conf hinzu:

PermitRootLogin no

Validieren und neu starten:

sudo sshd -t && sudo systemctl restart sshd

Verifizierung von einem zweiten Terminal:

ssh root@your-server-ip

Erwartete Ausgabe:

root@your-server-ip: Permission denied (publickey).

Verifizieren Sie die Einstellung mit sshd -T (Großbuchstabe T gibt die laufende Konfiguration aus):

sudo sshd -T | grep -i permitrootlogin

permitrootlogin no

Wie beschränke ich den SSH-Zugriff auf bestimmte Benutzer und Gruppen?

AllowUsers und AllowGroups beschränken die SSH-Anmeldung auf eine explizite Liste. Jeder, der nicht auf der Liste steht, wird abgewiesen -- selbst mit gültigen Schlüsseln. Das ist ein Sicherheitsnetz gegen versehentliche Schlüsselverteilung oder neue Benutzer, die von Paketen angelegt werden.

Fügen Sie zu /etc/ssh/sshd_config.d/00-hardening.conf hinzu:

AllowUsers youruser

Ersetzen Sie youruser durch Ihren tatsächlichen Benutzernamen. Für mehrere Benutzer:

AllowUsers youruser deployer

Alternativ können Sie gruppenbasierten Zugriff verwenden (besser für Teams):

sudo groupadd sshusers
sudo usermod -aG sshusers youruser

Dann in der Konfiguration:

AllowGroups sshusers

Verarbeitungsreihenfolge

OpenSSH wertet den Zugriff in dieser Reihenfolge aus: DenyUsers, AllowUsers, DenyGroups, AllowGroups. Ein Deny auf jeder Stufe blockiert den Benutzer. Wenn Sie AllowUsers verwenden, können sich nur gelistete Benutzer anmelden. Wenn Sie AllowGroups verwenden, können sich nur Mitglieder der gelisteten Gruppen anmelden. Sie können beides kombinieren, aber AllowUsers wird zuerst geprüft.

Validieren und neu starten:

sudo sshd -t && sudo systemctl restart sshd

Verifizierung von einem zweiten Terminal:

ssh youruser@your-server-ip

Bestätigen Sie, dass sich Ihr Benutzer noch anmelden kann. Verifizieren Sie dann, dass ein nicht gelisteter Benutzer abgewiesen wird:

sudo sshd -T | grep -i allowusers

allowusers youruser

Welche SSH-Sitzungslimits sollte ich setzen?

Diese Direktiven begrenzen Authentifizierungsversuche, Verbindungs-Timeouts und nicht authentifizierte Verbindungen. Sie verlangsamen Brute-Force-Angriffe und räumen inaktive Sitzungen auf.

Fügen Sie zu /etc/ssh/sshd_config.d/00-hardening.conf hinzu:

MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

Hier ist die Bedeutung jeder Einstellung:

Direktive	Wert	Effekt
MaxAuthTries	3	Trennt die Verbindung nach 3 fehlgeschlagenen Authentifizierungsversuchen pro Verbindung
LoginGraceTime	20	Gibt 20 Sekunden zur Authentifizierung, bevor die Verbindung getrennt wird
MaxStartups	10:30:60	Nach 10 nicht authentifizierten Verbindungen werden 30 % der neuen zufällig abgelehnt. Bei 60 werden alle neuen Verbindungen abgelehnt.
MaxSessions	3	Maximal 3 gemultiplexte Sitzungen pro Verbindung
ClientAliveInterval	300	Sendet alle 300 Sekunden (5 Minuten) ein Keepalive-Paket
ClientAliveCountMax	2	Trennt die Verbindung nach 2 unbeantworteten Keepalive-Antworten

ClientAliveInterval-Berechnung: Das tatsächliche Idle-Timeout ist ClientAliveInterval x ClientAliveCountMax. Mit diesen Werten: 300 x 2 = 600 Sekunden = 10 Minuten. Eine inaktive Sitzung wird nach 10 Minuten ohne Antwort getrennt.

Validieren und neu starten:

sudo sshd -t && sudo systemctl restart sshd

Verifizierung:

sudo sshd -T | grep -E "maxauthtries|logingracetime|maxstartups|maxsessions|clientaliveinterval|clientalivecountmax"

maxauthtries 3
logingracetime 20
maxstartups 10:30:60
maxsessions 3
clientaliveinterval 300
clientalivecountmax 2

Unnötige Weiterleitungsfunktionen deaktivieren

Weiterleitungsfunktionen (Forwarding) vergrößern die Angriffsfläche von SSH. Deaktivieren Sie alles, was Sie nicht aktiv nutzen.

Fügen Sie zu /etc/ssh/sshd_config.d/00-hardening.conf hinzu:

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

Validieren und neu starten:

sudo sshd -t && sudo systemctl restart sshd

Verifizierung:

sudo sshd -T | grep -E "allowagentforwarding|allowtcpforwarding|x11forwarding|permittunnel"

allowagentforwarding no
allowtcpforwarding no
x11forwarding no
permittunnel no

Warum sollte ich SSH Agent Forwarding deaktivieren?

Agent Forwarding erlaubt einem Remote-Server, Ihre lokalen SSH-Schlüssel zu verwenden, um sich bei anderen Servern zu authentifizieren. Das klingt praktisch, um zwischen Maschinen zu wechseln. Das Problem: Jeder mit Root-Zugriff auf diesem Remote-Server kann Ihren Agent-Socket kapern und Ihre Schlüssel verwenden.

Das Angriffsszenario:

Sie aktivieren Agent Forwarding und verbinden sich per SSH mit Server A.
OpenSSH erstellt einen Socket unter /tmp/ssh-XXXX/agent.YYYY auf Server A.
Ein Angreifer mit Root-Zugriff auf Server A liest die Umgebungsvariable SSH_AUTH_SOCK aus Ihrer Sitzung.
Der Angreifer verbindet sich über diesen Socket: SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.YYYY ssh user@server-b.
Server B sieht eine gültige Authentifizierung mit Ihrem Schlüssel. Der Angreifer ist drin.

Der Angreifer hat Ihren privaten Schlüssel nie berührt. Er brauchte nur Root-Zugriff auf dem Zwischenserver, während Ihre Sitzung aktiv war.

Verwenden Sie stattdessen ProxyJump (nächster Abschnitt). Es bietet denselben Multi-Hop-Zugang, ohne Ihren Agent-Socket einem Zwischenserver preiszugeben.

Wie konfiguriere ich SSH ProxyJump für den Bastion-Host-Zugang?

ProxyJump leitet Ihre SSH-Verbindung über einen Jump Host (Bastion) weiter, ohne Agent Forwarding. Ihre Schlüssel verlassen nie Ihren lokalen Rechner. Die Verbindung ist Ende-zu-Ende verschlüsselt: Der Bastion sieht nur verschlüsselten Datenverkehr.

Kommandozeilennutzung

ssh -J jumpuser@bastion.example.com targetuser@10.0.1.50

Das -J-Flag weist SSH an, sich zuerst mit dem Bastion zu verbinden und dann zum Ziel durchzutunneln. Sie können mehrere Spruenge mit Kommas verketten:

ssh -J jump1@bastion1,jump2@bastion2 targetuser@10.0.1.50

SSH-Konfigurationsdatei einrichten

Für regelmäßige Nutzung fügen Sie Einträge zu ~/.ssh/config auf Ihrem lokalen Rechner hinzu:

Host bastion
    HostName bastion.example.com
    User jumpuser
    IdentityFile ~/.ssh/id_ed25519

Host internal-app
    HostName 10.0.1.50
    User appuser
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Host internal-db
    HostName 10.0.2.100
    User dbadmin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Verbinden Sie sich nun direkt mit internen Servern:

ssh internal-app

SSH handhabt den Bastion-Hop automatisch.

Den Bastion-Server härten

Beschränken Sie auf dem Bastion-Host, was Jump-Benutzer tun können. Fügen Sie zur sshd_config des Bastion hinzu:

Match User jumpuser
    PermitTTY no
    X11Forwarding no
    PermitTunnel no
    ForceCommand /usr/sbin/nologin
    AllowTcpForwarding yes

Dies erlaubt TCP-Forwarding (notwendig für ProxyJump), verhindert aber, dass der Jump-Benutzer eine Shell erhält, Befehle ausführt oder X11 nutzt. Falls der Bastion kompromittiert wird, erhält der Angreifer ein Forwarding-Only-Konto ohne Shell-Zugang.

Welche SSH-Cipher und Schlüsseltauschalgorithmen sind sicher?

Standard-Cipher-Listen in OpenSSH enthalten Algorithmen, die für Rückwärtskompatibilität beibehalten werden. Das Entfernen schwacher Algorithmen reduziert Ihre Angriffsfläche. Diese Empfehlungen zielen auf OpenSSH 9.2+ (Debian 12) und 9.6+ (Ubuntu 24.04).

Generieren Sie zuerst die Host-Schlüssel mit Ed25519 neu und entfernen Sie DSA- oder ECDSA-Schlüssel:

sudo rm -f /etc/ssh/ssh_host_*key*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

Wir behalten einen RSA-Host-Schlüssel für Clients, die Ed25519 nicht unterstützen (selten, aber es vermeidet Aussperrungen).

Als Nächstes entfernen Sie schwache Diffie-Hellman-Moduli (Gruppen kleiner als 3072 Bit):

sudo awk '$5 >= 3071' /etc/ssh/moduli > /tmp/moduli.safe
sudo mv /tmp/moduli.safe /etc/ssh/moduli
sudo chown root:root /etc/ssh/moduli
sudo chmod 644 /etc/ssh/moduli

Fügen Sie zu /etc/ssh/sshd_config.d/00-hardening.conf hinzu:

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Kategorie	Algorithmen	Hinweise
Schlüsseltausch	sntrup761x25519, curve25519, DH group16/18	sntrup761 ist ein Post-Quantum-Hybrid. curve25519 ist der aktuelle Standard.
Cipher	ChaCha20-Poly1305, AES-256-GCM, AES-128-GCM, AES-CTR	ChaCha20 zuerst: schneller in Software ohne AES-NI. GCM ist authentifizierte Verschlüsselung.
MACs	HMAC-SHA2 ETM, UMAC-128 ETM	Nur ETM (Encrypt-then-MAC). Nicht-ETM-Modi sind schwächer.
Host-Schlüssel	Ed25519, RSA (SHA-2)	Kein DSA (gebrochen). Kein ECDSA (Vertrauensbedenken bei NIST-Kurven).

Validieren und neu starten:

sudo sshd -t && sudo systemctl restart sshd

Verifizieren Sie von einem zweiten Terminal, dass Sie sich noch verbinden können. Falls Ihr SSH-Client keinen dieser Algorithmen unterstützt (sehr alter Client), erhalten Sie einen << no matching cipher >>-Fehler. Aktualisieren Sie in diesem Fall Ihren Client oder fügen Sie den benötigten Algorithmus vorübergehend wieder hinzu.

Verbergen Sie Ihre SSH-Versionsinformationen und zeigen Sie ein rechtliches Warnbanner an:

sudo nano /etc/ssh/banner.txt

Authorized access only. All activity is monitored and logged.

Halten Sie es kurz. Lange Banner mit Systeminformationen helfen Angreifern, Ihr Betriebssystem zu identifizieren.

Fügen Sie zu /etc/ssh/sshd_config.d/00-hardening.conf hinzu:

Banner /etc/ssh/banner.txt
DebianBanner no

DebianBanner no entfernt den Debian/Ubuntu-Versionsstring aus dem SSH-Protokollbanner. Versionsoffenlegung hilft Angreifern, bekannte Schwachstellen für Ihren spezifischen OpenSSH-Build anzugreifen.

Validieren und neu starten:

sudo sshd -t && sudo systemctl restart sshd

Verifizierung von Ihrem lokalen Rechner:

ssh -v youruser@your-server-ip 2>&1 | grep "banner"

Vollständige gehärtete sshd_config-Referenz

Hier ist die vollständige /etc/ssh/sshd_config.d/00-hardening.conf mit allen Einstellungen aus dieser Anleitung:

# Authentication
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# Access control
AllowUsers youruser

# Session limits
MaxAuthTries 3
LoginGraceTime 20
MaxStartups 10:30:60
MaxSessions 3
ClientAliveInterval 300
ClientAliveCountMax 2

# Forwarding restrictions
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Cryptography
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

# Banner
Banner /etc/ssh/banner.txt
DebianBanner no

# Logging
LogLevel VERBOSE

LogLevel VERBOSE zeichnet zusaetzliche Details auf, einschliesslich der Schlüsselfingerabdruecke, die zur Authentifizierung verwendet werden. Nützlich, um zu prüfen, wer sich mit welchem Schlüssel angemeldet hat.

Validieren Sie nach dem Schreiben dieser Datei immer vor dem Neustart:

sudo sshd -t && sudo systemctl restart sshd

Prüfen Sie die vollständige effektive Konfiguration:

sudo sshd -T

Dies gibt jede aktive Einstellung aus, einschliesslich Standardwerte. Filtern Sie mit grep nach bestimmten Werten:

sudo sshd -T | grep -E "permitrootlogin|passwordauthentication|allowusers"

permitrootlogin no
passwordauthentication no
allowusers youruser

Wie verifiziere ich meine SSH-Härtung mit ssh-audit?

ssh-audit scannt Ihren Server und bewertet jeden Algorithmus als gut, Warnung oder fehlgeschlagen. Führen Sie es nach der Härtung aus, um zu bestätigen, dass alles besteht.

Installieren Sie es auf Ihrem lokalen Rechner oder einem separaten Server (nicht dem Ziel):

pip3 install ssh-audit

Oder mit apt auf Debian/Ubuntu:

sudo apt update && sudo apt install -y ssh-audit

Scannen Sie Ihren Server:

ssh-audit your-server-ip

Mit der Härtung aus dieser Anleitung sollten Sie keine [fail]-Einträge sehen. Die Ausgabe beginnt mit der erkannten OpenSSH-Version, dann werden die Algorithmuskategorien aufgelistet:

# general
(gen) banner: SSH-2.0-OpenSSH_9.6
(gen) software: OpenSSH 9.6
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com  -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256                   -- [info] available since OpenSSH 7.4
...

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com       -- [info] available since OpenSSH 6.5
(enc) aes256-gcm@openssh.com              -- [info] available since OpenSSH 6.2
...

Falls Sie [fail]-Einträge sehen, prüfen Sie, ob Ihre 00-hardening.conf geladen wird (denken Sie an die Include-Reihenfolge) und dass keine andere Datei in sshd_config.d/ Ihre Einstellungen überschreibt.

ssh-audit hat auch integrierte Härtungsanleitungen:

ssh-audit --list-hardening-guides

Fehlerbehebung

Ich habe mich ausgesperrt

Falls Sie sich nach einer Konfigurationsaenderung nicht per SSH anmelden können:

Verwenden Sie die Webkonsole Ihres VPS-Anbieters (KVM/VNC), um sich direkt anzumelden.
Korrigieren Sie /etc/ssh/sshd_config.d/00-hardening.conf.
Führen Sie sshd -t zur Validierung aus.
Neustart: systemctl restart sshd.

Deshalb sagen wir: Schließen Sie nie Ihre funktionierende Sitzung, bevor Sie von einem zweiten Terminal getestet haben.

sshd startet nach Konfigurationsaenderung nicht

sudo sshd -t

Dies gibt die exakte Zeile und Datei mit dem Fehler aus. Häufige Probleme:

Tippfehler in einem Algorithmusnamen (keine Leerzeichen in den kommaseparierten Listen erlaubt)
Doppelte Direktiven in mehreren Dateien (prüfen Sie sshd_config.d/ und die Haupt-sshd_config)
AllowUsers mit einem Benutzernamen, der nicht existiert (sshd startet, aber niemand kann sich anmelden)

Verbindung abgelehnt nach Cipher-Härtung

Ihr lokaler SSH-Client unterstützt möglicherweise die konfigurierten Cipher nicht. Prüfen Sie, welche Cipher Ihr Client unterstützt:

ssh -Q cipher

Vergleichen Sie mit der Serverliste. Fügen Sie den Cipher, den Ihr Client benötigt, wieder hinzu, oder aktualisieren Sie Ihren Client.

SSH-Logs prüfen

sudo journalctl -u sshd -f

Beobachten Sie die Logs in Echtzeit, während Sie von einem anderen Terminal eine Verbindung versuchen. Authentifizierungsfehler, Konfigurationsfehler und Verbindungsabbrueche erscheinen hier.

Prüfen, welche Konfigurationsdatei eine Direktive setzt

sudo sshd -T | grep passwordauthentication

Falls der Wert nicht mit Ihrer Einstellung übereinstimmt, überschreibt eine andere Datei in sshd_config.d/ Ihre Konfiguration. Dateien werden in alphabetischer Reihenfolge geladen. Unsere 00-hardening.conf wird zuerst geladen und gewinnt daher bei den meisten Direktiven. Prüfen Sie aber, ob cloud-init oder andere Verwaltungstools eigene Konfigurationen schreiben.

Verifizierungs-Checkliste

Gehen Sie diese nach Abschluss aller Härtungsschritte durch:

Passwortauthentifizierung deaktiviert: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@server gibt << Permission denied >> zurück
Root-Login deaktiviert: ssh root@server gibt << Permission denied >> zurück
Schlüsselauthentifizierung funktioniert: ssh youruser@server gibt Ihnen eine Shell
AllowUsers aktiv: sudo sshd -T | grep allowusers zeigt Ihren Benutzer
Sitzungslimits gesetzt: sudo sshd -T | grep maxauthtries zeigt 3
Forwarding deaktiviert: sudo sshd -T | grep allowagentforwarding zeigt no
Nur starke Cipher: ssh-audit server-ip zeigt keine [fail]-Einträge
Logs funktionieren: sudo journalctl -u sshd -n 20 zeigt aktuelle Authentifizierungseinträge

Nach der SSH-Härtung richten Sie Fail2Ban auf einem Linux-VPS installieren und konfigurieren ein, um IPs automatisch zu sperren, die die Authentifizierung nicht bestehen. Für SSH-Zugriffskontrolle auf Netzwerkebene siehe Linux-VPS-Firewall mit UFW und nftables einrichten.