SSH-Keys — Vom Protokoll zum sichersten Algorithmus

01 — Entstehungsgeschichte

Warum es SSH überhaupt gibt

Eine echte Chronologie — jeder Schritt entstand als direkte Antwort auf die Schwächen des vorherigen.

1995

SSH-1 — Tatu Ylönen, TU Helsinki

Nach einem Passwort-Sniffing-Angriff im Universitätsnetzwerk entwickelt Ylönen SSH als verschlüsselten Ersatz für die damals üblichen Klartext-Protokolle rlogin, rsh und telnet. Passwörter und Sitzungsdaten wandern erstmals verschlüsselt über das Netz.

1996

SSH-2 — komplette Neukonzeption

SSH-1 hatte strukturelle Schwächen (u.a. Integritätsprobleme bei CRC32). SSH-2 trennt das Protokoll sauber in drei Schichten: Transport, Authentication und Connection. Nicht abwärtskompatibel zu SSH-1 — bewusst.

1999

OpenSSH entsteht

Als die ursprüngliche SSH-Lizenz restriktiver wird, forkt das OpenBSD-Team die letzte freie Version (1.2.12) zu OpenSSH. Es wird binnen weniger Jahre zur de-facto-Standardimplementierung.

2006

IETF-Standardisierung

Die IETF gießt SSH-2 in die RFCs 4251–4256. Das Protokoll ist damit herstellerunabhängig spezifiziert.

2011

Ed25519 — Bernstein, Duif, Lange, Schwabe, Yang

Ein Forscherteam um Daniel J. Bernstein veröffentlicht Ed25519 auf Basis der elliptischen Kurve Curve25519 — es löst die Schwächen älterer Verfahren elegant und wird zur empfohlenen Standardwahl.

2020 – heute

Hardware-Keys & Post-Quantum-Vorbereitung

OpenSSH 8.2 bringt FIDO2/U2F-Unterstützung (ed25519-sk). Seit OpenSSH 9.0 wird für den Schlüsselaustausch standardmäßig ein hybrides post-quantensicheres Verfahren genutzt (sntrup761x25519).

02 — Kryptografischer Hintergrund

Die Schlüsseltypen im Vergleich

Jeder Algorithmus löst ein Problem seines Vorgängers — und bringt ein neues mit.

DSA

Entfernt seit OpenSSH 7.0

1991 · NIST1024 bit fix

Starr auf 1024 bit begrenzt, gilt als unsicher. Seit 2021 in OpenSSH vollständig entfernt.

RSA

Solide, aber alt

1977 · Rivest/Shamir/Adleman3072–4096 bit

Basiert auf der Schwierigkeit der Faktorisierung großer Primzahlprodukte. Mit ausreichender Länge sicher, aber größer und langsamer als Kurvenverfahren.

+--[RSA 3072]----+ | . o+. | | . +.oo | | . o +o+E | | . =.=+o | | . o S.o. | | o + o | | + . | | o | | | +-----------------+

ECDSA

Umstritten

~2005 · NIST-Kurven256/384/521 bit

Kompakter als RSA, aber NIST-Kurvenparameter stehen unter Backdoor-Verdacht. Schlechte RNG-Implementierungen führten 2010 zum Bruch des Sony-PS3-Signaturschlüssels.

+--[ECDSA 256]---+ | .o=*O%*+. | | +=+X*B. | | ..*+*.o | | . +.o o | | .S | | | | | | | | | +-----------------+

Ed25519

Empfehlung

2011 · Bernstein et al.256 bit / 68 Zeichen

Deterministische Signaturen — kein RNG-Risiko. Kleine, schnelle Schlüssel ohne bekannte Kurven-Bedenken. Heute Standard für neue Deployments.

+--[ED25519]-----+ | .+=*#@+ | | . o+*+%*. | | . .oo=+o | | .+ o . | | S . | | | | | | | | | +-----------------+

Ed25519-SK

Hardware-gebunden

2020 · OpenSSH 8.2FIDO2/U2F

Der private Schlüssel verlässt nie ein Hardware-Token (z. B. YubiKey). Für kritische Zugänge derzeit die robusteste Option.

Post-Quantum (KEX)

Zukunft, teils schon aktiv

seit OpenSSH 9.0sntrup761x25519

Betrifft den Schlüsselaustausch: hybrides Verfahren aus klassischem X25519 und post-quantensicherem NTRU Prime.

03 — Praxis

SSH-Keys erzeugen — je Plattform

Alle Befehle nutzen ed25519 als empfohlenen Standard.

Debian, Ubuntu, Linux Mint

# Client installieren
sudo apt update && sudo apt install openssh-client -y

# Schlüsselpaar erzeugen
ssh-keygen -t ed25519 -a 100 -C "jan@netcore-media"

# ssh-agent starten und Key laden
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# Public Key auf Zielserver übertragen
ssh-copy-id user@zielserver.de

Für dauerhaftes Laden: Eintrag in ~/.ssh/config mit AddKeysToAgent yes.

RHEL, Fedora, CentOS Stream, Rocky Linux, AlmaLinux

# Client installieren
sudo dnf install openssh-clients -y

# Schlüsselpaar erzeugen
ssh-keygen -t ed25519 -a 100 -C "jan@netcore-media"

# ssh-agent starten und Key laden
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# Public Key übertragen
ssh-copy-id user@zielserver.de

# Falls SELinux blockiert
restorecon -R -v ~/.ssh

SELinux im Enforcing-Modus verlangt korrekte Kontexte für ~/.ssh.

macOS

# Schlüsselpaar erzeugen
ssh-keygen -t ed25519 -a 100 -C "jan@netcore-media"

# Passphrase in der macOS-Keychain speichern
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Für automatisches Laden bei jedem Login, ~/.ssh/config ergänzen:

Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_ed25519

Windows 10 / 11 (OpenSSH-Client integriert seit Build 1809)

# PowerShell (Administrator) — prüfen ob installiert
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'

# Falls nicht vorhanden, installieren
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

# Schlüsselpaar erzeugen
ssh-keygen -t ed25519 -a 100 -C "jan@netcore-media"

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

Alternative für Legacy-Setups: PuTTYgen — für OpenSSH-Kompatibilität aber ssh-keygen bevorzugen.

Windows Server 2019 / 2022

# PowerShell (Administrator) — OpenSSH-Features installieren
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

# sshd-Dienst aktivieren
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

# Schlüsselpaar auf dem Client erzeugen
ssh-keygen -t ed25519 -a 100 -C "jan@netcore-media"

Für Administratoren-Konten erwartet Windows den Public Key zusätzlich in C:\ProgramData\ssh\administrators_authorized_keys mit angepassten ACLs.

05 — Absicherung

Best Practices

PASSPHRASE

Immer setzen

Ein Private Key ohne Passphrase ist bei Diebstahl sofort nutzbar.

BERECHTIGUNGEN

chmod korrekt setzen

chmod 700 ~/.ssh, chmod 600 Private Key, chmod 644 Public Key.

TRENNUNG

Ein Key pro Zweck

Separate Schlüssel für Produktion, private Projekte und Drittanbieter.

ROTATION

Alte Keys ablösen

Verwaiste Public Keys regelmäßig aus authorized_keys entfernen.

HARDWARE

Kritische Zugänge härten

Für Root-Zugriffe ed25519-sk mit FIDO2-Token nutzen.

SERVER-SEITIG

authorized_keys absichern

Passwort-Login serverseitig deaktivieren, sobald Keys eingerichtet sind.

SSH-Keys.
Vom Protokoll
zum sichersten Algorithmus.