SSH Key erstellen und Server absichern

Passwort-Logins sind bei öffentlich erreichbaren SSH-Zugängen ein häufiger Angriffspunkt. In diesem Tutorial generierst du ein SSH-Key-Paar, überträgst es auf deinen Server und härtest die Konfiguration so, dass Key-basierter Login der Normalfall wird.

Warum SSH Keys statt Passwörter?

Jeder Server mit offenem SSH-Port kann sehr schnell automatisierte Login-Versuche sehen. Bots scannen das Internet rund um die Uhr nach offenen SSH-Ports und probieren gängige Benutzernamen und Passwörter durch. SSH überträgt Passwörter zwar nicht im Klartext, aber ein Passwort bleibt ein einzelnes Geheimnis: Es kann erraten, wiederverwendet, durch Phishing abgegriffen oder aus anderen Leaks ausprobiert werden.

SSH-Keys lösen dieses Problem durch asymmetrische Verschlüsselung: Ein mathematisch verknüpftes Schlüsselpaar ersetzt das Passwort. Der private Key bleibt auf deinem Rechner, der öffentliche Key kommt auf den Server. Beim Login beweist dein Client kryptographisch, dass er den passenden privaten Key besitzt, ohne ihn jemals über das Netzwerk zu schicken. Selbst wenn ein Angreifer den gesamten Netzwerkverkehr mitlesen würde, könnte er den privaten Key nicht rekonstruieren. Die BSI-Richtlinie TR-02102-4 beschreibt Public-Key-Authentisierung als empfohlene Authentisierungsmethode im SSH-Kontext.

SSH-Key-Paar generieren

Öffne ein Terminal auf deinem lokalen Rechner (nicht auf dem Server!) und führe folgenden Befehl aus:

ssh-keygen -t ed25519 -C "dein.name@beispiel.de"

Der Parameter -t ed25519 wählt den Algorithmus. ED25519 basiert auf elliptischen Kurven und ist bei aktuellen OpenSSH-Versionen ein sinnvoller Standard für neue Benutzer-Keys. OpenSSH erzeugt inzwischen auch ohne explizite Option standardmäßig Ed25519-Keys; RSA bleibt relevant, wenn du mit älteren SSH-Implementierungen oder organisatorischen Vorgaben arbeiten musst.

-C setzt einen Kommentar, der später im Public Key steht. Verwende deine E-Mail-Adresse, damit du den Key später zuordnen kannst, wenn du mehrere hast.

Du wirst nach einem Speicherort gefragt. Drücke Enter für den Standard (~/.ssh/id_ed25519). Dann wirst du nach einer Passphrase gefragt.

Setze für produktiv genutzte Keys eine Passphrase. Sie verschlüsselt deinen privaten Key auf der Festplatte. Ohne Passphrase kann jeder, der Zugriff auf die Datei bekommt (Malware, gestohlener Laptop, ungesichertes Backup), sofort deinen Key verwenden. Die Passphrase ist deine zweite Verteidigungslinie: Selbst wenn jemand die Datei kopiert, kann er den Key nicht ohne Weiteres nutzen.

Die erwartete Ausgabe:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/azubi/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/azubi/.ssh/id_ed25519
Your public key has been saved in /home/azubi/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123... dein.name@beispiel.de

Zwei Dateien wurden erzeugt: ~/.ssh/id_ed25519 ist dein privater Key. Diese Datei darfst du niemals weitergeben, nicht auf einen Server kopieren und nicht in ein Git-Repository einchecken. ~/.ssh/id_ed25519.pub ist dein öffentlicher Key. Er ist nicht geheim und kommt auf den Server, sollte aber trotzdem nur dort landen, wo du ihn wirklich brauchst, weil er Rückschlüsse auf deine Identitäten oder Systeme zulassen kann.

Prüfe die Dateiberechtigungen. OpenSSH kann den Login verweigern, wenn sie zu offen sind:

chmod 700 ~/.ssh              # Nur du darfst in das Verzeichnis
chmod 600 ~/.ssh/id_ed25519   # Privater Key: nur du darfst lesen
chmod 644 ~/.ssh/id_ed25519.pub  # Public Key: alle dürfen lesen

Public Key auf den Server kopieren

Der öffentliche Key muss auf den Server, damit dieser deinen Client bei der Authentifizierung erkennt. Der einfachste Weg auf Linux/macOS ist häufig ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@dein-server.de

Du wirst ein letztes Mal nach dem Server-Passwort gefragt. Das Tool kopiert deinen Public Key automatisch in die Datei ~/.ssh/authorized_keys auf dem Server und setzt die richtigen Dateiberechtigungen. Danach kannst du dich mit deinem Key einloggen:

