SSH-Keys einrichten: 12 Schritte [2026]

SSH-Keys sind das Fundament sicherer Server-Authentifizierung. Wer noch mit Passwörtern auf Linux-Server zugreift, riskiert Brute-Force-Angriffe, Credential-Stuffing und kompromittierte Zugänge. OpenSSH 10.3, veröffentlicht am 2. April 2026, unterstützt jetzt standardmäßig den post-quanten-sicheren Schlüsselaustausch mlk768x25519-sha256. Dieses Tutorial zeigt, wie du in 12 Schritten SSH-Keys erstellst, auf Server überträgst, absicherst und professionell verwaltest.

CVE-2024-6387 (“regreSSHion”) betraf alle OpenSSH-Versionen von 8.5p1 bis 9.7p1 und ermöglichte Root-Zugriff ohne Authentifizierung. Wer SSH-Keys richtig konfiguriert und Passwort-Login deaktiviert, schließt genau diese Angriffsvektoren. Laut BSI-Technischer Richtlinie TR-02102-4 sind Ed25519-Keys die empfohlene Methode für sichere SSH-Authentifizierung in Deutschland.

Voraussetzungen

Bevor du beginnst, prüfe folgende Anforderungen:

Komponente	Mindestversion	Empfohlen	Prüfbefehl
OpenSSH Client	8.0	10.3 (April 2026)	`ssh -V`
OpenSSH Server (sshd)	8.0	10.3 (April 2026)	`sshd -V`
Linux Distribution	Ubuntu 22.04 / Debian 12	Ubuntu 24.04 LTS	`lsb_release -a`
Root oder sudo	Pflicht für sshd_config	Sudo-Zugang	`sudo -v`
Netzwerkzugang	Port 22 offen oder custom	Port nach Wahl	`ss -tlnp`

Dieses Tutorial setzt grundlegende Linux-Kenntnisse voraus. Du benötigst Zugang zu einem lokalen Rechner (Client) und einem entfernten Linux-Server. Die Schritte funktionieren identisch auf Ubuntu, Debian, CentOS/RHEL und Fedora.

Wie SSH-Keys funktionieren: Asymmetrische Kryptographie

SSH-Schlüsselpaare basieren auf asymmetrischer Kryptographie. Ein privater Schlüssel (Private Key) bleibt ausschließlich auf deinem lokalen Rechner. Der öffentliche Schlüssel (Public Key) landet auf dem Server in der Datei ~/.ssh/authorized_keys. Beim Verbindungsaufbau beweist der Client durch eine kryptographische Signatur, dass er den passenden privaten Schlüssel besitzt, ohne den Schlüssel selbst zu übertragen.

Dieser Mechanismus macht SSH-Keys fundamentell sicherer als Passwörter. Ein abgefangenes Passwort gibt sofortigen Zugang. Ein abgefangener Public Key ist nutzlos ohne den dazugehörigen Private Key. Selbst bei einem Man-in-the-Middle-Angriff kann ein Angreifer die Signatur nicht fälschen, sofern du den Server-Fingerprint beim ersten Verbindungsaufbau verifizierst.

Der Authentifizierungsprozess läuft in vier Phasen ab: (1) Der Client sendet den Public-Key-Fingerprint an den Server. (2) Der Server prüft, ob dieser Fingerprint in authorized_keys vorhanden ist. (3) Der Server sendet eine zufällige Challenge. (4) Der Client signiert die Challenge mit dem Private Key und schickt die Signatur zurück. Der Server verifiziert die Signatur mit dem Public Key. Nur wer den Private Key besitzt, kann eine gültige Signatur erstellen.

Algorithmus	Schlüssellänge	Sicherheitsniveau	Geschwindigkeit	Empfehlung 2026
Ed25519	256 Bit (fest)	ca. 128 Bit	Sehr schnell	Erste Wahl
ECDSA (P-384)	384 Bit	ca. 192 Bit	Schnell	Zweite Wahl
ECDSA (P-256)	256 Bit	ca. 128 Bit	Schnell	Dritte Wahl
RSA-4096	4096 Bit	ca. 140 Bit	Langsam	Kompatibilität
RSA-2048	2048 Bit	ca. 112 Bit	Mittel	Nicht mehr empfohlen
DSA-1024	1024 Bit	Unsicher	Mittel	Verboten

Ed25519, der Goldstandard unter den SSH-Key-Algorithmen, verwendet Elliptic-Curve-Kryptographie auf Basis der Curve25519. Die feste Schlüsselgröße von 256 Bit bietet ca. 128 Bit Sicherheit, vergleichbar mit RSA-3072. Der BSI empfiehlt Ed25519 in der TR-02102-4 als bevorzugten Algorithmus für neue SSH-Deployments. OpenSSH 10.0 (April 2025) wählte zudem den post-quanten-sicheren Key-Exchange mlkem768x25519-sha256 als neuen Standard, was SSH-Verbindungen bereits heute gegen hypothetische Quantencomputer-Angriffe absichert.

Schritt 1: OpenSSH-Version prüfen und aktualisieren

Bevor du einen SSH-Key erstellst, stelle sicher, dass du eine aktuelle OpenSSH-Version verwendest. OpenSSH 10.3 (April 2026) schließt mehrere kritische Sicherheitslücken und unterstützt post-quanten-sichere Schlüsselaustausch-Algorithmen. Veraltete Versionen vor 9.9p2 sind anfällig für CVE-2025-26465 (CVSS 6.8), der Man-in-the-Middle-Angriffe bei aktiviertem VerifyHostKeyDNS ermöglicht.

# OpenSSH-Version prüfen
ssh -V

# Beispiel-Ausgabe (aktuell):
# OpenSSH_10.3p1, OpenSSL 3.5.0 8 Apr 2026

# System aktualisieren (Ubuntu/Debian)
sudo apt update && sudo apt upgrade -y openssh-client openssh-server

# System aktualisieren (CentOS/RHEL/Fedora)
sudo dnf update openssh openssh-clients openssh-server -y

# SSH-Daemon-Status prüfen
sudo systemctl status sshd

