SSH Key erstellen und Server absichern

Passwörter sind die größte Schwachstelle bei SSH-Zugängen. In diesem Tutorial generierst du ein SSH-Key-Paar, überträgst es auf deinen Server und härtest die Konfiguration so, dass nur noch Key-basierter Login möglich ist.

Warum SSH Keys statt Passwörter?

Jeder Server mit offenem SSH-Port wird innerhalb von Minuten automatisiert angegriffen. Bots scannen das Internet rund um die Uhr nach offenen SSH-Ports und probieren gängige Benutzernamen und Passwörter durch. Passwörter können erraten, abgefangen oder per Brute-Force geknackt werden. Egal wie stark sie sind, sie bleiben ein einzelner Faktor, der über das Netzwerk übertragen wird.

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. Das BSI empfiehlt in der Technischen Richtlinie TR-02102-4 Key-basierte Authentifizierung als Standard für alle SSH-Zugänge.

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 bietet mit 256 Bit Schlüssellänge ein vergleichbares Sicherheitsniveau wie RSA mit 3072 Bit, bei deutlich kürzeren Keys und schnellerer Verarbeitung. Sowohl das BSI als auch Mozilla empfehlen ED25519 als Standard-Algorithmus. RSA ist nur noch nötig, wenn du dich mit Systemen vor 2014 (vor OpenSSH 6.5) verbinden 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 unbedingt 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 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. Den darfst du bedenkenlos teilen, er kommt auf den Server.

Prüfe die Dateiberechtigungen. SSH verweigert den Login, 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 und sicherste Weg ist 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. SSH verweigert den Login außerdem, wenn ~/.ssh/ oder authorized_keys für andere Benutzer lesbar sind. Die Berechtigungen (700 für das Verzeichnis, 600 für authorized_keys) sind zwingend. Falsche Berechtigungen sind die häufigste Ursache für SSH-Probleme.

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, dass Angreifer den Benutzernamen "root" erraten können. 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 die restriktivste 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 starte den SSH-Dienst neu:

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

# SSH-Dienst neu starten
sudo systemctl restart sshd

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 entscheidend: Sie beweist, dass 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. Neuere Ubuntu-Versionen 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 die Logdateien, 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
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 für neuere Systeme: Ab Ubuntu 22.04 und Debian 12 nutzen viele Installationen systemd-journald statt klassischer Logdateien. Falls /var/log/auth.log 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 wirst du überrascht sein, wie schnell die ersten gesperrten IPs auftauchen. Das zeigt, wie aktiv automatisierte Angriffe 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.