Passwörter sind die schwächste Stelle jedes Servers. Automatisierte Bots scannen rund um die Uhr das Internet nach offenen SSH-Diensten auf Port 22 und probieren in Sekunden tausende Standardpasswörter durch. Ein einziger erfolgreicher Treffer reicht, und der Angreifer hat eine Shell auf Ihrem System. Die Lösung ist seit Jahren bekannt und in der Praxis kompromisslos wirksam: ein SSH-Key statt eines Passworts. Diese Anleitung führt Sie in 10 nachvollziehbaren Schritten von der Schlüsselerzeugung bis zum vollständig gehärteten OpenSSH-Server. Sie brauchen dafür rund 30 Minuten und keine Vorkenntnisse über Kryptographie.

Wir arbeiten mit OpenSSH, dem De-facto-Standard auf Linux, macOS und seit Jahren auch Windows. Jeder Befehl ist getestet, jede Konfigurationszeile erklärt. Am Ende steht ein komplettes, kopierbares Beispielprojekt: ein Ubuntu- oder Debian-Server, der nur noch Schlüssel akzeptiert, Root-Logins ablehnt, Brute-Force-Versuche aussperrt und den quantenresistenten Schlüsselaustausch nutzt, den aktuelle OpenSSH-Versionen seit Ende 2024 standardmäßig mitbringen.

Warum SSH-Key-Authentifizierung 2026 zur Pflicht wird

Ein SSH-Key besteht aus einem mathematisch verknüpften Schlüsselpaar: einem privaten Schlüssel, der Ihren Rechner nie verlässt, und einem öffentlichen Schlüssel, den Sie auf beliebig vielen Servern hinterlegen. Beim Login beweist Ihr Client kryptographisch den Besitz des privaten Schlüssels, ohne ihn jemals zu übertragen. Es gibt kein Geheimnis, das über die Leitung wandert, und damit nichts, was ein Angreifer abfangen oder erraten könnte. Ein moderner Ed25519-Schlüssel hat eine effektive Stärke von 128 Bit. Ein Brute-Force-Angriff dagegen ist mit klassischer Rechenleistung praktisch ausgeschlossen.

Die Bedrohungslage spricht eine deutliche Sprache. In Österreich registrierte die Polizei laut Bundeskriminalamt 62.328 Fälle von Cyberkriminalität, und Server mit passwortbasiertem SSH-Zugang gehören zu den ersten Zielen automatisierter Angriffe. Ein frisch aufgesetzter Cloud-Server sieht innerhalb weniger Minuten die ersten Login-Versuche fremder IP-Adressen. Wer Passwortanmeldung erlaubt, setzt darauf, dass keiner dieser Versuche jemals erfolgreich ist. Wer auf SSH-Keys umstellt, nimmt diese Wette ganz vom Tisch.

Ein zweiter Grund ist Komfort. Nach der Einrichtung melden Sie sich ohne Passworteingabe an, Automatisierung über Skripte und CI/CD-Pipelines funktioniert reibungslos, und Sie verwalten Zugänge zentral über Dateien statt über geteilte Geheimnisse. Ein SSH-Key lässt sich jederzeit einzeln widerrufen, ohne dass andere Nutzer betroffen sind. Diese Anleitung behandelt nicht nur das Anlegen des Schlüssels, sondern die komplette Härtung des Servers, denn ein Schlüssel allein nützt wenig, solange die Passwortanmeldung als Hintertür offen bleibt.

Voraussetzungen: Software-Versionen und Zugänge

Bevor wir starten, stellen Sie sicher, dass folgende Komponenten bereitstehen. Die Versionsangaben beziehen sich auf den Stand Juni 2026. Ältere Versionen funktionieren grundsätzlich auch, aber einige Härtungsoptionen und der quantenresistente Schlüsselaustausch setzen aktuelle Software voraus.

  • Ein Server mit Ubuntu 22.04/24.04 LTS oder Debian 12, erreichbar per SSH (etwa ein vServer, Root-Server oder eine Cloud-Instanz).
  • OpenSSH-Server der aktuellen 9.x- oder 10.x-Reihe. Prüfen mit ssh -V. Ubuntu 24.04 liefert OpenSSH 9.6 oder neuer, die aktuelle Upstream-Reihe ist OpenSSH 10.x (2026).
  • Ein lokaler Rechner mit OpenSSH-Client (Linux, macOS oder Windows 10/11 mit aktiviertem OpenSSH-Client).
  • Ein Benutzerkonto mit sudo-Rechten auf dem Server. Den Root-Login deaktivieren wir später, deshalb brauchen Sie zwingend einen normalen Benutzer.
  • Terminalkenntnisse auf Einsteigerniveau: Sie sollten Befehle eintippen und eine Datei mit nano oder vim bearbeiten können.

Prüfen Sie zuerst die installierte Version auf Client und Server. Der Befehl gibt Versionsnummer und die verwendete Krypto-Bibliothek aus:

# Auf lokalem Rechner und auf dem Server ausführen
ssh -V