# SSH-Daemon neu starten (nach Updates)
sudo systemctl restart sshd

Nach dem Update prüfe erneut mit ssh -V, ob die neue Version aktiv ist. Für produktive Systeme empfiehlt sich ein SSH-Audit mit dem Tool ssh-audit (verfügbar als Python-Paket über pip), das alle aktiven Ciphers, MACs und Kex-Algorithmen auf Schwachstellen analysiert und einen detaillierten Bericht erstellt.

Schritt 2: Ed25519-Schlüsselpaar erstellen

Der Befehl ssh-keygen ist das zentrale Werkzeug zur Schlüsselerstellung. Das Flag -t ed25519 wählt den Algorithmus, -a 100 erhöht die Anzahl der KDF-Runden (Key Derivation Function) für die Passphrase-Ableitung auf 100, was Brute-Force-Angriffe gegen die verschlüsselte Schlüsseldatei erheblich erschwert (Standard: 16 Runden). Das Flag -C fügt einen Kommentar zur Identifikation hinzu.

# Ed25519-Schlüsselpaar mit 100 KDF-Runden erstellen
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C "alice@laptop-2026"

# Ausgabe des Befehls:
# Generating public/private ed25519 key pair.
# Enter passphrase (empty for no passphrase): [starke Passphrase eingeben]
# Enter same passphrase again: [Passphrase wiederholen]
# Your identification has been saved in /home/alice/.ssh/id_ed25519
# Your public key has been saved in /home/alice/.ssh/id_ed25519.pub
# The key fingerprint is:
# SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz123456789abcdef alice@laptop-2026
# The key's randomart image is:
# +--[ED25519 256]--+
# |        . o .    |
# +----[SHA256]-----+

# Erstellte Dateien prüfen
ls -la ~/.ssh/

# Erwartete Ausgabe:
# drwx------  2 alice alice 4096 Jun 19 10:23 .
# -rw-------  1 alice alice  464 Jun 19 10:23 id_ed25519
# -rw-r--r--  1 alice alice  102 Jun 19 10:23 id_ed25519.pub

# Public Key anzeigen
cat ~/.ssh/id_ed25519.pub
# Beispielausgabe:
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbCdEfGhIjKlMnOpQrStUvWxYz alice@laptop-2026

Wichtig: Die Datei id_ed25519 (Private Key) erhält automatisch Berechtigungen 0600 (rw——-). Die Datei id_ed25519.pub (Public Key) bekommt 0644 (rw-r–r–). Diese Berechtigungen sind nicht optional: OpenSSH verweigert die Verwendung eines Private Keys mit zu offenen Berechtigungen mit der Fehlermeldung “Permissions 0644 for ‘/home/alice/.ssh/id_ed25519’ are too open.”

Wähle eine starke Passphrase mit mindestens 20 Zeichen, idealerweise eine Passphrase aus mehreren zufälligen Wörtern (Diceware-Methode). Die Passphrase schützt den Private Key bei physischem Diebstahl des Rechners oder einem Dateileck. Ohne Passphrase ist jeder, der Zugang zur Schlüsseldatei erhält, sofort in der Lage, sich auf allen Servern anzumelden, die den zugehörigen Public Key akzeptieren.

Schritt 3: RSA-4096-Schlüssel für Legacy-Systeme erstellen

Für Systeme, die Ed25519 noch nicht unterstützen (OpenSSH vor Version 6.5, bestimmte Netzwerkgeräte wie ältere Cisco- oder Juniper-Systeme), ist RSA-4096 die empfohlene Alternative. RSA-2048 gilt seit 2024 gemäß NIST-Empfehlungen als nicht mehr zukunftssicher für langfristige Sicherheit. Das BSI empfiehlt in der TR-02102-4 mindestens RSA-3000 für neue Schlüssel, praktikabler und häufiger verwendet ist RSA-4096.

# RSA-4096-Schlüsselpaar erstellen (Kompatibilitäts-Backup)
ssh-keygen -t rsa -b 4096 -a 100 -f ~/.ssh/id_rsa_backup -C "alice@laptop-rsa-2026"

# Public Key aus vorhandenem Private Key ableiten (Wiederherstellung)
ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519_recovered.pub

# Key-Fingerprint anzeigen (SHA256, Standard ab OpenSSH 6.8)
ssh-keygen -lf ~/.ssh/id_ed25519.pub

# MD5-Fingerprint anzeigen (für ältere Systeme)
ssh-keygen -lf ~/.ssh/id_ed25519.pub -E md5

# Ausgabe SHA256:
# 256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz123456789abcdef alice@laptop-2026 (ED25519)

Benenne Schlüssel nach Verwendungszweck, nicht nach Algorithmus. Ein Schema wie id_ed25519_prod, id_ed25519_staging, id_ed25519_github und id_ed25519_gitlab macht die Verwaltung bei mehreren Servern und Diensten übersichtlich. Verwende nie denselben Private Key für verschiedene Sicherheitsbereiche: Produktionsserver und Test-Umgebungen gehören konzeptionell in unterschiedliche Vertrauenszonen.

Schritt 4: SSH-Verzeichnis und Berechtigungen korrekt setzen

Falsche Dateiberechtigungen sind der häufigste Grund, warum SSH-Key-Authentifizierung fehlschlägt. Der SSH-Daemon ist absichtlich restriktiv: Zu offene Berechtigungen an ~/.ssh oder authorized_keys werden als Sicherheitsrisiko interpretiert und führen zum stillen Fallback auf Passwort-Authentifizierung, ohne klare Fehlermeldung an den Benutzer.

# Korrekte Berechtigungen setzen (auf Client und Server)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config          # falls vorhanden
chmod 600 ~/.ssh/authorized_keys # auf dem Server

# Berechtigungen prüfen
ls -la ~/.ssh/

# Korrekte Ausgabe:
# drwx------  2 alice alice 4096 Jun 19 10:23 .
# -rw-------  1 alice alice  464 Jun 19 10:23 id_ed25519
# -rw-r--r--  1 alice alice  102 Jun 19 10:23 id_ed25519.pub
# -rw-------  1 alice alice  412 Jun 19 10:23 authorized_keys

