Ein SSH-Key ersetzt das Passwort beim Anmelden auf einem Server durch ein kryptografisches Schlüsselpaar. Wer 2026 noch mit Passwörtern arbeitet, lädt Brute-Force-Angriffe geradezu ein: Die OpenSSH-Lücke regreSSHion (CVE-2024-6387) hat 2024 gezeigt, wie schnell exponierte SSH-Dienste ins Visier geraten. Dieses Tutorial zeigt in 12 nachvollziehbaren Schritten, wie Sie einen SSH-Key erstellen, ihn sicher auf einen Server bringen, die Passwort-Anmeldung abschalten und optional Hardware-Schlüssel sowie Post-Quanten-Kryptografie aktivieren. Geplante Zeit: rund 30 Minuten.

Alle Befehle sind für Linux, macOS und Windows (mit OpenSSH-Client) getestet. Am Ende steht ein vollständiges, lauffähiges Beispielprojekt: ein gehärteter Zugang zu zwei Servern plus ein separater Deploy-Key für Git. Stand: 11. Juni 2026.

SSH-Key erstellen: Warum ed25519 statt RSA der Standard ist

Bevor wir einen SSH-Key erstellen, lohnt der Blick auf das Schlüsselverfahren. OpenSSH unterstützt mehrere Typen, doch in der aktuellen Härtungspraxis 2026 ist ed25519 die erste Wahl. Der Grund ist nicht Geschmack, sondern Mathematik: Ed25519 basiert auf der Edwards-Kurve Curve25519 und bietet ein Sicherheitsniveau, das grob einem 3072-Bit-RSA-Schlüssel entspricht, kommt dabei aber mit einem 256-Bit-Schlüssel aus. Der öffentliche Schlüssel ist nur rund 68 Zeichen lang, passt also in eine einzige Zeile.

Drei praktische Vorteile sprechen für ed25519: Erstens ist die Schlüsselerzeugung deterministisch und unempfindlich gegen schwache Zufallszahlen, ein bekanntes Risiko bei RSA und DSA. Zweitens sind Signatur und Verifikation deutlich schneller, was bei vielen parallelen Verbindungen spürbar wird. Drittens fällt die Konfiguration einfacher aus, weil es keine variable Schlüssellänge gibt, über die man nachdenken müsste. RSA bleibt nur dort sinnvoll, wo ein sehr alter Server oder ein Legacy-Gerät ed25519 schlicht nicht versteht.

Die folgende Tabelle vergleicht die in OpenSSH verfügbaren Schlüsseltypen. Die Empfehlungen orientieren sich an aktuellen Härtungsleitfäden sowie der BSI-Richtlinie TR-02102-4 zum Einsatz von Secure Shell.

SchlüsseltypSchlüssellängeSicherheitEmpfehlung 2026Einsatz
ed25519256 Bit≈ 3072-Bit-RSAErste WahlStandard für neue Schlüssel
ed25519-sk256 Bit + HardwareSehr hochEmpfohlenFIDO2-Sicherheitsschlüssel
ecdsa256–521 BitHochNur bei BedarfNIST-Kurven, Compliance
rsa≥ 3072 BitHochNur als FallbackLegacy-Systeme
dsa1024 BitUnsicherNicht nutzenIn OpenSSH entfernt

Voraussetzungen: OpenSSH-Version und Werkzeuge

Damit dieses Tutorial reibungslos läuft, brauchen Sie eine aktuelle OpenSSH-Installation auf dem lokalen Rechner und Zugriff auf einen Zielserver (Cloud-VM, Raspberry Pi, NAS oder Webhosting mit Shell-Zugang). Die folgenden Versionen gelten als sicherer Stand für 2026:

  • OpenSSH 10.x (aktuelle Serie 2026) auf Client und Server, mindestens jedoch 9.8p1. Die Version 9.8p1 vom 1. Juli 2024 schließt die kritische Lücke regreSSHion (CVE-2024-6387), die alle portablen Versionen von 8.5p1 bis 9.7p1 auf glibc-basierten Linux-Systemen betraf.
  • Linux: ein beliebiger Paketmanager (apt, dnf, pacman) zum Aktualisieren von openssh-client und openssh-server.
  • macOS: integrierter OpenSSH-Client; für die neueste Version optional Homebrew.
  • Windows 10/11: der optionale Client „OpenSSH-Client“ unter Einstellungen, oder die mitgelieferte Version in der PowerShell.
  • Ein Terminal mit Shell-Zugang sowie, optional, ein FIDO2-Sicherheitsschlüssel (YubiKey, Nitrokey, Token2) für Schritt 9.

Aktualisieren Sie OpenSSH vor dem Start. Veraltete Versionen sind die häufigste Ursache für unerklärliche Verbindungsfehler und bekannte Sicherheitslücken. Wer einen Hetzner-, IONOS- oder AWS-Server betreibt, sollte die Pakete des Anbieters einspielen, da diese die Sicherheits-Patches rückportiert enthalten.

Schritt 1: OpenSSH-Version prüfen

Prüfen Sie zuerst, welche Version lokal installiert ist. Öffnen Sie ein Terminal und führen Sie aus:

