SSH-Haertung Linux-VPS: sshd_config Sicherheitsguide

SSH ist die Eingangstuer zu Ihrem Server. Automatisierte Bots beginnen innerhalb von Minuten nach dem Start eines VPS, Port 22 anzugreifen. Diese Anleitung fuehrt Sie durch jede sshd_config-Aenderung, die noetig ist, um SSH auf Debian 12 (OpenSSH 9.2) und Ubuntu 24.04 (OpenSSH 9.6) abzusichern -- mit einem Verifizierungsschritt nach jeder Aenderung, damit Sie wissen, dass es funktioniert hat.

Voraussetzungen

Sie benoetigen:

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 Aenderungen zu testen, ohne sich auszusperren)

Diese Anleitung ist Teil der Serie Linux VPS Security: Threats, Layers, and Hardening Guide. Nach der SSH-Haertung hier richten Sie automatisierten Brute-Force-Schutz ein mit .

Wie generiere ich einen sicheren SSH-Schluessel fuer meinen VPS?

Generieren Sie einen Ed25519-Schluessel auf Ihrem lokalen Rechner (Ihrem Laptop oder Ihrer Workstation, nicht dem Server). Ed25519 erzeugt einen 256-Bit-Schluessel 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 Schluesseldatei stiehlt, ist die Passphrase das Einzige zwischen ihm und Ihren Servern.

Ed25519 vs RSA: Welchen Schluessel sollte ich verwenden?

	Ed25519	RSA-4096
Schluesselgroesse	256 Bits	4096 Bits
Sicherheitsstaerke	~128 Bits	~140 Bits
Schluesselgenerierung	Sofort	1-5 Sekunden
Signaturverifizierung	Schneller	Langsamer
Private Schluesseldatei	464 Bytes	~3,3 KB
RNG-Abhaengigkeit beim Signieren	Nein (deterministisch)	Ja
Kompatibilitaet	OpenSSH 6.5+ (2014)	Universal

Verwenden Sie Ed25519, es sei denn, Sie muessen sich mit Systemen verbinden, die OpenSSH aelter als 6.5 verwenden -- was 2026 selten ist.

Oeffentlichen Schluessel 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 verfuegbar 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 Schluesselauthentifizierung an:

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

Wenn Sie eine Shell erhalten, ohne Ihr Serverpasswort einzugeben (nur Ihre Schluessel-Passphrase), funktioniert die Schluesselauthentifizierung.

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 fuer die meisten Direktiven. Jede .conf-Datei in sshd_config.d/ hat Vorrang vor Einstellungen in der Hauptdatei.

Pruefen 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 Aenderungen vornehmen:

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

Wir legen unsere Haertungskonfiguration 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 Praefix 00- stellt sicher, dass unsere Datei vor anderen Konfigurations-Snippets gelesen wird. chmod 600 beschraenkt den Lesezugriff auf root, da diese Datei steuert, wer sich anmelden kann.

Alle sshd_config-Aenderungen 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 ausschliesslich schluesselbasierte Anmeldung. Brute-Force-Angriffe werden sinnlos, da es kein Passwort zum Erraten gibt.

Oeffnen Sie die Haertungskonfiguration:

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

Fuegen Sie hinzu:

PasswordAuthentication no
KbdInteractiveAuthentication no

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

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 gueltig. Fehler werden im Terminal angezeigt.

Starten Sie sshd nun neu:

sudo systemctl restart sshd