# Besitzer korrigieren (falls Dateien unter anderem User erstellt wurden)
chown -R $USER:$USER ~/.ssh

# Home-Verzeichnis auf korrekte Berechtigungen prüfen
ls -ld ~/
# Muss lauten: drwxr-xr-x (0755) oder drwx------ (0700)
# NICHT 0777 oder 0775 - SSH würde authorized_keys dann ignorieren!

Auf dem Server muss das Home-Verzeichnis des Benutzers für andere nicht beschreibbar sein. Ein Home-Verzeichnis mit Berechtigungen 0777 oder 0775 veranlasst SSH dazu, die authorized_keys-Datei zu ignorieren. Das ist ein bekanntes Problem bei frisch aufgesetzten Servern, bei denen mehrere Administratoren Dateien im Home-Verzeichnis abgelegt haben. Prüfe mit ls -ld ~/, ob die Berechtigungen maximal 0755 sind.

Schritt 5: Public Key auf den Server übertragen mit ssh-copy-id

Das Werkzeug ssh-copy-id überträgt den Public Key automatisch und sicher in die authorized_keys-Datei des Zielbenutzers auf dem Remoteserver. Es prüft dabei, ob der Schlüssel bereits vorhanden ist (um Duplikate zu vermeiden), erstellt das ~/.ssh-Verzeichnis auf dem Server falls nötig, und setzt automatisch die korrekten Berechtigungen. Für die einmalige Übertragung ist noch ein Passwort-Login nötig.

# Public Key mit ssh-copy-id auf Server übertragen (Standard-Port 22)
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# Bei nicht-standardmäßigem SSH-Port
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]

# Manuelle Alternative (wenn ssh-copy-id nicht verfügbar, z.B. auf macOS ohne Homebrew)
cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && \
   chmod 600 ~/.ssh/authorized_keys"

# Verbindung mit Key testen (vor Deaktivierung des Passwort-Logins!)
ssh -i ~/.ssh/id_ed25519 [email protected] "echo 'SSH-Key funktioniert'"

# Ausgabe bei Erfolg:
# SSH-Key funktioniert

Nach erfolgreicher Übertragung prüfe unbedingt in einer neuen Session, ob der Key-Login funktioniert, bevor du die Passwort-Authentifizierung deaktivierst. Das ist Schritt 7 in diesem Tutorial. Kein Passwort-Login bedeutet: Brute-Force-Angriffe gegen SSH werden vollständig unwirksam, da es kein Passwort gibt, das geraten werden könnte.

Schritt 6: SSH-Agent für komfortables Key-Management einrichten

Der SSH-Agent ist ein Hintergrundprozess, der Private Keys entschlüsselt im RAM hält und auf Anfrage Authentifizierungsoperationen durchführt. Du gibst die Passphrase einmal ein, und der Agent kümmert sich für den Rest der Session. Das eliminiert das wiederholte Eingeben der Passphrase bei häufigen SSH-Verbindungen, ohne die Sicherheit des Schlüssels zu kompromittieren, da der Private Key nie über das Netzwerk übertragen wird.

# SSH-Agent starten (falls nicht automatisch via Desktop-Umgebung gestartet)
eval "$(ssh-agent -s)"

# Ausgabe:
# Agent pid 12345

# Private Key zum Agent hinzufügen (Passphrase wird einmalig abgefragt)
ssh-add ~/.ssh/id_ed25519

# Key mit Zeitlimit hinzufügen (erlischt nach 8 Stunden = 28800 Sekunden)
ssh-add -t 28800 ~/.ssh/id_ed25519

# Alle geladenen Keys anzeigen
ssh-add -l

# Ausgabe:
# 256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz123456789abcdef alice@laptop-2026 (ED25519)

# Alle Keys aus Agent entfernen
ssh-add -D

# Automatischen Agent-Start in ~/.bashrc oder ~/.zshrc einrichten
cat >> ~/.bashrc << 'EOF'
if [ -z "$SSH_AUTH_SOCK" ]; then
  eval "$(ssh-agent -s)" > /dev/null
  ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi
EOF

Unter GNOME und KDE übernimmt der Desktop-Environment die Agent-Verwaltung automatisch. GNOME-Keyring und KWallet integrieren sich in den SSH-Agent und speichern Passphrasen sicher im Betriebssystem-Keystore. Auf Servern ohne Desktop empfiehlt sich das Tool keychain (verfügbar in den Standard-Repositories), das Keys über mehrere Terminals und sogar tmux/screen-Sessions hinweg persistent verwaltet und dabei einen einzigen ssh-agent-Prozess nutzt.

Schritt 7: SSH-Server mit sshd_config absichern

Die Konfigurationsdatei /etc/ssh/sshd_config steuert das Verhalten des SSH-Servers. Die Standardkonfiguration ist auf maximale Kompatibilität ausgelegt, nicht auf Sicherheit. Nach der Einrichtung von SSH-Keys ist das Deaktivieren des Passwort-Logins der wichtigste Härtungsschritt. Ohne Passwort-Authentifizierung sind Brute-Force-Angriffe und Credential-Stuffing grundsätzlich wirkungslos.

# Backup der Original-Konfiguration erstellen
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d)

# Konfigurationsdatei bearbeiten
sudo nano /etc/ssh/sshd_config

# Empfohlene Sicherheitseinstellungen (eine pro Zeile einfügen/ändern):
Port 2222                          # Standard-Port ändern (Security by Obscurity)
PermitRootLogin no                 # Root-Login verbieten
PasswordAuthentication no          # Passwort-Login deaktivieren
PubkeyAuthentication yes           # Key-Authentifizierung aktivieren
KbdInteractiveAuthentication no    # Challenge-Response deaktivieren
AuthenticationMethods publickey    # Ausschliesslich Public-Key erlauben
MaxAuthTries 3                     # Maximale Authentifizierungsversuche pro Verbindung
LoginGraceTime 30                  # 30 Sekunden Timeout fuer Login
X11Forwarding no                   # X11-Weiterleitung deaktivieren
AllowTcpForwarding no              # TCP-Tunneling deaktivieren (falls nicht benoetigt)
ClientAliveInterval 300            # Keep-alive alle 5 Minuten senden
ClientAliveCountMax 2              # Nach 2 fehlgeschlagenen Keep-alives trennen
AllowUsers alice bob               # Nur explizit erlaubte Benutzer