# Beispielausgabe:
# OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024

Sollte OpenSSH auf dem Server fehlen, installieren Sie es mit sudo apt update && sudo apt install openssh-server. Halten Sie während der gesamten Einrichtung eine zweite SSH-Sitzung offen. Falls Sie sich durch eine falsche Konfiguration aussperren, retten Sie sich über die noch aktive Verbindung. Diese eine Gewohnheit erspart Ihnen im Ernstfall eine Notfall-Konsole beim Hoster.

Wie SSH-Schlüssel funktionieren: Ed25519 statt RSA

SSH-Keys beruhen auf asymmetrischer Kryptographie. Der private Schlüssel signiert eine vom Server gestellte Challenge, der öffentliche Schlüssel verifiziert diese Signatur. Beide Seiten teilen nie ein gemeinsames Geheimnis, weshalb das Verfahren auch über unsichere Netze sicher bleibt. Die Wahl des Schlüsseltyps entscheidet über Sicherheit und Geschwindigkeit. Seit OpenSSH 8.8 (2021) lehnt der Dienst RSA-Schlüssel mit SHA-1-Signatur grundsätzlich ab, weil SHA-1 als gebrochen gilt. Wer heute neu einrichtet, hat zwei sinnvolle Optionen.

Ed25519 ist die empfohlene Wahl. Der Schlüssel ist kurz, die Erzeugung und Signaturprüfung sind sehr schnell, und die Kurve gilt als robust gegen viele Implementierungsfehler. RSA mit 4096 Bit bleibt sicher, solange SHA-2-Signaturen verwendet werden, ist aber rechenintensiver und produziert deutlich längere Schlüssel. Die folgende Tabelle vergleicht die gängigen Typen.

SchlüsseltypEffektive StärkeLänge öffentl. SchlüsselGeschwindigkeitEmpfehlung 2026
Ed25519~128 Bit~68 ZeichenSehr hochErste Wahl
ECDSA (nistp256)~128 Bit~94 ZeichenHochAkzeptabel
RSA 4096~128 Bit~720 ZeichenMittelNur bei Altsystemen
RSA 2048~112 Bit~380 ZeichenMittelNicht mehr empfohlen
DSAgebrochen––Entfernt, nicht nutzen

DSA-Schlüssel wurden aus aktuellen OpenSSH-Versionen vollständig entfernt und dürfen nicht mehr verwendet werden. Falls Sie noch sehr alte Geräte ansprechen müssen, die kein Ed25519 verstehen, greifen Sie zu RSA 4096. Für alles andere ist Ed25519 die richtige Entscheidung. Wir nutzen es im weiteren Verlauf dieser Anleitung durchgängig.

Schritt 1: SSH-Schlüsselpaar mit ssh-keygen erzeugen

Den ersten echten Arbeitsschritt führen Sie auf Ihrem lokalen Rechner aus, niemals auf dem Server. Der private Schlüssel soll dort bleiben, wo Sie physische Kontrolle haben. Erzeugen Sie das Schlüsselpaar mit ssh-keygen:

# Ed25519-Schlüsselpaar erzeugen
ssh-keygen -t ed25519 -C "[email protected]"

# Ausgabe:
# Generating public/private ed25519 key pair.
# Enter file in which to save the key (/home/sam/.ssh/id_ed25519):
# Enter passphrase (empty for no passphrase):
# Enter same passphrase again:
# Your identification has been saved in /home/sam/.ssh/id_ed25519
# Your public key has been saved in /home/sam/.ssh/id_ed25519.pub

Der Parameter -t ed25519 wählt den Schlüsseltyp, -C setzt einen Kommentar, der den Schlüssel später identifizierbar macht (üblich ist eine E-Mail-Adresse oder ein Gerätename). Bestätigen Sie den vorgeschlagenen Speicherpfad mit der Eingabetaste.

Warum die Passphrase nicht optional ist

Bei der Abfrage nach einer Passphrase sollten Sie nicht einfach Enter drücken. Die Passphrase verschlüsselt Ihren privaten Schlüssel auf der Festplatte. Ohne sie kann jeder, der Zugriff auf Ihre Datei id_ed25519 erlangt, sofort alle Ihre Server übernehmen. Mit Passphrase ist der gestohlene Schlüssel wertlos. Damit Sie die Passphrase nicht bei jedem Login eintippen müssen, übernimmt der SSH-Agent das Zwischenspeichern (dazu später mehr). Wählen Sie eine lange, eindeutige Passphrase, idealerweise aus Ihrem Passwortmanager. Nach der Erzeugung liegen zwei Dateien im Verzeichnis ~/.ssh/:

ls -l ~/.ssh/id_ed25519*

# -rw------- 1 sam sam  464 14. Jun 10:21 id_ed25519       (privat, geheim halten)
# -rw-r--r-- 1 sam sam  103 14. Jun 10:21 id_ed25519.pub   (öffentlich, darf geteilt werden)