Verifizierung von einem zweiten Terminal (schliessen 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 bestaetigt, dass die Passwortauthentifizierung deaktiviert ist. Achten Sie genau auf die Ausgabe: Es steht (publickey) als einzige erlaubte Methode. Genau das wollen wir.

Bestaetigen Sie nun, dass die Schluesselanmeldung vom selben zweiten Terminal noch funktioniert:

ssh youruser@your-server-ip

Wenn beide Tests bestanden sind, ist die Passwortauthentifizierung deaktiviert und die Schluesselanmeldung funktioniert. Falls die Schluesselanmeldung fehlschlaegt, gehen Sie zurueck zu Ihrer noch offenen ersten Sitzung und korrigieren Sie die Konfiguration, bevor Sie ausgesperrt werden.

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

Fuegen 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 (Grossbuchstabe T gibt die laufende Konfiguration aus):

sudo sshd -T | grep -i permitrootlogin

permitrootlogin no

Wie beschraenke ich den SSH-Zugriff auf bestimmte Benutzer und Gruppen?

AllowUsers und AllowGroups beschraenken die SSH-Anmeldung auf eine explizite Liste. Jeder, der nicht auf der Liste steht, wird abgewiesen -- selbst mit gueltigen Schluesseln. Das ist ein Sicherheitsnetz gegen versehentliche Schluesselverteilung oder neue Benutzer, die von Paketen angelegt werden.

Fuegen Sie zu /etc/ssh/sshd_config.d/00-hardening.conf hinzu:

AllowUsers youruser

Ersetzen Sie youruser durch Ihren tatsaechlichen Benutzernamen. Fuer mehrere Benutzer:

AllowUsers youruser deployer

Alternativ koennen Sie gruppenbasierten Zugriff verwenden (besser fuer 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, koennen sich nur gelistete Benutzer anmelden. Wenn Sie AllowGroups verwenden, koennen sich nur Mitglieder der gelisteten Gruppen anmelden. Sie koennen beides kombinieren, aber AllowUsers wird zuerst geprueft.

Validieren und neu starten:

sudo sshd -t && sudo systemctl restart sshd

Verifizierung von einem zweiten Terminal:

ssh youruser@your-server-ip

Bestaetigen 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 raeumen inaktive Sitzungen auf.

Fuegen 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 zufaellig 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 tatsaechliche 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

Unnoetige Weiterleitungsfunktionen deaktivieren

Weiterleitungsfunktionen (Forwarding) vergroessern die Angriffsflaeche von SSH. Deaktivieren Sie alles, was Sie nicht aktiv nutzen.

Fuegen 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-Schluessel 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 Schluessel 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 ueber diesen Socket: SSH_AUTH_SOCK=/tmp/ssh-XXXX/agent.YYYY ssh user@server-b.
Server B sieht eine gueltige Authentifizierung mit Ihrem Schluessel. Der Angreifer ist drin.

Der Angreifer hat Ihren privaten Schluessel nie beruehrt. Er brauchte nur Root-Zugriff auf dem Zwischenserver, waehrend Ihre Sitzung aktiv war.

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

Wie konfiguriere ich SSH ProxyJump fuer den Bastion-Host-Zugang?

ProxyJump leitet Ihre SSH-Verbindung ueber einen Jump Host (Bastion) weiter, ohne Agent Forwarding. Ihre Schluessel verlassen nie Ihren lokalen Rechner. Die Verbindung ist Ende-zu-Ende verschluesselt: Der Bastion sieht nur verschluesselten 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 koennen mehrere Spruenge mit Kommas verketten:

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

SSH-Konfigurationsdatei einrichten

Fuer regelmaessige Nutzung fuegen Sie Eintraege 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 haerten

Beschraenken Sie auf dem Bastion-Host, was Jump-Benutzer tun koennen. Fuegen 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 fuer ProxyJump), verhindert aber, dass der Jump-Benutzer eine Shell erhaelt, Befehle ausfuehrt oder X11 nutzt. Falls der Bastion kompromittiert wird, erhaelt der Angreifer ein Forwarding-Only-Konto ohne Shell-Zugang.

Welche SSH-Cipher und Schluesseltauschalgorithmen sind sicher?

Standard-Cipher-Listen in OpenSSH enthalten Algorithmen, die fuer Rueckwaertskompatibilitaet beibehalten werden. Das Entfernen schwacher Algorithmen reduziert Ihre Angriffsflaeche. Diese Empfehlungen zielen auf OpenSSH 9.2+ (Debian 12) und 9.6+ (Ubuntu 24.04).

Generieren Sie zuerst die Host-Schluessel mit Ed25519 neu und entfernen Sie DSA- oder ECDSA-Schluessel:

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-Schluessel fuer Clients, die Ed25519 nicht unterstuetzen (selten, aber es vermeidet Aussperrungen).

Als Naechstes 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

Fuegen 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
Schluesseltausch	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 Verschluesselung.
MACs	HMAC-SHA2 ETM, UMAC-128 ETM	Nur ETM (Encrypt-then-MAC). Nicht-ETM-Modi sind schwaecher.
Host-Schluessel	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 koennen. Falls Ihr SSH-Client keinen dieser Algorithmen unterstuetzt (sehr alter Client), erhalten Sie einen << no matching cipher >>-Fehler. Aktualisieren Sie in diesem Fall Ihren Client oder fuegen Sie den benoetigten Algorithmus voruebergehend 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.

Fuegen 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 fuer 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"

Vollstaendige gehaertete sshd_config-Referenz

Hier ist die vollstaendige /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 Schluesselfingerabdruecke, die zur Authentifizierung verwendet werden. Nuetzlich, um zu pruefen, wer sich mit welchem Schluessel angemeldet hat.

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

sudo sshd -t && sudo systemctl restart sshd

Pruefen Sie die vollstaendige 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-Haertung mit ssh-audit?

ssh-audit scannt Ihren Server und bewertet jeden Algorithmus als gut, Warnung oder fehlgeschlagen. Fuehren Sie es nach der Haertung aus, um zu bestaetigen, 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 Haertung aus dieser Anleitung sollten Sie keine [fail]-Eintraege 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]-Eintraege sehen, pruefen 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 ueberschreibt.