# Konfiguration auf Syntaxfehler prüfen (immer vor Neustart!)
sudo sshd -t

# Falls keine Fehler: SSH-Daemon neu laden (ohne bestehende Sessions zu trennen)
sudo systemctl reload sshd

# Falls reload nicht ausreicht (z.B. nach Port-Änderung):
sudo systemctl restart sshd

Kritisch: Teste die neue Konfiguration in einer bestehenden SSH-Session, bevor du die aktuelle Session schließt. Öffne ein zweites Terminal-Fenster und versuche dich mit dem Key einzuloggen. Nur wenn das funktioniert, schließe die ursprüngliche Session. Ein Konfigurationsfehler oder eine falsch gesetzte Berechtigung kann dich sonst dauerhaft vom Server aussperren und erfordert dann Konsolen-Zugang beim Hosting-Provider.

Für moderne, sichere Algorithmen in sshd_config ergänze explizite Cipher-, MAC- und KEX-Listen. Das schließt bekannte schwache Algorithmen wie arcfour, blowfish-cbc, 3des-cbc und diffie-hellman-group1-sha1 aus, die in älteren OpenSSH-Versionen noch verfügbar waren und in Security-Audits regelmäßig als Findings auftauchen:

# Moderne Algorithmen in /etc/ssh/sshd_config ergänzen
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512
KexAlgorithms mlkem768x25519-sha256,curve25519-sha256,diffie-hellman-group16-sha512

# Überprüfung mit ssh-audit (Open-Source Sicherheits-Scanner)
# Installation: sudo pip3 install ssh-audit
ssh-audit localhost

# Beispiel-Ausgabe nach Härtung:
# (nfo) SSH version: OpenSSH 10.3 (protocol 2.0)
# (rec) Good: Following key exchange algorithms are supported:
#       mlkem768x25519-sha256, curve25519-sha256
# (good) No problematic algorithms found.

Schritt 8: SSH-Config-Datei für mehrere Server einrichten

Die Datei ~/.ssh/config ist das zentrale Verwaltungsinstrument für mehrere SSH-Verbindungen. Statt langer Befehle mit vielen Flags reicht nach der Konfiguration ein einfaches Alias wie ssh prod für eine vollständig konfigurierte, sichere Verbindung. Die Config-Datei unterstützt Wildcards und Vererbung, was die Verwaltung von Dutzenden Servern erheblich vereinfacht. Die Datei liegt unter ~/.ssh/config und muss Berechtigungen 0600 haben.

# ~/.ssh/config erstellen oder bearbeiten
nano ~/.ssh/config

# Vollständige Beispiel-Konfiguration:

# Globale Standardeinstellungen (fuer alle Hosts)
Host *
  AddKeysToAgent yes
  IdentitiesOnly yes
  ServerAliveInterval 60
  ServerAliveCountMax 3
  HashKnownHosts yes
  StrictHostKeyChecking yes

# Produktionsserver
Host prod
  HostName prod.example.de
  User alice
  Port 2222
  IdentityFile ~/.ssh/id_ed25519_prod

# Staging-Server
Host staging
  HostName staging.example.de
  User alice
  Port 22
  IdentityFile ~/.ssh/id_ed25519_staging

# Alle internen Server (Wildcard)
Host *.intern.example.de
  User alice
  IdentityFile ~/.ssh/id_ed25519_prod
  Port 2222

# GitHub
Host github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
  IdentitiesOnly yes

# Datei-Berechtigungen setzen
chmod 600 ~/.ssh/config

# Verbindung testen
ssh prod

Die Option IdentitiesOnly yes in der globalen Sektion ist besonders wichtig: Ohne sie versucht SSH alle verfügbaren Identitäten aus dem Agent anzubieten, was bei SSH-Servern mit niedrigem MaxAuthTries-Limit (hier auf 3 gesetzt) zur automatischen Aussperrung führen kann, wenn du viele Keys im Agent hast. Mit IdentitiesOnly yes wird nur der explizit in IdentityFile angegebene Schlüssel verwendet.

Schritt 9: ProxyJump für Bastion-Hosts konfigurieren

In professionellen Infrastrukturen sind Produktionsserver oft nicht direkt aus dem Internet erreichbar. Ein Bastion-Host (auch Jump-Server) dient als gesicherter Eintrittspunkt ins interne Netzwerk. Frühere Lösungen nutzten verschachtelte ProxyCommand-Konstrukte mit Shell-Expansion; seit OpenSSH 7.3 (August 2016) ist ProxyJump die sichere und elegante Alternative. ProxyJump ist sicherer, weil keine Shell-Expansion der Verbindungsparameter stattfindet und deshalb keine Injection-Angriffe möglich sind.

# ProxyJump direkt im Befehl (einmaliger Einsatz)
ssh -J [email protected] [email protected]

# Mehrere Hops verketten (verschachtelte Bastion-Hosts)
ssh -J [email protected],alice@intern-bastion [email protected]

# ProxyJump dauerhaft in ~/.ssh/config konfigurieren
Host bastion
  HostName bastion.example.de
  User alice
  IdentityFile ~/.ssh/id_ed25519_bastion
  Port 22

Host intern-*
  User alice
  IdentityFile ~/.ssh/id_ed25519_prod
  ProxyJump bastion
  # Beispiel: 'ssh intern-db' verbindet via bastion -> intern-db

# SCP über Bastion-Host
scp -J bastion datei.tar.gz alice@intern-web:/home/alice/

# SFTP über Bastion-Host
sftp -J bastion alice@intern-db

# Tunnel über Bastion (Port-Forwarding durch Jump-Host)
ssh -J bastion -L 5432:localhost:5432 alice@intern-db -N