# Lokale OpenSSH-Version anzeigen
ssh -V

# Beispielausgabe (gewünscht):
# OpenSSH_10.0p1, OpenSSL 3.3.2 4 Jun 2024

Liegt die Version unter 9.8p1, aktualisieren Sie sofort. Unter Debian oder Ubuntu genügt:

# Paketquellen aktualisieren und OpenSSH einspielen
sudo apt update
sudo apt install --only-upgrade openssh-client openssh-server

# Version nach dem Upgrade erneut prüfen
ssh -V

Auf dem Server prüfen Sie dieselbe Version, sobald Sie sich anmelden können. Notieren Sie sich beide Versionsnummern. Unterscheiden sich Client und Server stark, kann das später bei modernen Algorithmen wie dem Post-Quanten-Schlüsselaustausch (Schritt 10) zu Aushandlungsproblemen führen.

Schritt 2: ed25519-Schlüsselpaar erzeugen

Jetzt geht es ans Eigentliche. Mit ssh-keygen erzeugen Sie das Schlüsselpaar. Der private Schlüssel bleibt für immer auf Ihrem Rechner, der öffentliche Schlüssel wandert auf den Server. Geben Sie diesen Befehl ein:

# ed25519-Schlüsselpaar mit aussagekräftigem Kommentar erzeugen
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519

Die Optionen im Detail: -t ed25519 wählt das Schlüsselverfahren, -C setzt einen Kommentar (meist E-Mail oder Rechnername zur späteren Zuordnung) und -f legt den Dateinamen fest. Die Ausgabe sieht so aus:

Generating public/private ed25519 key pair.
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
The key fingerprint is:
SHA256:9kPq2v...Xa7Yd [email protected]
The key's randomart image is:
+--[ED25519 256]--+
|        .o+=B*o  |
|       . o.=.o   |
+----[SHA256]-----+

Es entstehen zwei Dateien: id_ed25519 (privater Schlüssel, streng geheim) und id_ed25519.pub (öffentlicher Schlüssel, darf geteilt werden). Den Unterschied zwischen privatem und öffentlichem Schlüssel erklären wir ausführlicher im Beitrag zu digitalen Signaturen, denn das zugrunde liegende Prinzip ist identisch.

Schritt 3: Passphrase und KDF-Runden richtig setzen

Ein privater Schlüssel ohne Passphrase ist eine Datei, die jeden Zugang gewährt, der sie kopiert. Setzen Sie immer eine Passphrase. Damit ein gestohlener Schlüssel auch bei schwacher Passphrase nicht im Sekundentakt durchprobiert werden kann, erhöht OpenSSH die Anzahl der KDF-Runden (Key Derivation Function) mit der Option -a:

# Schlüssel mit 100 KDF-Runden für stärkere Passphrase-Streckung
ssh-keygen -t ed25519 -a 100 -C "[email protected]" -f ~/.ssh/id_ed25519

Der Wert -a 100 bedeutet 100 Runden der bcrypt-basierten KDF. Das macht das Entschlüsseln des privaten Schlüssels spürbar teurer für Angreifer, kostet beim eigenen Login aber nur Sekundenbruchteile. Wer die Passphrase eines bestehenden Schlüssels ändern möchte, ohne ein neues Paar zu erzeugen, nutzt:

# Passphrase eines vorhandenen Schlüssels ändern (-p) und KDF-Runden erhöhen
ssh-keygen -p -a 100 -f ~/.ssh/id_ed25519

Die Philosophie hinter der KDF ist dieselbe wie bei modernen Passwort-Hashes. Wer verstehen will, warum absichtlich langsame Funktionen gegen Brute-Force schützen, findet die Details in unserer Anleitung zu Argon2-Passwort-Hashing.

Schritt 4: ssh-agent einrichten und Schlüssel laden

Mit Passphrase müssten Sie diese bei jeder Verbindung neu eintippen. Der ssh-agent hält den entschlüsselten Schlüssel im Speicher und erspart die Wiederholung. Starten Sie den Agenten und laden Sie den Schlüssel:

# ssh-agent in der aktuellen Shell starten
eval "$(ssh-agent -s)"
# Ausgabe: Agent pid 48213

# Privaten Schlüssel zum Agenten hinzufügen (Passphrase wird einmal abgefragt)
ssh-add ~/.ssh/id_ed25519
# Ausgabe: Identity added: /home/sam/.ssh/id_ed25519 ([email protected])

# Geladene Schlüssel auflisten
ssh-add -l

Auf macOS integriert sich der Agent in den Schlüsselbund. Fügen Sie ssh-add --apple-use-keychain ~/.ssh/id_ed25519 hinzu, damit die Passphrase dauerhaft im Schlüsselbund gespeichert wird. Unter Linux mit systemd-Desktop übernimmt meist gnome-keyring oder ssh-agent.service diese Aufgabe automatisch. Auf Windows aktivieren Sie den Dienst „OpenSSH Authentication Agent“ einmalig:

# Windows PowerShell als Administrator
Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Schritt 5: Öffentlichen Schlüssel auf den Server kopieren

