SSH-Zugang absichern

Nach der Ersteinrichtung sichern wir den SSH-Zugang ab – die wichtigste Tür zu deinem Server.

Was bauen wir?

Am Ende meldest du dich per SSH-Schlüssel statt mit Passwort an, und weder root-Login noch Passwort-Login sind von außen möglich. Damit laufen die automatisierten Passwort-Rate-Angriffe, die jeden öffentlich erreichbaren Server rund um die Uhr treffen, komplett ins Leere. Getestet mit OpenSSH auf Debian 13.

Voraussetzungen

• Ein eingerichteter Server mit sudo-Benutzer
• Zugriff auf die VNC-Konsole im netcup SCP als Rettungsanker, falls du dich aussperrst

Schritt für Schritt

Schritt 1: SSH-Schlüsselpaar erzeugen

Falls du noch keinen Schlüssel hast, erzeuge auf deinem eigenen Rechner (nicht auf dem Server!) ein Ed25519-Schlüsselpaar:

ssh-keygen -t ed25519

Die Vorschläge für Speicherort kannst du mit Enter übernehmen. Vergib eine Passphrase – sie schützt den Schlüssel, falls dein Rechner in fremde Hände gerät. Es entstehen zwei Dateien: ~/.ssh/id_ed25519 (privat, bleibt bei dir) und ~/.ssh/id_ed25519.pub (öffentlich, kommt auf den Server).

Schritt 2: Öffentlichen Schlüssel übertragen

ssh-copy-id hängt deinen öffentlichen Schlüssel an die Datei ~/.ssh/authorized_keys deines Server-Benutzers – mit den korrekten Dateirechten:

ssh-copy-id koch@DEINE_SERVER_IP

Teste direkt danach, dass der Schlüssel-Login funktioniert:

ssh koch@DEINE_SERVER_IP

Du solltest jetzt ohne Server-Passwort eingeloggt werden (nur die Passphrase deines Schlüssels wird ggf. abgefragt). Erst wenn das klappt, geht es weiter – im nächsten Schritt schalten wir den Passwort-Login ab.

Schritt 3: Passwort-Login und root-Login deaktivieren

Öffne die SSH-Server-Konfiguration:

sudo nano /etc/ssh/sshd_config

Setze (bzw. entkommentiere) diese beiden Zeilen:

PermitRootLogin no
PasswordAuthentication no

PermitRootLogin no sperrt den direkten root-Login komplett, PasswordAuthentication no lässt nur noch Schlüssel-Logins zu.

Schritt 4: Konfiguration testen und SSH neu starten

Prüfe die Konfiguration auf Syntaxfehler, bevor du neu startest – ein Tippfehler würde sonst den SSH-Dienst lahmlegen:

sudo sshd -t

Keine Ausgabe bedeutet: alles in Ordnung. Dann übernehmen:

sudo systemctl restart ssh

Zur Kontrolle: sudo systemctl status ssh sollte active (running) zeigen, und ein Login-Versuch als root muss jetzt mit Permission denied (publickey) abgewiesen werden.

Wenn es nicht funktioniert

Symptom: SSH fragt trotz ssh-copy-id weiter nach dem Passwort

Ursache & Lösung: Meist stimmen die Dateirechte auf dem Server nicht. SSH ignoriert authorized_keys, wenn die Rechte zu offen sind: chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys. Prüfe außerdem, dass du dich mit dem richtigen Benutzer verbindest (koch@…, nicht root@…).

Symptom: Permission denied (publickey) – und du kommst gar nicht mehr rein

Ursache & Lösung: Passwort-Login wurde deaktiviert, bevor der Schlüssel funktionierte. Kein Drama: Öffne die VNC-Konsole im netcup SCP, melde dich dort lokal an, setze PasswordAuthentication yes, starte SSH neu und beginne wieder bei Schritt 2.

Symptom: Nach dem Neustart startet der SSH-Dienst nicht mehr

Ursache & Lösung: Syntaxfehler in der sshd_config (deshalb immer sshd -t vor dem Neustart). Über die VNC-Konsole einloggen, sudo sshd -t zeigt dir Datei und Zeilennummer des Fehlers.

Symptom: Einstellungen scheinen zu greifen, Passwort-Login geht aber weiterhin

Ursache & Lösung: Eine Datei unter /etc/ssh/sshd_config.d/ (häufig 50-cloud-init.conf) überschreibt deine Werte. sudo sshd -T | grep -i passwordauthentication zeigt die tatsächlich wirksame Einstellung – Treffer in den Zusatzdateien anpassen und SSH neu starten.

Wartung & Backups

• Privaten Schlüssel sichern: Ohne ~/.ssh/id_ed25519 kommst du nur noch über die VNC-Konsole auf den Server. Sichere den Schlüssel verschlüsselt (z. B. im Passwortmanager) oder hinterlege einen zweiten Schlüssel von einem anderen Gerät in authorized_keys.
• Logins im Blick behalten: sudo journalctl -u ssh --since today zeigt dir alle Login-Versuche. Fehlversuche auf Port 22 sind normal und dank Schlüssel-Pflicht harmlos.
• Updates: OpenSSH bekommt seine Sicherheitsupdates über das normale apt upgrade – halte den Server also aktuell (siehe Ersteinrichtung).