ProxyJump vermeidet das unsichere Agent-Forwarding. Ein häufiger Fehler in Legacy-Infrastrukturen ist ForwardAgent yes für Bastion-Hosts zu aktivieren, damit der Jump-Server sich weiter nach innen authentifizieren kann. Das erlaubt einem kompromittierten Bastion-Host, deine gesamte SSH-Identität für beliebige Verbindungen zu missbrauchen, solange die Session aktiv ist. ProxyJump löst das Problem architektonisch: SSH baut zwei separate verschlüsselte Tunnel auf, und der Bastion-Host sieht ausschließlich verschlüsselten Durchleitungs-Traffic, niemals die Credentials für Innensysteme.

Schritt 10: SSH-Keys für GitHub und GitLab einrichten

GitHub und GitLab unterstützen SSH-Keys für sichere Git-Operationen (git clone, push, pull) ohne Passwort-Eingabe. Beide Plattformen empfehlen Ed25519 als bevorzugten Algorithmus. GitHub akzeptiert keine DSA-Keys mehr (seit 2021) und empfiehlt mindestens RSA-3072 für RSA-Keys. Für einen dedizierten GitHub-Key erstelle einen separaten Schlüssel, um bei einer Kompromittierung nur GitHub und nicht alle anderen Server zu gefährden.

# Dedizierten GitHub-Key erstellen
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_github -C "alice@laptop-github-2026"

# Public Key anzeigen (diesen Inhalt bei GitHub einfügen)
cat ~/.ssh/id_ed25519_github.pub

# ~/.ssh/config für GitHub erweitern
# (falls noch nicht vorhanden, aus Schritt 8 hinzufuegen)
cat >> ~/.ssh/config << 'EOF'

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
  IdentitiesOnly yes

Host gitlab.com
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_ed25519_gitlab
  IdentitiesOnly yes
EOF

# GitHub-SSH-Verbindung testen (nach Upload des Public Key in GitHub Settings)
ssh -T [email protected]

# Erwartete Ausgabe:
# Hi alice! You've successfully authenticated, but GitHub does not provide shell access.

# GitLab-Verbindung testen
ssh -T [email protected]

# Erwartete Ausgabe:
# Welcome to GitLab, @alice!

Den Public Key auf GitHub hochladen: Navigiere zu Settings > SSH and GPG keys > New SSH key. Kopiere den vollständigen Inhalt der .pub-Datei inklusive des abschließenden Kommentars (“alice@laptop-github-2026”). Wähle als Key-Typ “Authentication Key” für regulären Zugang oder “Signing Key”, wenn du Git-Commits mit SSH signieren möchtest. GitHub zeigt nach erfolgreichem Upload den SHA256-Fingerprint an, den du mit ssh-keygen -lf ~/.ssh/id_ed25519_github.pub lokal verifizieren kannst.

Schritt 11: SSH-Key-Rotation und Ablaufverwaltung

Key-Rotation ist eine sicherheitskritische Praxis, die in vielen Organisationen vernachlässigt wird. Das BSI empfiehlt für reguläre Zugänge eine Rotation mindestens alle 12 Monate, für privilegierte Zugänge (root, sudo) alle 6 Monate. Nach einem Mitarbeiterabgang oder Sicherheitsvorfall ist sofortige Rotation Pflicht. OpenSSH kennt kein eingebautes Ablaufdatum für Keys, die Verwaltung erfordert Disziplin oder spezialisiertes Tooling.

# Neuen Key fuer Rotation erstellen
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_new -C "alice@laptop-rotation-2026"

# Neuen Public Key auf alle betroffenen Server übertragen
# (alter Key bleibt vorübergehend noch aktiv fuer Rollback-Moeglichkeit)
ssh-copy-id -i ~/.ssh/id_ed25519_new.pub [email protected]
ssh-copy-id -i ~/.ssh/id_ed25519_new.pub [email protected]

# Neuen Key testen BEVOR der alte entfernt wird
ssh -i ~/.ssh/id_ed25519_new [email protected] "echo 'Neuer Key: OK'"

# Alten Key aus authorized_keys entfernen (auf jedem Server)
# Fingerprint des alten Keys ermitteln:
OLD_FINGERPRINT=$(ssh-keygen -lf ~/.ssh/id_ed25519.pub | awk '{print $2}')
echo "Entferne Key mit Fingerprint: $OLD_FINGERPRINT"

# Auf Server ausfuehren:
ssh [email protected] "
  grep -v '$OLD_FINGERPRINT' ~/.ssh/authorized_keys > /tmp/ak_new
  mv /tmp/ak_new ~/.ssh/authorized_keys
  chmod 600 ~/.ssh/authorized_keys
"

# Alten lokalen Key archivieren (nicht loeschen - fuer Forensik 90 Tage aufheben)
mkdir -p ~/.ssh/archive
mv ~/.ssh/id_ed25519 ~/.ssh/archive/id_ed25519_deprecated_$(date +%Y%m%d)
mv ~/.ssh/id_ed25519.pub ~/.ssh/archive/id_ed25519_deprecated_$(date +%Y%m%d).pub

# Neuen Key an Standard-Speicherort verschieben
mv ~/.ssh/id_ed25519_new ~/.ssh/id_ed25519
mv ~/.ssh/id_ed25519_new.pub ~/.ssh/id_ed25519.pub

Für Organisationen mit vielen Servern ist manuelle Key-Rotation fehleranfällig und zeitaufwendig. Das Tool HashiCorp Vault bietet SSH-Certificate-Authority-Funktionalität: Vault signiert SSH-Keys mit einer zentral verwalteten CA, und Zertifikate haben eingebaute Ablaufdaten (TTL). Das macht Rotation automatisierbar und vollständig auditierbar. Eine Alternative ist Teleport (open source), das SSH-Zertifikate mit kurzen Laufzeiten (typisch 8-12 Stunden) und vollständiger Session-Aufzeichnung kombiniert.

Schritt 12: Komplette Konfiguration testen und verifizieren