Der öffentliche Schlüssel muss in die Datei ~/.ssh/authorized_keys des Zielkontos auf dem Server. Das erledigt ssh-copy-id in einem Schritt, inklusive korrekter Rechte:

# Öffentlichen Schlüssel automatisch auf den Server übertragen
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# Ausgabe nach erfolgreicher Übertragung:
# Number of key(s) added: 1
# Now try logging into the machine, with: "ssh [email protected]"

Beim ersten Mal fragt der Befehl noch nach dem Passwort des Kontos, weil ja noch kein Schlüssel hinterlegt ist. Falls ssh-copy-id fehlt (etwa auf Windows oder minimalen Images), übertragen Sie den Schlüssel manuell:

# Manuelle Übertragung 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"

Testen Sie jetzt die Anmeldung: ssh [email protected]. Wenn alles stimmt, landen Sie ohne Passwort direkt auf dem Server, höchstens die Passphrase des Agenten wird einmal abgefragt. Erst wenn dieser Login funktioniert, deaktivieren wir in Schritt 8 die Passwort-Anmeldung.

Schritt 6: Dateirechte korrekt setzen

OpenSSH ist bei Dateirechten kompromisslos. Sind der Schlüssel oder das Verzeichnis zu offen, verweigert der Client oder der Server die Nutzung kommentarlos. Setzen Sie die Rechte sowohl lokal als auch auf dem Server:

# Lokal und auf dem Server jeweils ausführen
chmod 700 ~/.ssh                       # nur der Eigentümer darf hinein
chmod 600 ~/.ssh/id_ed25519            # privater Schlüssel: nur lesen/schreiben für Eigentümer
chmod 644 ~/.ssh/id_ed25519.pub        # öffentlicher Schlüssel darf lesbar sein
chmod 600 ~/.ssh/authorized_keys       # auf dem Server
chmod 600 ~/.ssh/config                # falls vorhanden (Schritt 7)

Die Zahlen sind oktale Rechte: 700 heißt voller Zugriff für den Eigentümer, nichts für Gruppe und andere. 600 erlaubt dem Eigentümer Lesen und Schreiben, sonst nichts. Achten Sie zusätzlich darauf, dass das Heimatverzeichnis selbst nicht für die Gruppe oder andere schreibbar ist, sonst lehnt ein strenger sshd die Schlüsselanmeldung ab.

Schritt 7: Die ~/.ssh/config für komfortable Verbindungen

Statt bei jeder Verbindung Benutzername, Host und Schlüssel anzugeben, definieren Sie pro Server einen Alias in ~/.ssh/config. Das spart Tipparbeit und macht komplexe Setups übersichtlich:

# ~/.ssh/config
Host produktiv
    HostName server.firma.de
    User sam
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    AddKeysToAgent yes

Host backup
    HostName 10.0.5.12
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_backup
    IdentitiesOnly yes

Danach genügt ssh produktiv oder ssh backup. Die Option IdentitiesOnly yes ist wichtig: Sie verhindert, dass der Client wahllos alle geladenen Schlüssel durchprobiert, was bei vielen Schlüsseln zur Fehlermeldung „Too many authentication failures“ führt. AddKeysToAgent yes lädt den Schlüssel bei Bedarf automatisch in den Agenten.

Schritt 8: Passwort-Login deaktivieren und sshd härten

Jetzt der wichtigste Sicherheitsschritt. Solange Passwörter erlaubt sind, nützt der schönste Schlüssel wenig, weil Angreifer einfach Passwörter raten. Öffnen Sie auf dem Server die Datei /etc/ssh/sshd_config (oder besser eine Datei unter /etc/ssh/sshd_config.d/) und setzen Sie:

# /etc/ssh/sshd_config.d/99-haertung.conf
PasswordAuthentication no          # Passwort-Login komplett abschalten
PermitRootLogin no                 # kein direkter Root-Login per SSH
PubkeyAuthentication yes           # Schlüssel-Anmeldung erlauben
KbdInteractiveAuthentication no    # interaktive Passwortabfrage aus
PermitEmptyPasswords no
MaxAuthTries 3                     # nach 3 Fehlversuchen trennen
LoginGraceTime 20                  # 20 Sekunden bis zur erfolgreichen Anmeldung

Prüfen Sie die Syntax und starten Sie den Dienst neu, ohne die bestehende Sitzung zu schließen:

# Konfiguration auf Syntaxfehler prüfen
sudo sshd -t

# Dienst neu laden (bestehende Sitzungen bleiben offen)
sudo systemctl reload ssh    # auf manchen Systemen: reload sshd

Wichtig: Lassen Sie unbedingt die aktuelle SSH-Sitzung geöffnet und testen Sie den neuen Login in einem zweiten Terminal. Sperren Sie sich nicht selbst aus. Die Prinzipien hinter dieser Verschlüsselung und Server-Authentifizierung ähneln denen, die wir im Beitrag zu HTTPS und TLS beschreiben.

Schritt 9: Hardware-Schlüssel mit FIDO2 (ed25519-sk)