Die Datei mit der Endung .pub ist der öffentliche Schlüssel. Nur diese Datei wandert auf den Server. Die Datei ohne Endung ist der private Schlüssel. Geben Sie ihn niemals weiter, laden Sie ihn nicht in Cloud-Speicher und versenden Sie ihn nicht per E-Mail. Die Berechtigung -rw------- (600) auf dem privaten Schlüssel ist Pflicht. Der SSH-Client verweigert sonst die Nutzung.

Schritt 2: Den öffentlichen Schlüssel auf den Server kopieren

Jetzt hinterlegen Sie den öffentlichen Schlüssel auf dem Server. Das komfortabelste Werkzeug dafür ist ssh-copy-id. Es überträgt den Schlüssel und legt ihn mit den korrekten Berechtigungen in der Datei authorized_keys ab. Für diesen einen Vorgang melden Sie sich noch einmal per Passwort an:

# Syntax: ssh-copy-id benutzer@server-ip
ssh-copy-id [email protected]

# Ausgabe:
# Number of key(s) added: 1
# Now try logging into the machine, with:  "ssh '[email protected]'"
# and check to make sure that only the key(s) you wanted were added.

Falls ssh-copy-id auf Ihrem System fehlt (etwa unter Windows), kopieren Sie den Schlüssel manuell. Der folgende Einzeiler hängt Ihren öffentlichen Schlüssel an die richtige Datei an und setzt die Berechtigungen korrekt:

# Manuelle Variante (funktioniert auch ohne ssh-copy-id)
cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Auf dem Server liegt der öffentliche Schlüssel nun in ~/.ssh/authorized_keys. Diese Datei darf mehrere Schlüssel enthalten, einen pro Zeile. So geben Sie mehreren Geräten oder Teammitgliedern Zugang, ohne ein Passwort zu teilen. Die strikten Berechtigungen sind entscheidend: Das Verzeichnis ~/.ssh muss 700 haben, die Datei authorized_keys muss 600 haben. Der SSH-Daemon ignoriert Schlüssel in zu großzügig freigegebenen Dateien aus Sicherheitsgründen stillschweigend.

Schritt 3: Anmeldung mit dem Schlüssel testen

Bevor Sie irgendetwas härten, prüfen Sie, dass der Schlüssel-Login tatsächlich funktioniert. Das ist der wichtigste Test der ganzen Anleitung, denn die folgenden Schritte deaktivieren die Passwortanmeldung. Funktioniert der Schlüssel jetzt nicht, sperren Sie sich aus.

# Verbindung aufbauen
ssh [email protected]

# Bei Passphrase werden Sie lokal danach gefragt, nicht vom Server.
# Erfolgreich, wenn Sie ohne Server-Passwort eine Shell erhalten.

Erhalten Sie eine Shell, ohne dass der Server nach einem Passwort fragt (die Passphrase-Abfrage Ihres lokalen Schlüssels zählt nicht), ist die Schlüsselanmeldung aktiv. Bei Problemen liefert der ausführliche Modus wertvolle Hinweise:

# Ausführliche Diagnose
ssh -v [email protected]

# Achten Sie auf Zeilen wie:
# debug1: Offering public key: /home/sam/.ssh/id_ed25519 ED25519
# debug1: Server accepts key: ...
# Authenticated to 203.0.113.10 using "publickey".

Die Zeile Authenticated ... using "publickey" bestätigt den Erfolg. Steht dort stattdessen using "password", hat der Schlüssel nicht gegriffen, und Sie sollten die Berechtigungen sowie den Pfad prüfen, bevor Sie weitermachen. Erst wenn der Schlüssel-Login sicher klappt, geht es an die Härtung des Servers.

Schritt 4: Die sshd_config sichern und bearbeiten

Die zentrale Konfigurationsdatei des SSH-Servers liegt unter /etc/ssh/sshd_config. Legen Sie zuerst eine Sicherungskopie an, damit Sie jederzeit zurück können:

# Backup der Originalkonfiguration
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

# Datei zur Bearbeitung öffnen
sudo nano /etc/ssh/sshd_config

Moderne Ubuntu- und Debian-Systeme lesen zusätzlich Dateien aus dem Verzeichnis /etc/ssh/sshd_config.d/. Dort abgelegte Einstellungen überschreiben die Hauptdatei. Die sauberste Methode ist deshalb, Ihre Härtung in einer eigenen Datei zu bündeln, etwa /etc/ssh/sshd_config.d/99-haertung.conf. So bleiben Distributions-Updates der Hauptdatei wirkungslos auf Ihre Einstellungen. Tragen Sie folgende Werte ein:

# /etc/ssh/sshd_config.d/99-haertung.conf

# Nur Schlüsselauthentifizierung erlauben
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

# Root-Login verbieten
PermitRootLogin no

# Nur bestimmte Benutzer zulassen
AllowUsers sam

# Strenge Berechtigungsprüfung
StrictModes yes

# Login-Versuche und Sitzungen begrenzen
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 4

Die folgende Tabelle erklärt die wichtigsten Direktiven und ihre Wirkung. Jede einzelne reduziert die Angriffsfläche messbar.