Nach Abschluss aller Schritte prüfe die Gesamtkonfiguration systematisch. SSH bietet einen eingebauten Verbose-Modus, der detaillierte Informationen über den Authentifizierungsprozess liefert. Das Flag -v aktiviert einen Verbose-Level, -vvv maximale Ausgabe. Bei Problemen mit SSH-Key-Authentifizierung ist dieser Modus das erste Diagnose-Werkzeug.

# 1. Verbindung im Debug-Modus testen
ssh -vvv [email protected] 2>&1 | grep -E "(Offering|accepts|succeeded|denied)"

# Erwartete relevante Ausgaben:
# debug1: Offering public key: /home/alice/.ssh/id_ed25519 ED25519 SHA256:...
# debug1: Server accepts key: /home/alice/.ssh/id_ed25519 ED25519 SHA256:...
# debug1: Authentication succeeded (publickey).

# 2. Passwort-Login verifizieren (muss fehlschlagen)
ssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no [email protected]
# Erwartete Ausgabe:
# Permission denied (publickey).

# 3. Root-Login verifizieren (muss fehlschlagen)
ssh [email protected]
# Erwartete Ausgabe:
# Permission denied (publickey).

# 4. Server-Logs auf Anomalien prüfen
sudo tail -50 /var/log/auth.log | grep -E "Accepted|Failed|Invalid"

# 5. Aktive SSH-Verbindungen anzeigen
sudo ss -tnp | grep :22
sudo who

# 6. ssh-audit für vollständigen Sicherheitsbericht
pip3 install ssh-audit --quiet
ssh-audit server.example.de 2>/dev/null | tail -20

Aktuelle Sicherheitslücken in OpenSSH 2024 bis 2026

Richtig konfigurierte SSH-Keys reduzieren die Angriffsfläche erheblich, ersetzen aber kein zeitnahes Patching. Die letzten zwei Jahre brachten mehrere kritische OpenSSH-Schwachstellen, die auch gut konfigurierte Systeme betrafen und schnelles Handeln erforderten.

CVE	CVSS	Betroffen	Behoben in	Auswirkung
CVE-2024-6387	8.1	OpenSSH 8.5p1 bis 9.7p1	9.8p1 (Juli 2024)	Remote Code Execution als root
CVE-2025-26465	6.8	OpenSSH 6.8p1 bis 9.9p1	9.9p2 (Feb. 2025)	Man-in-the-Middle bei VerifyHostKeyDNS
CVE-2025-26466	5.9	OpenSSH 9.5p1 bis 9.9p1	9.9p2 (Feb. 2025)	Pre-Auth Denial of Service
CVE-2025-61984	7.5	OpenSSH mit ProxyCommand	RHEL-Patch 2026	Code-Ausführung via Shell-Metazeichen
CVE-2025-61985	7.5	OpenSSH mit ssh://-URI	RHEL-Patch 2026	Code-Ausführung via Null-Byte in URI

CVE-2024-6387, intern “regreSSHion” genannt, war besonders gravierend: Eine Signal-Handler-Race-Condition im Authentifizierungs-Code ermöglichte Remote Code Execution als root auf nicht gepatchten Systemen. Das Sicherheitsunternehmen Qualys schätzte, dass über 14 Millionen verwundbare OpenSSH-Server öffentlich erreichbar waren. Das Exploit erforderte keine Authentifizierung und war über einen Zeitraum von Stunden zuverlässig ausführbar. Systeme mit deaktiviertem Passwort-Login waren zwar unattraktiver als Ziel für Brute-Force, aber von CVE-2024-6387 gleichermaßen betroffen, da die Lücke vor der Authentifizierungsphase lag.

Die Gegenmaßnahme für CVE-2025-26465 ist simpel: VerifyHostKeyDNS no in /etc/ssh/ssh_config oder ~/.ssh/config setzen. Diese Option ist standardmäßig deaktiviert, wird aber in DANE-basierten Infrastrukturen aktiviert. Wer DANE für SSH nutzt, sollte auf OpenSSH 9.9p2 oder neuer aktualisieren. CVE-2025-26466 (DoS) erfordert kein spezielles Konfigurationsmerkmal, ist aber durch das Update auf 9.9p2 ebenfalls behoben.

7 häufige Fehler bei der SSH-Key-Einrichtung

Fehler 1: Kein Passphrase auf dem Private Key. Ein Private Key ohne Passphrase ist bei Diebstahl des Rechners oder einem Datenleck sofort nutzbar. Der SSH-Agent eliminiert die lästige Passphrase-Eingabe, ohne die Sicherheit zu opfern. Setze immer eine starke Passphrase und nutze den Agent für den täglichen Betrieb.

Fehler 2: Falsche Dateiberechtigungen. authorized_keys mit 0644 statt 0600, oder ~/.ssh mit 0755 statt 0700 führt dazu, dass SSH den Key ignoriert und nur “Permission denied” meldet. Prüfe Berechtigungen mit ls -la ~/.ssh/ und korrigiere mit chmod.

Fehler 3: Agent-Forwarding auf untrusted Hosts. ForwardAgent yes in der globalen Host *-Sektion erlaubt jedem Server, deinen SSH-Agent zu nutzen, auch kompromittierten. Aktiviere Agent-Forwarding nur für explizit vertrauenswürdige Hosts, oder nutze ProxyJump als sichere Alternative.

Fehler 4: Einen Key für alle Dienste. Derselbe Private Key für Produktionsserver, GitHub, GitLab und Unternehmens-VPN bedeutet, dass eine Kompromittierung alle Zugänge gleichzeitig öffnet. Separate Keys pro Sicherheitskontext mit ~/.ssh/config verwalten.

Fehler 5: Passwort-Login nach Key-Setup aktiv lassen. SSH-Keys einrichten und Passwort-Auth aktiv lassen ist wie eine Alarmanlage installieren und die Hintertür offen stehen lassen. Nach Verifikation des Key-Logins sofort PasswordAuthentication no in sshd_config setzen.