Ein rein softwarebasierter Schlüssel kann kopiert werden, sobald jemand Zugriff auf die Datei und die Passphrase hat. Hardware-Sicherheitsschlüssel nach FIDO2 lösen das: Der geheime Teil verlässt nie das Token. OpenSSH unterstützt das mit dem Typ ed25519-sk (sk steht für „security key“). Stecken Sie Ihren YubiKey oder Nitrokey ein und erzeugen Sie:

# Hardware-gebundenen ed25519-Schlüssel erzeugen
ssh-keygen -t ed25519-sk -O resident -O verify-required \
  -C "sam-yubikey" -f ~/.ssh/id_ed25519_sk

# Sie werden aufgefordert, den Schlüssel zu berühren (Touch)

Die Optionen: -O resident speichert eine Referenz auf dem Token selbst, sodass Sie den Schlüssel auf einem neuen Rechner mit ssh-keygen -K wiederherstellen können. -O verify-required verlangt zusätzlich eine PIN oder Biometrie, nicht nur eine Berührung. Den öffentlichen Teil kopieren Sie wie gewohnt mit ssh-copy-id auf den Server. Bei jedem Login leuchtet das Token und verlangt eine Berührung, was Phishing und unbemerkten Fernzugriff praktisch ausschließt.

Falls Ihr Server ed25519-sk nicht akzeptiert, ist sein OpenSSH zu alt (Unterstützung gibt es seit OpenSSH 8.2). Aktualisieren Sie ihn oder nutzen Sie übergangsweise den Typ ecdsa-sk, den auch ältere FIDO2-Token unterstützen.

Schritt 10: Post-Quanten-Schlüsselaustausch aktivieren

SSH-Schlüssel selbst sind eine Sache, der Schlüsselaustausch beim Verbindungsaufbau eine andere. Hier droht das Szenario „jetzt abfangen, später entschlüsseln“: Ein Angreifer speichert heute verschlüsselten Verkehr und entschlüsselt ihn, sobald Quantencomputer leistungsfähig genug sind. OpenSSH wehrt das mit hybriden Post-Quanten-Verfahren ab, die ein klassisches mit einem quantensicheren Verfahren kombinieren.

Zwei Methoden sind relevant: sntrup761x25519-sha512 ist seit OpenSSH 9.0 der Standard, mlkem768x25519-sha256 (auf Basis des NIST-standardisierten ML-KEM) kam mit OpenSSH 9.9 hinzu und ist in der Serie 10.x Standard. Erzwingen Sie die hybriden Verfahren explizit in Ihrer Konfiguration:

# In ~/.ssh/config (Client) oder /etc/ssh/sshd_config (Server)
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

# Ausgehandelten Schlüsselaustausch einer Verbindung anzeigen
ssh -v produktiv 2>&1 | grep "kex:"
# debug1: kex: algorithm: mlkem768x25519-sha256

Warum das wichtig ist, vertiefen wir im Überblick zur Post-Quanten-Kryptografie. Kurz gesagt: Der Schlüsselaustausch ist die verwundbarste Stelle gegen künftige Quantenangriffe, weil hier das gemeinsame Geheimnis ausgehandelt wird.

Schritt 11: RSA als Fallback für Legacy-Systeme

Manche älteren Geräte, Netzwerk-Appliances oder Hosting-Panels verstehen ed25519 nicht. Für solche Fälle erzeugen Sie einen RSA-Schlüssel mit mindestens 3072 Bit, dem aktuell empfohlenen Minimum:

# RSA-Fallback mit 3072 Bit und 100 KDF-Runden
ssh-keygen -t rsa -b 3072 -a 100 -C "sam-rsa-fallback" -f ~/.ssh/id_rsa

# Für besonders langlebige Schlüssel optional 4096 Bit
ssh-keygen -t rsa -b 4096 -a 100 -f ~/.ssh/id_rsa_4096

Verwenden Sie RSA wirklich nur dort, wo es nötig ist, und ordnen Sie ihn in der ~/.ssh/config gezielt dem betreffenden Host zu. Vermeiden Sie es, RSA aus Bequemlichkeit überall einzusetzen. Ein gemischtes Setup mit ed25519 als Standard und RSA als Ausnahme ist die saubere Lösung.

Schritt 12: Vollständiges Beispielprojekt für zwei Server plus Git

Zum Abschluss bauen wir ein realistisches, lauffähiges Setup: ein gehärteter Hauptzugang, ein Backup-Server auf abweichendem Port und ein separater Deploy-Key, der nur für Git-Pushes auf GitHub gilt. Getrennte Schlüssel pro Zweck sind ein Grundprinzip: Wird einer kompromittiert, bleibt der Rest sicher.

# 1. Drei Schlüssel für drei Zwecke erzeugen
ssh-keygen -t ed25519 -a 100 -C "sam-produktiv" -f ~/.ssh/id_ed25519
ssh-keygen -t ed25519 -a 100 -C "sam-backup"    -f ~/.ssh/id_ed25519_backup
ssh-keygen -t ed25519 -a 100 -C "sam-github"    -f ~/.ssh/id_github