DirektiveEmpfohlener WertWirkung
PasswordAuthenticationnoSchaltet die Passwortanmeldung komplett ab, Brute-Force wird sinnlos
PubkeyAuthenticationyesErlaubt die Schlüsselanmeldung (Standard, explizit bestätigen)
PermitRootLoginnoVerhindert direkten Root-Zugang, erzwingt Umweg über sudo
KbdInteractiveAuthenticationnoSchließt interaktive Passwort-Hintertüren
AllowUsersbenutzernameWhitelist, nur genannte Konten dürfen sich anmelden
MaxAuthTries3Trennt die Verbindung nach drei Fehlversuchen
LoginGraceTime30Zeitfenster in Sekunden für eine erfolgreiche Anmeldung

Schritt 5: Konfiguration prüfen und neu laden

Eine fehlerhafte Konfigurationszeile kann den SSH-Dienst beim Neustart scheitern lassen. Deshalb prüfen Sie die Syntax vor dem Neuladen mit dem eingebauten Testmodus. Der Befehl meldet jede problematische Zeile mit Nummer:

# Syntaxprüfung, gibt bei Fehlern die Zeilennummer aus
sudo sshd -t

# Keine Ausgabe bedeutet: Konfiguration ist gültig.

Meldet der Test keinen Fehler, laden Sie den Dienst neu. Nutzen Sie reload statt restart, denn das Neuladen trennt bestehende Sitzungen nicht. Ihre offene Sicherheitsverbindung bleibt also erhalten:

# Konfiguration neu laden, bestehende Verbindungen bleiben erhalten
sudo systemctl reload ssh

# Status kontrollieren
sudo systemctl status ssh --no-pager

Auf manchen Systemen heißt der Dienst sshd statt ssh. Schlägt der erste Befehl fehl, probieren Sie sudo systemctl reload sshd. Jetzt der entscheidende Test: Öffnen Sie ein neues Terminalfenster (die alte Sitzung behalten Sie offen) und melden Sie sich erneut an. Funktioniert die Schlüsselanmeldung weiterhin und wird die Passworteingabe verweigert, ist die Härtung aktiv. Zur Kontrolle erzwingen Sie testweise einen Passwort-Login, der nun scheitern muss:

# Sollte abgelehnt werden, da Passwortlogin deaktiviert ist
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]

# Erwartete Ausgabe:
# [email protected]: Permission denied (publickey).

Schritt 6: Den Root-Login dauerhaft abschalten

Das Konto root existiert auf jedem Linux-System und ist deshalb das beliebteste Ziel automatisierter Angriffe. Mit PermitRootLogin no aus Schritt 4 haben Sie den direkten Root-Login bereits gesperrt. Verwalten Sie das System ab jetzt ausschließlich über Ihren normalen Benutzer und das Kommando sudo. Das hat zwei Vorteile: Angreifer müssen sowohl den richtigen Benutzernamen erraten als auch einen gültigen Schlüssel besitzen, und jede administrative Aktion landet nachvollziehbar im sudo-Protokoll.

Prüfen Sie, dass Ihr Benutzer tatsächlich sudo-Rechte hat, bevor Sie sich auf das Verbot verlassen. Andernfalls können Sie nach dem Abschalten von Root keine administrativen Aufgaben mehr erledigen:

# sudo-Rechte testen
sudo whoami
# Ausgabe muss "root" sein

# Falls der Benutzer noch keine sudo-Rechte hat (als root ausführen):
# usermod -aG sudo sam

Wenn Sie für Automatisierung doch einen Root-Schlüssel brauchen, etwa für Backups, nutzen Sie statt no den Wert prohibit-password. Damit ist der Root-Login per Passwort verboten, ein hinterlegter Schlüssel funktioniert aber weiterhin. Für die meisten Anwendungsfälle ist das vollständige no die sicherere Wahl. Beschränken Sie zusätzlich die erlaubten Benutzer mit AllowUsers auf genau die Konten, die Zugang brauchen.

Schritt 7: Die Firewall mit UFW konfigurieren

Eine Firewall begrenzt, welche Dienste überhaupt von außen erreichbar sind. Unter Ubuntu und Debian ist ufw (Uncomplicated Firewall) das einfachste Werkzeug. Wichtig: Erlauben Sie den SSH-Port, bevor Sie die Firewall aktivieren, sonst trennen Sie sich selbst von der Verbindung.

# SSH zuerst erlauben (Standardport 22)
sudo ufw allow OpenSSH

# Firewall aktivieren
sudo ufw enable
# Bestätigung mit y

# Status anzeigen
sudo ufw status verbose

Standardmäßig blockiert UFW nun alle eingehenden Verbindungen außer SSH und lässt ausgehende Verbindungen zu. Öffnen Sie weitere Ports nur, wenn Sie sie wirklich brauchen, etwa 80 und 443 für einen Webserver mit sudo ufw allow 80,443/tcp.

Den SSH-Port ändern: sinnvoll oder Sicherheitstheater?