Fehler 6: StrictHostKeyChecking deaktivieren. Das Flag -o StrictHostKeyChecking=no oder die Config-Option StrictHostKeyChecking no schaltet die Man-in-the-Middle-Erkennung vollständig aus. In CI/CD-Pipelines verwende ssh-keyscan, um Server-Fingerprints vorab sicher in known_hosts einzutragen, statt die Prüfung zu deaktivieren.

Fehler 7: Keys nie rotieren. Ein SSH-Key, der seit Jahren nicht rotiert wurde, könnte aus einem ehemaligen Mitarbeiter-Laptop stammen, der schon längst aus dem Unternehmen ausgeschieden ist. Führe ein Inventar aller authorized_keys-Einträge auf allen Servern und plane regelmäßige Rotation. Das BSI-Framework Allianz für Cyber-Sicherheit empfiehlt SSH-Key-Inventarisierung als Bestandteil des Asset-Managements.

Erweiterte Techniken: SSH-Zertifikate und CI/CD-Integration

SSH-Zertifikate als skalierbare Alternative

SSH-Zertifikate lösen das Skalierungsproblem bei statischen Keys. Statt jeden Public Key auf jeden Server zu kopieren, vertrauen alle Server der SSH-Certificate-Authority (CA). Neue Benutzer erhalten ein zeitlich befristetes Zertifikat. Bei Mitarbeiterabgang läuft das Zertifikat automatisch ab. Die Infrastruktur benötigt keine Server-seitigen Änderungen pro Benutzer, was bei 100 oder 1000 Servern den Aufwand dramatisch reduziert.

# SSH-CA erstellen (einmalig, sicher offline aufbewahren)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "SSH-CA Organization XYZ 2026"

# CA-Public-Key auf Servern verteilen (in /etc/ssh/sshd_config):
# TrustedUserCAKeys /etc/ssh/ca_key.pub

# Benutzer-Key mit CA signieren (30-Tage-Gueltigkeit)
ssh-keygen -s /etc/ssh/ca_key \
  -I "[email protected]" \
  -n alice,deploy \
  -V +30d \
  ~/.ssh/id_ed25519.pub

# Ergebnis: ~/.ssh/id_ed25519-cert.pub

# Zertifikat-Details anzeigen und verifizieren
ssh-keygen -Lf ~/.ssh/id_ed25519-cert.pub

# Ausgabe (vereinfacht):
# Type: [email protected] user certificate
# Public key: ED25519-CERT SHA256:...
# Signing CA: ED25519 SHA256:...
# Key ID: "[email protected]"
# Valid: from 2026-06-19T00:00:00 to 2026-07-19T00:00:00
# Principals: alice, deploy

SSH-Keys in CI/CD-Pipelines sicher verwalten

Automatisierte Deployment-Pipelines brauchen SSH-Zugang ohne interaktive Passphrase-Eingabe. Das direkte Speichern von Private Keys in Repository-Dateien ist ein kritischer Fehler, der in Git-Histories verbleibt und bei öffentlichen Repositories sofortige Kompromittierung bedeutet. Die sichere Lösung kombiniert dedizierte Deploy-Keys, minimale Berechtigungen in authorized_keys und einen Secret-Manager wie GitHub Actions Secrets oder HashiCorp Vault.

# Dedizierten Deploy-Key erstellen (ohne Passphrase fuer Automation, aber mit Einschraenkungen)
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_deploy -C "ci-deploy@github-actions-2026" -N ""

# Auf Server: authorized_keys mit command-Einschraenkung (nur git pull erlaubt)
# ~/.ssh/authorized_keys Eintrag:
# command="git -C /var/www/app pull --ff-only",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA...

# GitHub Actions Workflow-Beispiel (als Kommentar, nicht als Shell-Code):
# - name: Setup SSH Deploy Key
#   run: |
#     mkdir -p ~/.ssh
#     echo "${{ secrets.DEPLOY_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
#     chmod 600 ~/.ssh/id_ed25519
#     ssh-keyscan -H prod.example.de >> ~/.ssh/known_hosts
#
# - name: Deploy
#   run: ssh [email protected]  # Nur 'git pull' moeglich durch command= Einschraenkung

# Vault-basierte Alternative fuer kurze SSH-Zertifikate (empfohlen):
# vault write ssh/sign/deploy-role \
#   public_key=@~/.ssh/id_ed25519.pub \
#   valid_principals=deploy \
#   ttl=1h

Fehlerbehebung: 8 häufige SSH-Verbindungsprobleme

Fehlermeldung	Wahrscheinliche Ursache	Lösung
Permission denied (publickey)	Key nicht in authorized_keys, oder falsche Berechtigungen	ssh-copy-id erneut ausführen; chmod 600 ~/.ssh/authorized_keys
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED	Server-Key geändert oder MitM-Verdacht	ssh-keygen -R hostname; Fingerprint beim Admin prüfen
Could not open a connection to your authentication agent	SSH-Agent nicht gestartet	eval “$(ssh-agent -s)” ausführen
Bad permissions. Try removing permissions for user	authorized_keys oder ~/.ssh zu offen	chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys
Too many authentication failures	MaxAuthTries überschritten (Agent bietet zu viele Keys an)	IdentitiesOnly yes in ~/.ssh/config setzen
Connection refused	sshd nicht gestartet oder falscher Port	sudo systemctl start sshd; Port in ssh-Befehl angeben
No supported authentication methods available	Nur PubkeyAuthentication aktiv, aber Key fehlt auf Server	Key auf Server kopieren; authorized_keys prüfen
Host key verification failed	known_hosts-Eintrag veraltet oder falsch	ssh-keygen -R hostname; neuen Fingerprint beim Admin verifizieren

Bei hartnäckigen Problemen hilft die Kombination aus ssh -vvv auf dem Client und sudo tail -f /var/log/auth.log auf dem Server. OpenSSH protokolliert präzise, warum eine Authentifizierung scheitert. Ein häufig übersehenes Problem auf RHEL- und CentOS-Systemen: SELinux blockiert den SSH-Daemon bei falschen Dateikontexten. Der Befehl restorecon -Rv ~/.ssh/ stellt die korrekten SELinux-Kontexte wieder her. Bei Ubuntu kann AppArmor ähnliche Probleme verursachen; sudo apparmor_status zeigt den Status.