# 2. Öffentliche Schlüssel verteilen
ssh-copy-id -i ~/.ssh/id_ed25519.pub        [email protected]
ssh-copy-id -i ~/.ssh/id_ed25519_backup.pub [email protected] -p 2222
# Den GitHub-Schlüssel im GitHub-Konto unter Settings > SSH Keys hinterlegen:
cat ~/.ssh/id_github.pub

Jetzt die zentrale Konfiguration, die alles verbindet:

# ~/.ssh/config
Host produktiv
    HostName server.firma.de
    User sam
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    AddKeysToAgent yes
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512

Host backup
    HostName 10.0.5.12
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_backup
    IdentitiesOnly yes

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

Testen Sie alle drei Verbindungen. Der GitHub-Test bestätigt die Authentifizierung, ohne eine Shell zu öffnen:

ssh produktiv "hostname && uptime"
ssh backup    "hostname"
ssh -T [email protected]
# Hi sam! You've successfully authenticated, but GitHub does not provide shell access.

Damit steht ein vollständiges, gehärtetes SSH-Setup mit drei zweckgebundenen Schlüsseln, deaktivierter Passwort-Anmeldung und Post-Quanten-Schlüsselaustausch. Dasselbe Prinzip schützt im Übrigen auch verschlüsselte Tunnel; ein Vergleich der VPN-Protokolle steht in unserem Beitrag WireGuard vs OpenVPN.

Häufige Fehler beim SSH-Key erstellen und wie Sie sie vermeiden

Diese Stolperfallen kosten erfahrungsgemäß die meiste Zeit. Wer sie kennt, spart sich stundenlange Fehlersuche.

  • Privater Schlüssel ohne Passphrase: Wird die Datei kopiert, ist der Zugang offen. Setzen Sie immer eine Passphrase plus -a 100.
  • Falsche Dateirechte: Ist ~/.ssh oder der Schlüssel zu offen (etwa 777), verweigert OpenSSH die Nutzung wortlos. chmod 700 bzw. 600 setzen.
  • Passwort-Login zu früh deaktiviert: Wer PasswordAuthentication no setzt, bevor der Schlüssel-Login getestet ist, sperrt sich aus. Immer erst im zweiten Terminal testen.
  • Öffentlichen mit privatem Schlüssel verwechselt: Auf den Server gehört nur die .pub-Datei. Den privaten Schlüssel niemals hochladen oder per E-Mail verschicken.
  • Schlüssel im falschen Verzeichnis: Liegt der Schlüssel nicht in ~/.ssh oder ist er nicht in der config referenziert, findet der Client ihn nicht. Mit IdentityFile explizit angeben.
  • Zu viele Schlüssel im Agenten: Ohne IdentitiesOnly yes probiert der Client alle Schlüssel durch und stößt an MaxAuthTries. Pro Host genau einen Schlüssel zuweisen.

Troubleshooting: Die 8 häufigsten SSH-Fehler beheben

Wenn der Login nicht klappt, hilft der ausführliche Modus ssh -vvv host, der jede Aushandlungsstufe protokolliert. Die folgende Tabelle ordnet die häufigsten Meldungen ihrer Ursache und Lösung zu.

FehlermeldungUrsacheLösung
Permission denied (publickey)Schlüssel nicht hinterlegt oder falscher Pfadauthorized_keys prüfen, IdentityFile setzen
Bad permissions / UNPROTECTED KEY FILEDateirechte zu offenchmod 600 auf den privaten Schlüssel
Too many authentication failuresAgent probiert zu viele SchlüsselIdentitiesOnly yes setzen
Agent admitted failure to signSchlüssel nicht im Agenten geladenssh-add ~/.ssh/id_ed25519 ausführen
Connection refusedsshd läuft nicht oder falscher PortDienststatus und Port prüfen
no matching key exchange methodAlgorithmen von Client und Server passen nichtOpenSSH aktualisieren, KexAlgorithms anpassen
Host key verification failedServer-Fingerabdruck geändertAlten Eintrag in known_hosts entfernen
sign_and_send_pubkey: signing failedFIDO2-Token nicht berührt oder PIN fehltToken einstecken, berühren, PIN eingeben

Ein konkretes Beispiel: Nach einem Server-Umzug mit gleicher IP, aber neuem Host-Schlüssel meldet SSH einen möglichen Angriff. Entfernen Sie den veralteten Eintrag gezielt:

# Veralteten Host-Schlüssel entfernen und neu verbinden
ssh-keygen -R server.firma.de
ssh produktiv   # akzeptiert den neuen Fingerabdruck nach Bestätigung

Profi-Tipps für fortgeschrittene SSH-Setups

Wer die Grundlagen beherrscht, hebt die Sicherheit mit diesen Techniken auf ein professionelles Niveau.

SSH-Zertifikate statt einzelner Schlüssel

Bei vielen Servern wird das Pflegen einzelner authorized_keys-Dateien mühsam. Eine SSH-Zertifizierungsstelle (CA) signiert öffentliche Schlüssel mit begrenzter Gültigkeit. Server vertrauen dann nur der CA, nicht jedem einzelnen Schlüssel:

