Sicherheit Schwierigkeit: Einsteiger

SSH-Zugang absichern

Schlüssel-Login statt Passwort und root-Login sperren: die wichtigsten Handgriffe, um die Eingangstür zu deinem Server zu härten.

14.07.2026 · 5 Min. Lesezeit ·Dauer: ca. 20 Minuten

Inhaltsverzeichnis

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 10.0p2 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:

Terminal

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:

Ausgabe

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

Danach folgt noch das „randomart image", eine kleine ASCII-Grafik des Fingerprints – die kannst du ignorieren. Wichtig sind die 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:

Terminal

ssh-copy-id koch@DEINE_SERVER_IP

Hier fragt der Server ein letztes Mal nach dem Passwort des Benutzers – danach nicht mehr:

Ausgabe

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/DEIN_BENUTZER/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
koch@DEINE_SERVER_IP's password:

Number of key(s) added: 1

Number of key(s) added: 1 ist die Erfolgsmeldung. Beim zweiten Aufruf kommt stattdessen WARNING: All keys were skipped because they already exist on the remote system. – dann liegt der Schlüssel bereits dort. Teste direkt danach, dass der Schlüssel-Login funktioniert:

Terminal

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.

Öffne die SSH-Server-Konfiguration:

Terminal

sudo nano /etc/ssh/sshd_config

Setze (bzw. entkommentiere) diese beiden Zeilen:

Ausgabe

PermitRootLogin no
PasswordAuthentication no

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

Achtung

Auf Cloud-Images liegen unter /etc/ssh/sshd_config.d/ oft Zusatzdateien, die diese Einstellungen überschreiben. Prüfe mit grep -r PasswordAuthentication /etc/ssh/sshd_config.d/ und passe Treffer ebenfalls an.

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:

Terminal

sudo sshd -t

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

Terminal

sudo systemctl restart ssh

Vorsicht

Teste den Schlüssel-Login jetzt in einer zweiten Terminal-Sitzung, bevor du die erste schließt – sonst sperrst du dich womöglich aus.

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

SSH fragt trotz ssh-copy-id weiter nach dem Passwort. Meist stimmen die Dateirechte auf dem Server nicht: SSH ignoriert authorized_keys, wenn Gruppe oder andere in ~/.ssh schreiben dürfen. Im Log auf dem Server (sudo journalctl -u ssh --since -5min) steht dann Authentication refused: bad ownership or modes for directory /home/koch/.ssh. Repariere mit chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys und prüfe außerdem, dass du dich mit dem richtigen Benutzer verbindest (koch@…, nicht root@…).

Permission denied (publickey) – und du kommst gar nicht mehr rein. 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.

Nach dem Neustart startet der SSH-Dienst nicht mehr. Syntaxfehler in der sshd_config – ein verschriebenes PasswordAuthentification genügt (deshalb immer sshd -t vor dem Neustart). Über die VNC-Konsole einloggen, dann nennt sudo sshd -t Datei, Zeile und Option: /etc/ssh/sshd_config: line 125: Bad configuration option: PasswordAuthentification gefolgt von /etc/ssh/sshd_config: terminating, 1 bad configuration options.

Einstellungen scheinen zu greifen, Passwort-Login geht aber weiterhin. 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. Die einzelnen Verbindungen protokolliert OpenSSH 10 unter dem Namen sshd-session, etwa als Connection closed by authenticating user root 203.0.113.10 port 50718 [preauth]. Fehlversuche auf Port 22 sind normal und dank Schlüssel-Pflicht harmlos – automatisch aussperren kannst du solche Bots später mit Fail2ban.
Updates: OpenSSH bekommt seine Sicherheitsupdates über das normale apt upgrade – halte den Server also aktuell, am besten automatisiert.