Admin-Benutzer erstellen und sudo prüfen.
Linux Security
Debian SSH-Hardening ohne Aussperren
SSH ist auf Root-Servern der wichtigste administrative Eingang. Dieser Guide zeigt,
wie du SSH unter Debian sicher härtest, ohne dich selbst vom Server auszusperren:
neuer Admin-User, SSH-Keys, sichere sshd_config, Testsession, Reload,
Rollback und Logprüfung.
Grundsatz
Nie SSH härten, ohne eine zweite Session offen zu halten.
Der häufigste Fehler beim SSH-Hardening ist nicht eine falsche Direktive, sondern ein schlechter Ablauf: Man ändert die Konfiguration, startet SSH neu und merkt erst dann, dass der eigene Zugang nicht mehr funktioniert. Deshalb gilt: Eine bestehende Root- oder Admin-Session bleibt offen, bis der neue Login erfolgreich getestet wurde.
SSH-Key hinterlegen und Login testen.
sshd_config ändern und mit sshd -t validieren.
SSH reloaden, neue Session testen, alte Session erst danach schließen.
Vorbereitung
Admin-User erstellen.
Direktes Arbeiten als Root ist bequem, aber unnötig riskant. Besser ist ein eigener Admin-Benutzer mit sudo-Rechten. Der Root-Account bleibt für Notfälle vorhanden, aber nicht direkt per SSH erreichbar.
User anlegen und sudo aktivieren
adduser adminuser
usermod -aG sudo adminuser
su - adminuser
sudo whoami
Wenn sudo whoami sauber root ausgibt, funktioniert die
Rechtevergabe grundsätzlich.
SSH-Key
Keys statt Passwörter.
Passwort-Logins sind bei öffentlich erreichbaren Servern unnötige Angriffsfläche. Der sichere Standard ist Public-Key-Authentifizierung mit einem modernen Key.
Key auf deinem Admin-Rechner erzeugen
ssh-keygen -t ed25519 -a 100 -C "admin@digital-world.dev"
ssh-copy-id adminuser@SERVER-IP
Key-Rechte prüfen
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R adminuser:adminuser ~/.ssh
Sichere SSH-Konfiguration
Minimal sinnvolle Baseline.
Die konkrete Konfiguration hängt von Umgebung und Zugriffskonzept ab. Für viele Debian-Server ist diese Baseline ein stabiler Ausgangspunkt.
/etc/ssh/sshd_config
Empfohlene Direktiven.
SSH-Hardening-Baseline
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers adminuser
AllowUsers ist stark, aber auch riskant, wenn du den Benutzernamen falsch
schreibst. Deshalb erst testen, dann alte Session schließen.
Validierung
Konfiguration testen, bevor du reloadest.
SSH bietet eine eingebaute Syntaxprüfung. Nutze sie immer, bevor du den Dienst neu lädst. Ein Tippfehler in der Config darf nicht zum Ausfall des Admin-Zugangs führen.
Syntax prüfen und reloaden
sshd -t
systemctl reload ssh
systemctl status ssh --no-pager
Auf manchen Systemen heißt der Dienst sshd statt ssh.
Prüfe das mit systemctl status ssh oder systemctl status sshd.
Testsession
Neue Verbindung testen.
Öffne ein neues Terminal und teste den Login mit dem neuen Benutzer. Die alte Session bleibt offen, bis der neue Zugriff erfolgreich ist.
Login prüfen
ssh -i ~/.ssh/id_ed25519 adminuser@SERVER-IP
sudo whoami
exit
Erst wenn dieser Test erfolgreich war, kannst du die alte Root-Session schließen.
Rollback
Wenn etwas schiefgeht.
Ein sauberer Rollback beginnt vor der Änderung. Lege eine Kopie der SSH-Konfiguration an. Wenn der neue Login nicht funktioniert, kannst du die alte Konfiguration aus der noch offenen Session wiederherstellen.
cp -av /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
cp -av /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sshd -t
systemctl reload ssh
Logging & Kontrolle
Nach dem Hardening prüfen, was passiert.
SSH-Härtung ist nicht fertig, nur weil der Login funktioniert. Danach prüfst du Logs, fehlgeschlagene Logins und den Zustand des Dienstes.
SSH-Service-Logs
journalctl -u ssh --since "24 hours ago"
Fehlversuche finden
grep "Failed password" /var/log/auth.log
Dienst prüfen
systemctl status ssh --no-pager
Listener anzeigen
ss -tulpen | grep ssh
SSH-Port kontrollieren
nft list ruleset
ufw status verbose
Brute Force sichtbar machen
cscli alerts list
fail2ban-client status sshd
Typische Fehler
Was dich schnell aussperrt.
Diese Fehler passieren häufig, sind aber vermeidbar, wenn du strukturiert arbeitest.
Alte Session zu früh geschlossen
Niemals die bestehende Session schließen, bevor der neue Login erfolgreich getestet wurde.
AllowUsers falsch gesetzt
Ein Tippfehler im Benutzernamen reicht, um legitime Logins zu blockieren.
Key-Rechte falsch
Falsche Rechte auf ~/.ssh oder authorized_keys führen dazu,
dass SSH den Key ignoriert.
Firewall vergessen
SSH kann korrekt laufen, aber durch Firewall, Provider-Regel oder Security Group blockiert sein.
Restart statt Reload
Ein Reload ist meist sicherer als ein harter Restart. Vorher immer sshd -t.
Kein Rettungsweg
Bei Root-Servern sollte klar sein, wie du über Rescue-System, Konsole oder Provider-Zugang zurückkommst.
Vor Änderung
- Backup der sshd_config erstellen
- Zweite Session offen halten
- Admin-User und sudo prüfen
- SSH-Key-Login testen
Während Änderung
- Root-Login deaktivieren
- Passwortlogin deaktivieren
- AllowUsers vorsichtig setzen
- sshd -t ausführen
Nach Änderung
- systemctl reload ssh
- Neue Session testen
- sudo erneut prüfen
- Logs kontrollieren
Fazit
SSH-Hardening ist ein Ablauf, kein einzelner Schalter.
Wer strukturiert vorgeht, kann SSH deutlich härten, ohne unnötiges Risiko. Entscheidend sind Testsession, Key-Login, validierte Konfiguration, Rollback und Kontrolle.