# CA-Schlüssel erzeugen und einen Nutzerschlüssel für 8 Stunden signieren
ssh-keygen -t ed25519 -f ~/.ssh/ca_key -C "firmen-ca"
ssh-keygen -s ~/.ssh/ca_key -I "sam" -n sam -V +8h ~/.ssh/id_ed25519.pub

Die kurze Gültigkeit (-V +8h) bedeutet, dass ein abhandengekommener Schlüssel sich nach acht Stunden von selbst entwertet. Das langlebige Vertrauen einzelner Schlüssel entfällt damit komplett.

Zugriff pro Schlüssel einschränken

In der authorized_keys lässt sich vor jedem Schlüssel festlegen, was er darf. So bindet man einen Deploy-Key auf genau einen Befehl und unterbindet die Port-Weiterleitung:

# In ~/.ssh/authorized_keys auf dem Server
restrict,command="/usr/local/bin/deploy.sh",no-pty ssh-ed25519 AAAAC3Nz...== sam-deploy

Die Option restrict verbietet alles und gibt nur frei, was explizit erlaubt wird. So kann ein automatisierter Schlüssel ausschließlich das Deploy-Skript starten, aber keine interaktive Shell öffnen. Wer den Wert kryptografischer Verfahren grundsätzlich vertiefen möchte, findet eine Einordnung in unserer Übersicht zur Online-Sicherheit.

Verbindungen mit ControlMaster beschleunigen

Wer oft denselben Server anspricht, kann eine bestehende Verbindung wiederverwenden, statt jedes Mal neu auszuhandeln. Das spart spürbar Zeit bei Skripten:

# In ~/.ssh/config ergänzen
Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 600

Legen Sie zuvor das Verzeichnis an: mkdir -p ~/.ssh/sockets. Nach der ersten Verbindung bleibt der Tunnel zehn Minuten (600 Sekunden) offen und neue Verbindungen springen sofort darauf auf.

SSH-Schlüssel sichern und rotieren

Ein Schlüssel ist kein Ewigkeitsobjekt. Planen Sie eine Rotation: Erzeugen Sie regelmäßig (etwa jährlich oder beim Verdacht einer Kompromittierung) neue Schlüssel, verteilen Sie die neuen öffentlichen Teile und entfernen Sie die alten aus allen authorized_keys. Bewahren Sie den privaten Schlüssel niemals unverschlüsselt in einem Cloud-Backup auf. Wer ein Backup braucht, verschlüsselt es zusätzlich, etwa mit GnuPG oder einem Passwortmanager, der Dateianhänge unterstützt.

Die folgende Tabelle fasst eine sinnvolle Rotationspolitik für verschiedene Schlüsselzwecke zusammen.

SchlüsselzweckTypRotationBackupPassphrase
Persönlicher Logined25519JährlichVerschlüsseltPflicht
Hochsicherer Zuganged25519-sk (FIDO2)Bei VerlustResident auf TokenPIN + Touch
Deploy / CIed25519HalbjährlichIm Secret-StoreOptional, eingeschränkt
Kurzzeit-ZugangSSH-ZertifikatStündlich/täglichNicht nötigÜber CA
Legacy-Systemrsa 3072JährlichVerschlüsseltPflicht

SSH-Key erstellen auf Windows, macOS und Linux

Die Befehle in diesem Tutorial sind plattformübergreifend identisch, weil sie alle auf demselben OpenSSH-Client beruhen. Trotzdem gibt es bei der Einrichtung kleine Unterschiede, die immer wieder für Verwirrung sorgen. Wer auf einem Mac arbeitet und denselben Schlüssel später auf einem Windows-Rechner nutzen möchte, profitiert davon, die Eigenheiten jeder Plattform zu kennen.

Unter Linux ist OpenSSH praktisch immer vorinstalliert. Das Verzeichnis ~/.ssh liegt im Heimatverzeichnis, der Agent läuft meist über systemd oder den Schlüsselbund der Desktop-Umgebung. Unter macOS bringt das System ebenfalls einen OpenSSH-Client mit, der sich tief in den Schlüsselbund integriert. Die Option --apple-use-keychain sorgt dafür, dass die Passphrase nach der ersten Eingabe gespeichert bleibt, sodass selbst ein Neustart sie nicht erneut abfragt. Wer die jeweils neueste OpenSSH-Version braucht, etwa für die aktuellsten Post-Quanten-Algorithmen, installiert sie über Homebrew parallel zur Systemversion.

Unter Windows 10 und 11 ist der OpenSSH-Client als optionales Feature integriert. Das Schlüsselverzeichnis liegt unter %USERPROFILE%\.ssh, also typischerweise C:\Users\Name\.ssh. Der Authentifizierungs-Agent läuft als Windows-Dienst, der erst aktiviert werden muss. Eine häufige Stolperfalle: die Zeilenenden. Wer eine authorized_keys unter Windows mit einem ungeeigneten Editor bearbeitet, fügt unter Umständen Wagenrückläufe (CRLF) ein, die der Server nicht akzeptiert. Nutzen Sie deshalb die PowerShell oder einen Editor, der reine Unix-Zeilenenden (LF) speichert.