ssh benutzer@dein-server.de
# Keine Passwort-Abfrage mehr, nur noch die Key-Passphrase

Falls ssh-copy-id nicht verfügbar ist (z.B. unter Windows ohne WSL), kopiere den Key manuell:

# Public Key anzeigen und kopieren
cat ~/.ssh/id_ed25519.pub

# Auf dem Server: Verzeichnis anlegen und Key einfügen
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "DEIN_PUBLIC_KEY_HIER" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Wichtig: Der Key muss in einer einzigen Zeile stehen. Wenn dein Editor ihn umbricht, schlägt die Authentifizierung fehl. OpenSSH kann Logins außerdem verweigern, wenn Home-Verzeichnis, ~/.ssh/ oder authorized_keys zu offen beschreibbar sind. Die Berechtigungen 700 für das Verzeichnis und 600 für authorized_keys sind eine bewährte sichere Vorgabe.

SSH-Konfiguration härten

Jetzt kommt der wichtigste Teil: Die SSH-Konfiguration auf dem Server so anpassen, dass nur noch Key-basierte Authentifizierung erlaubt ist. Öffne die SSH-Konfiguration:

sudo nano /etc/ssh/sshd_config

Suche und ändere folgende Zeilen. Die Einstellungen basieren auf den Mozilla OpenSSH Guidelines und den BSI-Empfehlungen:

# Passwort-Login deaktivieren
PasswordAuthentication no

# Root-Login verbieten
PermitRootLogin no

# Nur Key-Authentifizierung erlauben
PubkeyAuthentication yes

# Challenge-Response deaktivieren (wird oft vergessen!)
KbdInteractiveAuthentication no

# Leere Passwörter verbieten
PermitEmptyPasswords no

# Nur bestimmte Benutzer erlauben (anpassen!)
AllowUsers dein-benutzername

# Maximale Anmeldeversuche pro Verbindung
MaxAuthTries 3

# Idle-Timeout: Verbindung nach Inaktivität trennen
ClientAliveInterval 300
ClientAliveCountMax 2

Jede Einstellung hat einen konkreten Zweck: PermitRootLogin no verhindert direkte Root-Anmeldungen, sodass der bekannte Benutzername root nicht mehr für SSH-Logins genutzt werden kann. KbdInteractiveAuthentication no ist besonders wichtig: Manche SSH-Konfigurationen akzeptieren über diesen Mechanismus trotz deaktiviertem Passwort-Login noch Passwörter, ein häufig übersehenes Einfallstor. AllowUsers ist eine restriktive Methode: Nur explizit aufgeführte Benutzer dürfen sich überhaupt per SSH einloggen.

Achtung, kritischer Schritt: Schließe die aktuelle SSH-Verbindung NICHT, bevor du in einem zweiten Terminal getestet hast, ob der Key-Login funktioniert! Wenn du dich aussperrst und kein Passwort-Login mehr möglich ist, brauchst du Zugang über die KVM-Konsole deines Hosters.

Prüfe zuerst die Konfiguration auf Syntaxfehler, dann lade den SSH-Dienst neu:

# Konfiguration auf Fehler prüfen (keine Ausgabe = kein Fehler)
sudo sshd -t

# SSH-Dienst neu laden oder neu starten
sudo systemctl reload sshd || sudo systemctl reload ssh

Jetzt in einem neuen Terminalfenster testen (das alte nicht schließen!):

# Test 1: Key-Login muss funktionieren
ssh benutzer@dein-server.de

# Test 2: Gegenkontrolle, Passwort-Login muss abgelehnt werden
ssh -o PubkeyAuthentication=no benutzer@dein-server.de
# Erwartete Ausgabe: Permission denied (publickey).

Die Gegenkontrolle ist wichtig: Sie zeigt, ob Passwort-Login tatsächlich deaktiviert ist. Erst wenn beide Tests bestanden sind, kannst du die alte SSH-Sitzung schließen. Prüfe zusätzlich, ob Include-Dateien deine Einstellungen überschreiben. Viele aktuelle Ubuntu/Debian-Installationen laden Konfigurationen aus /etc/ssh/sshd_config.d/:

# Alle aktiven SSH-Einstellungen prüfen
sudo sshd -T | grep passwordauthentication
# Erwartete Ausgabe: passwordauthentication no

Fail2Ban gegen Brute-Force einrichten

Auch mit deaktiviertem Passwort-Login versuchen Angreifer ständig, sich per SSH einzuloggen. Das erzeugt Last auf dem Server und füllt die Logs. Fail2Ban überwacht Logdateien oder das systemd-Journal, erkennt wiederholte fehlgeschlagene Login-Versuche und sperrt die IP-Adressen automatisch über die Firewall.