Viele Anleitungen empfehlen, SSH von Port 22 auf einen anderen Port zu verlegen. Das verhindert keinen gezielten Angriff, ein Portscan findet den Dienst in Sekunden. Es reduziert aber spürbar das Grundrauschen automatisierter Bots und damit Ihre Logdateien. Wenn Sie den Port ändern, müssen Sie ihn in der sshd_config und in der Firewall anpassen:

# In /etc/ssh/sshd_config.d/99-haertung.conf ergänzen:
Port 2222

# Firewall anpassen (neuen Port erlauben, alten entfernen)
sudo ufw allow 2222/tcp
sudo ufw delete allow OpenSSH

# Dienst neu laden und mit neuem Port verbinden
sudo systemctl reload ssh
ssh -p 2222 [email protected]

Behandeln Sie die Portänderung als Komfortmaßnahme gegen Logspam, nicht als echten Schutz. Die eigentliche Sicherheit liefern Schlüsselauthentifizierung und deaktivierte Passwörter.

Schritt 8: Brute-Force-Schutz mit Fail2ban ergänzen

Auch wenn Passwortlogins deaktiviert sind, bombardieren Bots Ihren Server weiter mit Verbindungsversuchen. Fail2ban liest die Logdateien, erkennt wiederholte Fehlversuche und sperrt die betreffenden IP-Adressen für einen Zeitraum aus. Das schont Ressourcen und hält die Protokolle übersichtlich. Installation und Grundkonfiguration sind in wenigen Befehlen erledigt:

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

# Lokale Konfiguration anlegen (jail.local überschreibt jail.conf)
sudo nano /etc/fail2ban/jail.local
# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 22
maxretry = 3
findtime = 600
bantime = 3600

Mit diesen Werten sperrt Fail2ban eine IP-Adresse für 3600 Sekunden (eine Stunde), wenn sie innerhalb von 600 Sekunden drei Fehlversuche produziert. Starten Sie den Dienst und prüfen Sie den Status:

# Dienst aktivieren und starten
sudo systemctl enable --now fail2ban

# Status des SSH-Jails anzeigen
sudo fail2ban-client status sshd

# Beispielausgabe:
# Status for the jail: sshd
# |- Currently banned: 4
# `- Total banned:     27

Haben Sie den SSH-Port geändert, passen Sie den Wert port in der jail.local entsprechend an. Eine ausführliche Einrichtung mit eigenen Filtern und Benachrichtigungen behandeln wir in unserer separaten Fail2ban-Anleitung, verlinkt am Ende dieses Beitrags.

Schritt 9: Quantenresistenten Schlüsselaustausch nutzen

Hier kommt das vielleicht überraschendste Detail dieser Anleitung: Aktuelle OpenSSH-Versionen schützen Ihre Sitzungen bereits gegen künftige Quantencomputer. Seit OpenSSH 9.0 (2022) ist der hybride Schlüsselaustausch sntrup761x25519-sha512 Standard, und seit OpenSSH 9.9 (Ende 2024) kommt zusätzlich der auf dem NIST-Standard basierende mlkem768x25519-sha256 hinzu. Diese Verfahren kombinieren klassische Kurvenkryptographie mit gitterbasierten, quantenresistenten Algorithmen. Selbst wer heute den verschlüsselten Datenverkehr mitschneidet, kann ihn auch mit einem späteren Quantencomputer nicht entschlüsseln.

Sie müssen dafür in der Regel nichts tun, der Schutz ist bei aktuellen Versionen automatisch aktiv. Prüfen können Sie die ausgehandelten Algorithmen aber explizit. Wer auf Nummer sicher gehen will, schreibt die bevorzugte Reihenfolge selbst fest:

# Ausgehandelten Schlüsselaustausch anzeigen
ssh -v [email protected] 2>&1 | grep "kex:"
# debug1: kex: algorithm: mlkem768x25519-sha256

# Optional in /etc/ssh/sshd_config.d/99-haertung.conf erzwingen:
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

Erscheint in der Ausgabe einer der Algorithmen mit mlkem oder sntrup, ist der quantenresistente Schutz aktiv. Achten Sie nur darauf, dass alte Clients diese Verfahren noch nicht beherrschen. Erzwingen Sie sie also nicht, wenn Sie veraltete Systeme anbinden müssen. Wer tiefer einsteigen will, findet in unserem Beitrag zur Post-Quanten-Kryptographie die Hintergründe zu Kyber und Dilithium.

Schritt 10: SSH-Agent und ~/.ssh/config für den Alltag

Damit die Passphrase Ihres Schlüssels nicht bei jedem Login stört, übernimmt der SSH-Agent das sichere Zwischenspeichern für die Dauer Ihrer Sitzung. Sie geben die Passphrase einmal ein, danach läuft die Anmeldung automatisch:

# SSH-Agent starten (auf den meisten Systemen bereits aktiv)
eval "$(ssh-agent -s)"

# Schlüssel zum Agenten hinzufügen
ssh-add ~/.ssh/id_ed25519
# Enter passphrase for /home/sam/.ssh/id_ed25519:
# Identity added: /home/sam/.ssh/id_ed25519 ([email protected])