AspektLinuxmacOSWindows 10/11
OpenSSH vorinstalliertJaJaOptionales Feature
Schlüsselverzeichnis~/.ssh~/.ssh%USERPROFILE%\.ssh
Agentsystemd / gnome-keyringSchlüsselbundOpenSSH Authentication Agent
Passphrase speichernkeyring–apple-use-keychainssh-add im Dienst
Typische StolperfalleHeimverzeichnis-RechteAgent-NeustartCRLF-Zeilenenden

Der entscheidende Punkt: Der private Schlüssel funktioniert auf allen drei Systemen gleich, solange die Dateirechte stimmen. Sie können also auf dem Mac einen Schlüssel erzeugen und ihn auf einen Linux-Laptop kopieren, ohne ihn neu zu erstellen. Nur die Rechte müssen Sie nach dem Kopieren erneut setzen, weil sie beim Transfer über manche Dateisysteme verloren gehen.

SSH-Key gegen Passwort: Der Sicherheitsvergleich

Warum überhaupt der Aufwand mit Schlüsseln, wenn ein Passwort doch schneller eingerichtet ist? Die Antwort liegt im Angriffsmodell. Ein Passwort ist ein gemeinsames Geheimnis, das bei jeder Anmeldung über die Leitung muss und auf dem Server in irgendeiner Form überprüft wird. Es lässt sich erraten, abfangen, per Phishing entlocken oder aus einem geleakten Datensatz wiederverwenden. SSH-Dienste, die Passwörter erlauben, verzeichnen im offenen Internet permanent automatisierte Anmeldeversuche, oft Tausende pro Tag und Server.

Ein SSH-Schlüssel funktioniert grundlegend anders. Der private Teil verlässt nie Ihren Rechner. Bei der Anmeldung beweist der Client dem Server kryptografisch, dass er den privaten Schlüssel besitzt, ohne ihn jemals zu übertragen. Ein Angreifer, der den Netzwerkverkehr mitschneidet, lernt nichts Verwertbares. Selbst wenn die authorized_keys-Datei auf dem Server in falsche Hände gerät, enthält sie nur öffentliche Schlüssel, mit denen sich niemand anmelden kann.

Die Größenordnung des Unterschieds ist gewaltig. Ein ed25519-Schlüssel bietet ein Sicherheitsniveau von rund 128 Bit. Das bedeutet, ein Angreifer müsste im Mittel in der Größenordnung von 2 hoch 128 Operationen durchführen, um ihn zu brechen. Diese Zahl ist so groß, dass kein heute existierender oder absehbarer klassischer Computer sie bewältigt. Ein typisches Nutzerpasswort dagegen lässt sich, wenn es schwach gewählt ist, in Minuten oder Stunden durchprobieren. Kombiniert man den Schlüssel mit einem FIDO2-Token, kommt eine physische Komponente hinzu, die selbst ein kompromittierter Rechner nicht ersetzen kann.

Für Unternehmen kommt ein praktischer Vorteil hinzu: Nachvollziehbarkeit. Jeder Schlüssel lässt sich einer Person oder einem Dienst zuordnen und einzeln widerrufen, ohne dass alle anderen Zugänge geändert werden müssen. Bei gemeinsamen Passwörtern ist das unmöglich. Genau deshalb schreiben viele Compliance-Rahmenwerke und auch die BSI-Empfehlungen die schlüsselbasierte Authentifizierung für administrative Zugänge vor. Wer tiefer in die Frage einsteigen will, wie sichere Authentifizierung im Alltag aussieht, findet weitere Bausteine in unserer Übersicht zur Online-Sicherheit.

SSH-Key in CI/CD und Automatisierung nutzen

In automatisierten Umgebungen wie GitHub Actions, GitLab CI oder einem Deployment-Skript gibt es keinen Menschen, der eine Passphrase eintippt. Hier braucht es ein durchdachtes Vorgehen, damit Automatisierung nicht zur Sicherheitslücke wird. Der Schlüssel der Wahl ist ein dedizierter Deploy-Key, der nur das Nötigste darf und sich von Ihren persönlichen Schlüsseln vollständig trennt.

Erzeugen Sie für die Pipeline einen eigenen Schlüssel, hinterlegen Sie den öffentlichen Teil als read-only Deploy-Key im Repository oder auf dem Zielserver und legen Sie den privaten Teil als verschlüsseltes Secret im CI-System ab. Niemals den privaten Schlüssel im Repository selbst speichern, auch nicht in einem vermeintlich privaten. So sieht der Kern eines Deployment-Schritts aus:

# Beispiel: Deployment-Schritt mit Schlüssel aus einem CI-Secret
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "$DEPLOY_KEY" > ~/.ssh/id_deploy
chmod 600 ~/.ssh/id_deploy

# Host-Schlüssel des Servers vorab eintragen, damit keine Rückfrage hängt
ssh-keyscan -t ed25519 server.firma.de >> ~/.ssh/known_hosts