# Fail2Ban installieren
sudo apt update && sudo apt install -y fail2ban

# Lokale Konfiguration erstellen (wird bei Updates nicht überschrieben)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Im Abschnitt [sshd] diese Werte setzen:

[sshd]
enabled = true
port = ssh
filter = sshd
# Debian/Ubuntu mit klassischer Auth-Logdatei:
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Nach 3 fehlgeschlagenen Login-Versuchen innerhalb von 10 Minuten (findtime = 600) wird die IP für 1 Stunde gesperrt (bantime = 3600). Für Produktionsserver kannst du bantime auf 86400 (24 Stunden) erhöhen.

Hinweis zu Logs: Der passende Logpfad hängt von Distribution und Logging-Setup ab. Debian/Ubuntu nutzen häufig /var/log/auth.log, RHEL/Fedora-Familien eher /var/log/secure, und manche Installationen lesen über systemd-journald. Falls die Logdatei nicht existiert, setze in der Jail-Konfiguration backend = systemd und entferne die logpath-Zeile. Fail2Ban liest die SSH-Logs dann direkt aus dem Journal.

Aktiviere Fail2Ban und starte den Dienst:

sudo systemctl enable fail2ban && sudo systemctl start fail2ban

# Status und gesperrte IPs prüfen
sudo fail2ban-client status sshd

Auf einem frisch eingerichteten Server kannst du schnell erste gesperrte IPs sehen. Das zeigt, wie aktiv automatisierte Login-Versuche auf SSH-Ports sind.

Häufige Fehler

SSH-Probleme sind frustrierend, weil die Fehlermeldungen oft kryptisch sind. Hier die häufigsten Fehler mit konkreten Lösungen:

Bei hartnäckigen Problemen hilft der Verbose-Modus: ssh -vvv benutzer@dein-server.de zeigt exakt, an welchem Punkt die Authentifizierung scheitert: ob der Key angeboten wird, ob der Server ihn akzeptiert, und welche Methoden verfügbar sind. Die OpenSSH-Dokumentation beschreibt alle Debug-Optionen im Detail.

Was du nach diesem Tutorial kannst

Wenn du die Schritte oben durchlaufen hast, hast du den grundlegenden Workflow zur SSH-Absicherung eines Linux-Servers geübt. Konkret kannst du jetzt:

• Ein modernes ED25519-Key-Paar generieren und sicher mit Passphrase schützen.
• Den Public Key per ssh-copy-id oder manuell auf einen Server übertragen und die Datei-Berechtigungen korrekt setzen.
• Die sshd_config härten: Passwort-Login deaktivieren, Root-Login verbieten, Challenge-Response sperren.
• Die Konfiguration vor dem Schließen der alten Sitzung sicher testen, ohne dich aus deinem Server auszusperren.
• Wiederholte fehlgeschlagene Login-Versuche mit Fail2Ban automatisiert blockieren.
• Typische SSH-Fehler wie Permission denied (publickey) oder REMOTE HOST IDENTIFICATION HAS CHANGED systematisch lösen.

Damit hast du einen wichtigen Basisbaustein der Linux-Administration abgehakt. Auf einem produktiven Server kommen weitere Themen dazu: Updates, Firewall, Backups, Monitoring, Rechtekonzept, Diensthärtung und saubere Wiederherstellungstests.

Nächster Schritt: Linux & Server-Administration

SSH-Hardening ist nur ein Baustein der Server-Administration unter Linux. Wenn du dich systematisch in das Thema einarbeiten willst, sind das die nächsten sinnvollen Schritte:

• Linux-Befehle: Übersicht mit Beispielen: alle Kommandos, die du für den Umgang mit der Konfiguration brauchst, von chmod über systemctl bis journalctl.
• Lexikon-Eintrag SSH: kompakte Begriffsdefinition, falls du Begriffe wie Public/Private Key oder asymmetrische Verschlüsselung im Detail nachschlagen willst.

Wenn du die Schritte erst üben willst, nutze eine lokale VM oder eine kleine Testinstanz, nicht deinen produktiven Server. Für geführte Übung mit Aufgaben und Wiederholung ist die Lernplattform der passende nächste Schritt.

Technische Quellen

• BSI TR-02102-4: Kryptographische Verfahren für SSH
• Mozilla: OpenSSH Guidelines
• OpenSSH: Manual Pages
• OpenBSD Manual: ssh-keygen(1)
• Linux man-pages: sshd_config(5)