Noch komfortabler wird der Alltag mit einer persönlichen Client-Konfiguration in ~/.ssh/config. Dort hinterlegen Sie pro Server einen Kurznamen samt Benutzer, Port und Schlüsseldatei. Statt langer Befehle tippen Sie dann nur noch ssh produktiv:

# ~/.ssh/config auf dem lokalen Rechner
Host produktiv
    HostName 203.0.113.10
    User sam
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    AddKeysToAgent yes

Die Option IdentitiesOnly yes sorgt dafür, dass der Client nur den angegebenen Schlüssel anbietet und nicht wahllos alle vorhandenen. Das verhindert das verbreitete Problem, dass der Server nach zu vielen falschen Schlüsseln die Verbindung mit Too many authentication failures abbricht. Mit diesem letzten Schritt ist Ihr Setup vollständig: Schlüsselanmeldung, gehärteter Server, Firewall, Brute-Force-Schutz und bequemer Alltag.

Das vollständige Beispielprojekt im Überblick

Zur Kontrolle hier das komplette, funktionierende Setup in der richtigen Reihenfolge. Wenn Sie diese Befehle in genau dieser Reihenfolge ausführen und Ihre Werte (Benutzername, IP, Port) anpassen, erhalten Sie einen vollständig gehärteten SSH-Server.

# ===== LOKALER RECHNER =====
# 1. Schlüssel erzeugen
ssh-keygen -t ed25519 -C "[email protected]"

# 2. Öffentlichen Schlüssel auf den Server kopieren
ssh-copy-id [email protected]

# 3. Schlüssel-Login testen
ssh [email protected]

# ===== AUF DEM SERVER (zweite Sitzung offen halten!) =====
# 4. Backup und Härtungsdatei anlegen
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo tee /etc/ssh/sshd_config.d/99-haertung.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers sam
MaxAuthTries 3
LoginGraceTime 30
EOF

# 5. Syntax prüfen und neu laden
sudo sshd -t && sudo systemctl reload ssh

# 6. Firewall
sudo ufw allow OpenSSH
sudo ufw enable

# 7. Brute-Force-Schutz
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

# 8. Verifizieren: neue Sitzung öffnen, Passwortlogin muss scheitern
ssh -o PreferredAuthentications=password [email protected]  # -> Permission denied

Behalten Sie die Sicherungsdatei sshd_config.bak auf dem Server. Sollte später etwas schieflaufen, stellen Sie damit in Sekunden den Ausgangszustand wieder her. Dokumentieren Sie außerdem, welche Schlüssel auf welchem Server liegen, damit Sie verlorene oder kompromittierte Schlüssel gezielt aus der authorized_keys entfernen können.

Häufige Fehler beim SSH-Key-Einsatz vermeiden

Die folgenden fünf Fehler führen zu den meisten Support-Anfragen und Selbstaussperrungen. Wer sie kennt, umgeht die typischen Stolperfallen.

  • Passwortlogin deaktivieren ohne getesteten Schlüssel. Das ist die klassische Selbstaussperrung. Testen Sie den Schlüssel-Login immer in einer neuen Sitzung, bevor Sie die alte schließen.
  • Falsche Dateiberechtigungen. Ist ~/.ssh nicht 700 oder authorized_keys nicht 600, ignoriert der Server den Schlüssel kommentarlos. Auch der private Schlüssel braucht 600.
  • Privaten Schlüssel auf den Server kopiert. Auf den Server gehört ausschließlich die .pub-Datei. Der private Schlüssel bleibt lokal.
  • Keine Passphrase gesetzt. Ein ungeschützter privater Schlüssel ist bei Diebstahl sofort einsatzbereit. Eine Passphrase macht ihn wertlos.
  • Firewall vor der SSH-Regel aktiviert. Wer ufw enable ausführt, ohne SSH freizugeben, kappt die eigene Verbindung. Immer zuerst ufw allow OpenSSH.

Troubleshooting: Die häufigsten SSH-Probleme lösen

Wenn etwas klemmt, hilft fast immer der ausführliche Modus mit ssh -vvv sowie ein Blick ins Server-Log mit sudo journalctl -u ssh -n 50. Die folgende Tabelle ordnet die häufigsten Meldungen ihrer Ursache und Lösung zu.

Meldung / SymptomUrsacheLösung
Permission denied (publickey)Schlüssel nicht gefunden oder falsche BerechtigungenPfad prüfen, chmod 600 auf Schlüssel, chmod 700 auf ~/.ssh
Too many authentication failuresClient bietet zu viele Schlüssel anIdentitiesOnly yes in ~/.ssh/config setzen
Connection refusedSSH-Dienst läuft nicht oder Port blockiertsystemctl status ssh, Firewall und Port prüfen
Connection timed outFalsche IP, Firewall oder NetzwerkproblemIP und Port verifizieren, ufw status prüfen
Host key verification failedServerschlüssel hat sich geändertAlten Eintrag mit ssh-keygen -R hostname entfernen
sign_and_send_pubkey: signing failedSSH-Agent läuft nicht oder Schlüssel nicht geladenssh-add ~/.ssh/id_ed25519 ausführen
Authentications that can continue: passwordSchlüssel wurde nicht akzeptiertauthorized_keys auf dem Server kontrollieren
Bad configuration optionTippfehler in sshd_configsudo sshd -t zeigt die fehlerhafte Zeile