# Mit explizitem Schlüssel deployen, ohne Agent
ssh -i ~/.ssh/id_deploy -o IdentitiesOnly=yes [email protected] \
  "cd /var/www/app && git pull && systemctl --user restart app"

Der Befehl ssh-keyscan ist hier wichtig: Ohne vorher hinterlegten Host-Schlüssel würde die Verbindung auf eine interaktive Bestätigung warten, die in einer Pipeline nie kommt, und das Skript bliebe hängen. Beschränken Sie den Deploy-Key zusätzlich serverseitig mit der in den Profi-Tipps gezeigten command-Option auf genau die erlaubte Aktion. Ein in einem CI-Log versehentlich ausgegebener, aber eingeschränkter Schlüssel richtet dann kaum Schaden an.

Für sehr sicherheitskritische Pipelines lohnt der Blick auf kurzlebige SSH-Zertifikate statt statischer Deploy-Keys. Die Pipeline holt sich dann zu Beginn ein nur wenige Minuten gültiges Zertifikat von einer CA, und nach dem Lauf existiert kein dauerhaft gültiger Zugang mehr. Das reduziert die Angriffsfläche erheblich, weil ein geleaktes Zertifikat schnell wertlos wird.

Häufig gestellte Fragen (FAQ)

Wie kann ich einen SSH-Key erstellen, der zu GitHub und meinem Server passt?

Erzeugen Sie für jeden Zweck einen eigenen ed25519-Schlüssel und ordnen Sie ihn in der ~/.ssh/config dem jeweiligen Host zu. Ein Schlüssel für GitHub, ein anderer für den Server. So bleibt bei einem kompromittierten Schlüssel der Rest sicher, und Sie können einzelne Zugänge gezielt widerrufen.

ed25519 oder RSA: Was soll ich 2026 nehmen?

Nehmen Sie ed25519. Es ist sicherer bei kleinerer Schlüssellänge, schneller und unempfindlicher gegen schlechte Zufallszahlen. RSA mit mindestens 3072 Bit nutzen Sie nur, wenn ein altes System ed25519 nicht versteht.

Muss ich eine Passphrase setzen?

Ja. Ohne Passphrase ist der private Schlüssel eine Klartext-Eintrittskarte, sobald jemand die Datei kopiert. Der ssh-agent sorgt dafür, dass Sie die Passphrase trotzdem nur einmal pro Sitzung eingeben müssen.

Wo wird der SSH-Key gespeichert?

Standardmäßig im Verzeichnis ~/.ssh. Der private Schlüssel heißt id_ed25519, der öffentliche id_ed25519.pub. Auf dem Server landet der öffentliche Schlüssel in ~/.ssh/authorized_keys des Zielkontos.

Wie übertrage ich meinen Schlüssel auf einen neuen Computer?

Kopieren Sie das Verzeichnis ~/.ssh über einen verschlüsselten Kanal (zum Beispiel scp oder einen verschlüsselten USB-Stick). Setzen Sie danach sofort wieder die Rechte mit chmod 700 ~/.ssh und chmod 600 ~/.ssh/id_ed25519. Bei Hardware-Schlüsseln stecken Sie einfach das Token um und stellen residente Schlüssel mit ssh-keygen -K wieder her.

Schützt ein SSH-Key vor Quantencomputern?

Der Schlüssel allein nicht direkt, aber der Schlüsselaustausch beim Verbindungsaufbau lässt sich quantensicher machen. Aktivieren Sie hybride Verfahren wie mlkem768x25519-sha256, wie in Schritt 10 gezeigt. Das schützt gegen das Szenario, in dem heute abgefangener Verkehr später entschlüsselt wird.

Was tue ich, wenn ich die Passphrase vergessen habe?

Die Passphrase lässt sich nicht wiederherstellen, das ist ihr Sinn. Erzeugen Sie ein neues Schlüsselpaar, verteilen Sie den neuen öffentlichen Schlüssel auf alle Server und entfernen Sie den alten Eintrag aus den authorized_keys. Genau deshalb lohnt eine durchdachte Rotationspolitik.

Fazit: In 30 Minuten zum sicheren SSH-Zugang

Wer einen SSH-Key erstellen und richtig einsetzen will, braucht keine Stunden. Die Kernschritte sind: ed25519-Schlüssel mit Passphrase und -a 100 erzeugen, mit ssh-copy-id verteilen, Dateirechte setzen, in der config ordnen und schließlich die Passwort-Anmeldung abschalten. Wer mehr Sicherheit will, ergänzt einen FIDO2-Hardware-Schlüssel und den Post-Quanten-Schlüsselaustausch. Das Ergebnis ist ein Zugang, der gegen Brute-Force, gestohlene Passwörter und sogar künftige Quantenangriffe gewappnet ist.

Der wichtigste Rat zum Schluss: Testen Sie jeden Schritt, bevor Sie den nächsten gehen, und schließen Sie niemals Ihre letzte funktionierende Sitzung, bevor der neue Login bestätigt ist. Dann ist ein gehärteter SSH-Zugang weniger Risiko und mehr Routine.

Verwandte Beiträge

Externe Quellen