SSH-Härtung in der Praxis: Server sicher erreichbar machen

SSH ist der Standardzugang zu Linux-Servern – und damit ein bevorzugtes Angriffsziel. Im Internet erreichbare Server verzeichnen binnen Minuten Login-Versuche. Die folgenden Maßnahmen sind bewährt, in wenigen Minuten umgesetzt und machen den größten Teil des Risikos zunichte.

Vorbereitung: nicht aussperren

Faustregel: Änderungen an der SSH-Konfiguration erst in einer zweiten, offenen Sitzung testen. Läuft die neue Konfiguration, bleibt die alte Verbindung bestehen; schlägt sie fehl, kann man korrigieren. Zuvor Konfiguration sichern:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sshd -t          # Syntax prüfen, BEVOR neu gestartet wird

Schritt 1: Schlüssel statt Passwort

ssh-keygen -t ed25519 -C "admin@notebook"
ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server

# Kontrolle: passwortloses Login
ssh -i ~/.ssh/id_ed25519 benutzer@server true

ed25519 ist der empfohlene Schlüsseltyp: kurze Schlüssel, starke Sicherheit. Der private Schlüssel verlässt niemals den eigenen Rechner und gehört auf ~/.ssh/ mit Rechten 600. Der Schlüssel kann zusätzlich eine Passphrase tragen.

Schritt 2: Passwortanmeldung und Root sperren

Ein Blick in /etc/ssh/sshd_config – oder besser in eine eigene Datei unter /etc/ssh/sshd_config.d/, die per Include geladen wird:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 20
AllowUsers benutzer
ClientAliveInterval 300
ClientAliveCountMax 2

AllowUsers beschränkt den Zugang auf ausdrücklich genannte Konten. Wichtig ist, dass alle benötigten Nutzer dort stehen – sonst sperrt man sich aus.

sudo sshd -t
sudo systemctl reload ssh    # oder: sshd

Ein reload reicht; bestehende Verbindungen bleiben erhalten.

Schritt 3: Rechte kontrollieren

SSH ist streng: Bei falschen Rechten verweigert es die Schlüssel-Anmeldung – ein häufiger und schwer zu findender Fehler.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

Schritt 4: Brute-Force bremsen

fail2ban liest die Protokolle und sperrt IP-Adressen nach zu vielen Fehlversuchen zeitweise aus.

sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Ergänzend kann der SSH-Port verlegt werden. Das ist kein Sicherheitsgewinn, sondern reduziert nur das Rauschen im Protokoll – der Schutz kommt aus Schlüsseln, nicht aus einem ungewohnten Port.

Schritt 5: Prüfen

# Passwort-Anmeldung muss scheitern
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no benutzer@server

# Aushandlung ansehen
ssh -vvv benutzer@server 2>&1 | head -40

# Wer ist eingeloggt?
who; last -n 10

Für Server, die nur über einen Sprungrechner erreichbar sein sollen, sind Match-Blöcke oder eine AllowUsers-Beschränkung auf die Sprung-Adresse sinnvoll.

Siehe auch