ssh-audit hat auch integrierte Haertungsanleitungen:

ssh-audit --list-hardening-guides

Fehlerbehebung

Ich habe mich ausgesperrt

Falls Sie sich nach einer Konfigurationsaenderung nicht per SSH anmelden koennen:

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

Deshalb sagen wir: Schliessen 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. Haeufige Probleme:

Tippfehler in einem Algorithmusnamen (keine Leerzeichen in den kommaseparierten Listen erlaubt)
Doppelte Direktiven in mehreren Dateien (pruefen 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-Haertung

Ihr lokaler SSH-Client unterstuetzt moeglicherweise die konfigurierten Cipher nicht. Pruefen Sie, welche Cipher Ihr Client unterstuetzt:

ssh -Q cipher

Vergleichen Sie mit der Serverliste. Fuegen Sie den Cipher, den Ihr Client benoetigt, wieder hinzu, oder aktualisieren Sie Ihren Client.

SSH-Logs pruefen

sudo journalctl -u sshd -f

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

Pruefen, welche Konfigurationsdatei eine Direktive setzt

sudo sshd -T | grep passwordauthentication

Falls der Wert nicht mit Ihrer Einstellung uebereinstimmt, ueberschreibt 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. Pruefen Sie aber, ob cloud-init oder andere Verwaltungstools eigene Konfigurationen schreiben.

Verifizierungs-Checkliste

Gehen Sie diese nach Abschluss aller Haertungsschritte durch:

Passwortauthentifizierung deaktiviert: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@server gibt << Permission denied >> zurueck
Root-Login deaktiviert: ssh root@server gibt << Permission denied >> zurueck
Schluesselauthentifizierung 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]-Eintraege
Logs funktionieren: sudo journalctl -u sshd -n 20 zeigt aktuelle Authentifizierungseintraege

Nach der SSH-Haertung richten Sie ein, um IPs automatisch zu sperren, die die Authentifizierung nicht bestehen. Fuer SSH-Zugriffskontrolle auf Netzwerkebene siehe .

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfaeltigung, Wiederveroeffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.