Ein weiterer häufiger Fall: der Server akzeptiert den Key, aber der Login schlägt danach trotzdem fehl. Das deutet auf ein Problem mit der Benutzerumgebung hin (/etc/nologin vorhanden, Shell in /etc/passwd nicht ausführbar, oder das Konto ist deaktiviert). Prüfe mit sudo getent passwd alice die Shell und mit sudo passwd -S alice den Account-Status.

Weiterführende Quellen

OpenSSH Release Notes: Offizielle Versionshistorie und Sicherheitsfixes seit OpenSSH 1.2
BSI TR-02102: Kryptographische Verfahren: Bundesamt für Sicherheit in der Informationstechnik, Empfehlungen zu SSH-Algorithmen
OpenSSH CVE-Analyse 2024/2025: Detaillierte technische Analyse aktueller OpenSSH-Schwachstellen
CVE-2025-26465 und CVE-2025-26466: MitM- und DoS-Schwachstellen in OpenSSH, Qualys-Forschung
CVE-2024-6387 (regreSSHion): MITRE-Eintrag zur kritischen Remote-Code-Execution-Schwachstelle

FAQ: SSH-Keys erstellen und verwalten

Welcher SSH-Key-Algorithmus ist 2026 der beste?

Ed25519 ist die erste Wahl für neue SSH-Keys in 2026. Der Algorithmus bietet ca. 128 Bit Sicherheit bei kurzen Schlüsseln (256 Bit), hoher Geschwindigkeit und eingebauter Resistenz gegen Timing-Angriffe. Das BSI empfiehlt Ed25519 explizit in der Technischen Richtlinie TR-02102-4. Für ältere Systeme ohne Ed25519-Unterstützung ist RSA-4096 die Fallback-Option. RSA-2048 und DSA gelten heute als nicht mehr ausreichend sicher.

Was ist der Unterschied zwischen Public Key und Private Key?

Der Private Key (Datei id_ed25519) bleibt ausschließlich auf deinem lokalen Rechner und darf niemals weitergegeben oder übertragen werden. Er wird durch eine Passphrase verschlüsselt gespeichert. Der Public Key (Datei id_ed25519.pub) wird auf Servern in der Datei ~/.ssh/authorized_keys eingetragen und kann bedenkenlos geteilt werden. Beim Login beweist der Client per kryptographischer Signatur den Besitz des Private Keys, ohne ihn zu übertragen.

Wie sicher sind SSH-Keys im Vergleich zu Passwörtern?

SSH-Keys bieten fundamentale Sicherheitsvorteile gegenüber Passwörtern. Ein Ed25519-Key hat effektiv 128 Bit Sicherheit, was einem Passwort aus 28 zufälligen alphanumerischen Zeichen entspricht. Passwörter können durch Brute-Force, Phishing oder Datenlecks kompromittiert werden. Ein SSH-Key ist ohne den Private Key wertlos, und mit deaktiviertem Passwort-Login im sshd_config sind Brute-Force-Angriffe gegen SSH vollständig unwirksam.

Kann ich denselben SSH-Key auf mehreren Servern verwenden?

Technisch ja, aus Sicherheitsgründen nicht empfohlen. Ein Key für alle Server bedeutet: Kompromittierung eines Keys öffnet alle Server gleichzeitig. Die Empfehlung lautet: separate Keys für verschiedene Sicherheitsbereiche (Produktion, Staging, GitHub, GitLab). Die Datei ~/.ssh/config macht die Verwaltung mehrerer Keys trotzdem einfach und transparent.

Was passiert, wenn ich meinen Private Key verliere?

Du verlierst den Zugang zu allen Servern, die ausschließlich diesen Key akzeptieren, sofern du keinen alternativen Zugang hast. Richte daher immer eine Backup-Methode ein: entweder ein zweites Schlüsselpaar in der authorized_keys, oder einen Out-of-Band-Zugang wie Konsolen-Zugang beim Hosting-Provider. Erstelle verschlüsselte Backups des Private Keys auf einem sicheren offline Medium und bewahre diese separat auf.

Muss ich nach CVE-2024-6387 alle SSH-Keys neu erstellen?

Nein. CVE-2024-6387 betrifft den OpenSSH-Server-Prozess selbst (eine Race-Condition im Signal-Handler), nicht die kryptographischen Schlüssel. Die Lösung ist ein Update des OpenSSH-Servers auf Version 9.8p1 oder neuer. Die vorhandenen SSH-Keys bleiben kryptographisch sicher und müssen nicht neu erstellt werden. Eine reguläre Key-Rotation alle 12 Monate bleibt trotzdem empfehlenswert.

Wie richte ich SSH-Keys unter Windows ein?

Windows 10 und 11 enthalten OpenSSH als optionales Feature, das in den Windows-Einstellungen unter “Optionale Features” aktiviert wird. Nach Aktivierung liegen alle Befehle (ssh-keygen, ssh-copy-id, ssh-add) im Windows-Terminal (PowerShell) bereit. Das .ssh-Verzeichnis liegt unter C:\Users\Benutzername\.ssh\. Die Befehle sind identisch zu Linux. Alternativ bietet PuTTY/PuTTYgen eine grafische Oberfläche, und das Windows Subsystem for Linux (WSL) eine vollständige Linux-SSH-Umgebung.

Wie lange sollte ein SSH-Key gültig sein?

Statische SSH-Keys haben kein eingebautes Ablaufdatum. Das BSI empfiehlt manuelle Rotation alle 12 Monate für reguläre Keys, alle 6 Monate für privilegierte Zugänge. SSH-Zertifikate (signierte Keys mit TTL) ermöglichen automatische Ablaufsteuerung: typische Werte sind 30 Tage für Benutzer-Zertifikate und 8-24 Stunden für CI/CD-Deploy-Zertifikate. HashiCorp Vault und Teleport implementieren dieses Konzept für skalierbare SSH-Infrastrukturen.

SSH-Keys einrichten: 12 Schritte, 25 Min [2026]