Haben Sie sich tatsächlich ausgesperrt, hilft die Notfall-Konsole (KVM, VNC oder serielle Konsole) Ihres Hosters. Dort melden Sie sich lokal an, stellen mit sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config die Sicherung wieder her und entfernen vorübergehend Ihre Härtungsdatei. Genau für diesen Fall haben Sie die Sicherungskopie aus Schritt 4 angelegt.

Fortgeschrittene Tipps für maximale Sicherheit

Wer das Grundsetup beherrscht, kann den Schutz weiter ausbauen. Diese Maßnahmen lohnen sich besonders für Server mit mehreren Nutzern oder erhöhtem Schutzbedarf.

Hardware-Schlüssel mit FIDO2

Aktuelle OpenSSH-Versionen unterstützen Hardware-Token wie YubiKey über die Schlüsseltypen ed25519-sk und ecdsa-sk. Der private Schlüsselanteil verlässt das Hardware-Token nie, und die Anmeldung erfordert eine physische Berührung. Selbst ein vollständig kompromittierter Rechner gibt den Schlüssel nicht preis. Erzeugt wird er mit ssh-keygen -t ed25519-sk bei eingestecktem Token.

SSH-Zertifikate statt authorized_keys

In größeren Umgebungen wird das Verwalten einzelner Schlüssel pro Server schnell unübersichtlich. SSH-Zertifikate lösen das: Eine eigene Zertifizierungsstelle (CA) signiert Benutzerschlüssel mit begrenzter Gültigkeit. Der Server vertraut nur der CA, nicht jedem einzelnen Schlüssel. So rotieren Sie Zugänge zentral und mit Ablaufdatum, ohne auf jedem Host die authorized_keys pflegen zu müssen.

Zugriff auf IP-Bereiche und Zeitfenster begrenzen

Mit der Match-Direktive in der sshd_config setzen Sie feingranulare Regeln, etwa nur Schlüsselanmeldung aus dem Firmennetz. Ergänzend lässt sich der SSH-Port per Firewall auf bekannte IP-Adressen beschränken. Wer nur aus einem festen Büro oder über ein VPN zugreift, kann den Zugang darauf einschränken und damit das Internet als Angriffsfläche praktisch ausschließen. Eine VPN-Verbindung davor, etwa per WireGuard, kombiniert beide Welten elegant.

SSH-Keys verwalten, rotieren und widerrufen

Ein SSH-Key ist kein Werkzeug, das man einmal einrichtet und dann vergisst. Wie jedes Geheimnis sollte er einen Lebenszyklus haben: erzeugen, einsetzen, rotieren, widerrufen. Verschaffen Sie sich zuerst einen Überblick, welche Schlüssel auf einem Server überhaupt Zugang haben. Die Datei authorized_keys listet jeden berechtigten öffentlichen Schlüssel in einer eigenen Zeile, samt Kommentar am Ende. Anhand des Kommentars erkennen Sie, welches Gerät oder welche Person dahintersteht.

# Alle berechtigten Schlüssel auf dem Server anzeigen
cat ~/.ssh/authorized_keys

# Fingerabdruck eines lokalen Schlüssels prüfen
ssh-keygen -lf ~/.ssh/id_ed25519.pub
# 256 SHA256:4f3c... [email protected] (ED25519)

Verlässt eine Person das Team oder geht ein Gerät verloren, widerrufen Sie den Zugang, indem Sie die entsprechende Zeile aus der authorized_keys entfernen. Das wirkt sofort, ohne Neustart des Dienstes. Den Fingerabdruck aus dem ssh-keygen -lf nutzen Sie, um die richtige Zeile sicher zu identifizieren, bevor Sie sie löschen. Vermeiden Sie es, einfach die ganze Datei zu leeren, sonst sperren Sie auch die noch benötigten Schlüssel aus.

Rotation bedeutet, einen Schlüssel nach einer festgelegten Zeit gegen einen neuen zu tauschen. Für persönliche Schlüssel mit Passphrase ist ein Rhythmus von ein bis zwei Jahren praktikabel. Erzeugen Sie dazu ein neues Paar, hinterlegen Sie den neuen öffentlichen Schlüssel auf allen Servern, testen Sie den Login und entfernen Sie erst danach den alten Eintrag. So entsteht keine Lücke. Bei Schlüsseln für Automatisierung, etwa in CI/CD-Pipelines, lohnt sich eine kürzere Frist und im Idealfall der Umstieg auf SSH-Zertifikate mit eingebautem Ablaufdatum, die diesen Prozess vollständig automatisieren.

Häufig gestellte Fragen (FAQ)

