Entstehungsgeschichte, kryptografischer Hintergrund und exakte Schritt-für-Schritt-Anleitungen für Debian- & RedHat-basierte Linux-Distributionen, macOS, Windows und Windows Server.
Eine echte Chronologie — jeder Schritt entstand als direkte Antwort auf die Schwächen des vorherigen.
rlogin, rsh und telnet. Passwörter und Sitzungsdaten wandern erstmals verschlüsselt über das Netz.ed25519-sk). Seit OpenSSH 9.0 wird für den Schlüsselaustausch standardmäßig ein hybrides post-quantensicheres Verfahren genutzt (sntrup761x25519), seit OpenSSH 10.0 (April 2025) das NIST-standardisierte mlkem768x25519-sha256.ssh-keygen -t dsa oder RSA-2048 statt Ed25519? Solche Artikel stammen oft aus einer Zeit, in der DSA/RSA Standard waren, und werden danach selten grundlegend überarbeitet — ein gutes Beispiel dafür, dass "seit Jahren online" nicht "aktuell" bedeutet. Vor dem Kopieren von Befehlen aus alten Anleitungen lohnt sich immer ein Blick auf das Veröffentlichungsdatum.
SSH ist keine Firma und kein einzelnes Produkt, sondern ein Geflecht aus Protokoll-Standards, Referenzimplementierungen und unabhängig entwickelten Signaturalgorithmen. Hier die Kette von Urheberschaft bis heutigem Steward.
Kurz zusammengefasst: Das Protokoll liegt in der Hand der IETF, die Referenzimplementierung beim OpenBSD-Projekt, und jeder Signatur-/KEX-Algorithmus stammt aus einer eigenen, meist akademischen Forschungslinie mit eigener Historie — deshalb altern sie auch unterschiedlich schnell.
Jeder Algorithmus löst ein Problem seines Vorgängers — und bringt ein neues mit.
sntrup761x25519 (OpenSSH 9.0–9.9). Schutz gegen „Harvest now, decrypt later"-Angriffe. Für die Authentifizierung selbst bleibt Ed25519 vorerst die beste Wahl, bis post-quantensichere Signaturverfahren (ML-DSA/FIPS 204) in OpenSSH integriert sind.Alle Befehle nutzen ed25519 als empfohlenen Standard.
# 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
~/.ssh/config mit AddKeysToAgent yes.# 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
~/.ssh.# 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
# 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
ssh-keygen bevorzugen.# 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"
C:\ProgramData\ssh\administrators_authorized_keys mit angepassten ACLs.Erst die geführte Demo zum Kennenlernen, danach der Prüfungsmodus: Baue die Befehle selbst zusammen — per Baukasten oder freier Eingabe. Ab 70 % korrekt im ersten Versuch gibt es das Zertifikat.
Gib eine E-Mail-Adresse an, um dein personalisiertes SSH-Zertifikat auszustellen. Es wird sicher im Vault abgelegt und ist nur über diesen Browser-Session-Link abrufbar.
Service-ID dieser Sitzung: 1649DA42-2607251507 — bei Support-Anfragen bitte angeben.
Ein Private Key ohne Passphrase ist bei Diebstahl sofort nutzbar.
chmod 700 ~/.ssh, chmod 600 Private Key, chmod 644 Public Key.
Separate Schlüssel für Produktion, private Projekte und Drittanbieter.
Verwaiste Public Keys regelmäßig aus authorized_keys entfernen.
Für Root-Zugriffe ed25519-sk mit FIDO2-Token nutzen.
Passwort-Login serverseitig deaktivieren, sobald Keys eingerichtet sind.
Separaten Nutzer anlegen, erst danach PermitRootLogin no setzen. Nach erfolgreichem Key-Test zusätzlich PasswordAuthentication no und ChallengeResponseAuthentication no — erst dann ist Public-Key-Only aktiv.
Kontextbezogene Hinweise für den aktuellen Schritt:
Versionierte Historie aller Features, Verbesserungen und Fixes dieses Projekts.
-a 100 oder administrators_authorized_keys wurden fälschlich als "verbotener Baustein" erkannt, weil kürzere Distraktoren (-a 10, authorized_keys) als Teilstring darin vorkamen. Baukasten-Modus prüft jetzt rein anhand der ausgewählten Baustein-IDs statt per Text-Matching.includes()-Tests, um dieselbe Klasse von Fehltreffern zu verhindern.-v einen nach Groß-/Kleinschreibungs-Normalisierung mehrdeutigen Distraktor (identisch zur korrekten Lösung -V) — ersetzt durch einen eindeutigen Distraktor (sshd -V).