Ist ein SSH-Key wirklich sicherer als ein langes Passwort?

Ja, deutlich. Ein Ed25519-Schlüssel hat eine effektive Stärke von rund 128 Bit, die kein realistischer Brute-Force-Angriff überwindet. Vor allem aber wird beim Login nie ein Geheimnis übertragen, das abgefangen werden könnte. Selbst das stärkste Passwort kann durch Phishing oder einen kompromittierten Server abhandenkommen. Ein privater Schlüssel mit Passphrase bleibt auch dann geschützt.

Was passiert, wenn ich meinen privaten Schlüssel verliere?

Ohne den privaten Schlüssel können Sie sich nicht mehr anmelden, deshalb sind ein Backup an einem sicheren Ort und ein zweiter hinterlegter Schlüssel sinnvoll. Geht der Schlüssel verloren oder wird gestohlen, entfernen Sie den zugehörigen öffentlichen Schlüssel umgehend aus der authorized_keys aller Server. Eine gesetzte Passphrase verschafft Ihnen dabei wertvolle Zeit, da der gestohlene Schlüssel ohne sie nutzlos ist.

Sollte ich den SSH-Port von 22 auf einen anderen ändern?

Es ist eine Komfortmaßnahme, kein echter Schutz. Ein Portscan findet den Dienst trotzdem in Sekunden. Die Änderung reduziert aber das Grundrauschen automatisierter Bots und hält Ihre Logdateien übersichtlicher. Die eigentliche Sicherheit liefern die Schlüsselauthentifizierung und die deaktivierte Passwortanmeldung, nicht die Portnummer.

Funktioniert SSH-Key-Authentifizierung auch unter Windows?

Ja. Windows 10 und 11 enthalten den OpenSSH-Client, den Sie in den optionalen Features aktivieren. Danach funktionieren ssh-keygen, ssh und ~/.ssh/config genau wie unter Linux. Lediglich ssh-copy-id fehlt, weshalb Sie den öffentlichen Schlüssel mit dem manuellen Befehl aus Schritt 2 übertragen oder per PowerShell anhängen.

Muss ich für jeden Server ein eigenes Schlüsselpaar erzeugen?

Nicht zwingend, aber es ist gute Praxis, pro Gerät oder Zweck ein eigenes Paar zu nutzen. So können Sie einzelne Schlüssel gezielt widerrufen, ohne alle Zugänge zu erneuern. Ein Schlüssel pro Arbeitsgerät und ein separater für die Automatisierung sind ein praktikabler Kompromiss zwischen Sicherheit und Verwaltungsaufwand.

Ist SSH gegen Quantencomputer geschützt?

Der Schlüsselaustausch ja, sofern Sie eine aktuelle OpenSSH-Version nutzen. Seit OpenSSH 9.0 ist der hybride, quantenresistente Schlüsselaustausch Standard, seit Version 9.9 kommt der NIST-basierte mlkem768x25519 hinzu. Damit ist Ihr verschlüsselter Datenverkehr auch gegen das Mitschneiden für eine spätere Entschlüsselung geschützt. Aktualisieren Sie Ihre Server regelmäßig, dann profitieren Sie automatisch.

Wie binde ich weitere Personen in mein Team ein?

Jede Person erzeugt ihr eigenes Schlüsselpaar und schickt Ihnen nur den öffentlichen Schlüssel. Diesen hängen Sie als zusätzliche Zeile an die authorized_keys des entsprechenden Benutzers an und ergänzen den Namen in AllowUsers. Bei mehr als einer Handvoll Nutzer lohnt sich der Umstieg auf SSH-Zertifikate, die das zentrale Verwalten und Ablaufenlassen von Zugängen erheblich vereinfachen.

Fazit: In 30 Minuten zum gehärteten SSH-Server

Ein SSH-Key ersetzt das schwächste Glied der Server-Sicherheit, das Passwort, durch ein Verfahren, das Brute-Force-Angriffe praktisch ausschließt. Mit den zehn Schritten dieser Anleitung haben Sie nicht nur den Schlüssel eingerichtet, sondern den gesamten Dienst gehärtet: Passwortlogins sind deaktiviert, der Root-Zugang ist gesperrt, eine Firewall begrenzt die erreichbaren Dienste, und Fail2ban sperrt aufdringliche Bots aus. Der quantenresistente Schlüsselaustausch aktueller OpenSSH-Versionen schützt Ihre Verbindungen sogar gegen künftige Bedrohungen.

Der wichtigste Grundsatz bleibt: Testen Sie jeden Schritt, bevor Sie die nächste Tür schließen, und halten Sie immer eine zweite Sitzung offen. Mit der Sicherungskopie der Konfiguration und der Notfall-Konsole Ihres Hosters als Rückversicherung ist die ganze Prozedur risikolos. Halten Sie Ihre Systeme aktuell, rotieren Sie Schlüssel regelmäßig, und Ihr Server bleibt auch in der wachsenden Bedrohungslage 2026 ein hartes Ziel.

Externe Quellen