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. Backlinks führen zu Primärquellen; diese Seite ist Teil des Projekts ssh.webservice.digital von NETCORE⚡MEDIA, Maintainer: Jan Gebser.
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, dir per Mail zugestellt und ist über die Cert-ID unten im Footer erneut abrufbar.
Service-ID dieser Sitzung: 33C91354-2609220252 — bei Support-Anfragen bitte angeben.
Dein Fortschritt in dieser Prüfungssession geht dabei verloren. Der Versuch zählt nicht als Fehlversuch — du kannst danach direkt neu starten.
Kontextbezogene Hinweise für den aktuellen Schritt:
Klicke eine Karte für Details. Beim Hover markiert sich die Karte grün — so wie ein Pentester eine offene Angriffsfläche markieren würde.
Ein Private Key ohne Passphrase ist bei Diebstahl sofort nutzbar.
↻ Detailsssh-keygen -p -f ~/.ssh/id_ed25519 ändert sie nachträglichchmod 700 ~/.ssh, chmod 600 Private Key, chmod 644 Public Key.
authorized_keys auf dem Server: 600Separate Schlüssel für Produktion, private Projekte und Drittanbieter.
↻ Details~/.ssh/config mit IdentityFile je Host-Eintrag-C) je Zweck vergebenVerwaiste 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.
↻ DetailsPasswordAuthentication no in sshd_configsshd -t vor Neustart zur Syntax-Prüfung nutzenSeparaten Nutzer anlegen, erst danach PermitRootLogin no setzen.
PermitRootLogin noPasswordAuthentication no + ChallengeResponseAuthentication noAuch mit Key-Only-Auth lohnt sich ein Blick auf fehlgeschlagene Login-Versuche.
↻ Detailsfail2ban sperrt IPs nach wiederholten Fehlversuchenjournalctl -u sshd / /var/log/auth.log prüfenAngaben gemäß § 5 TMG
NETCORE⚡MEDIA — Digital Solutions & Managed Hosting
Inhaber: Jan Gebser
[Straße, Hausnummer]
[PLZ, Ort]
Deutschland
Kontakt: [Telefonnummer] · [E-Mail-Adresse]
Web: netcore.digital · ssh.webservice.digital
Verantwortlich für den Inhalt nach § 55 Abs. 2 RStV: Jan Gebser (Anschrift wie oben)
Über dieses Projekt: ssh.webservice.digital ist ein Lern- und Simulationsprojekt von NETCORE⚡MEDIA rund um SSH-Schlüssel, Protokoll-Geschichte und Server-Härtung — Teil des Webservice.Digital-Portfolios für praxisnahe IT-Security-Weiterbildung.
Platzhalter-Impressum — vor Live-Schaltung mit vollständigen, ladungsfähigen Angaben ersetzen (u. a. Anschrift, Telefonnummer, ggf. USt-IdNr.).
NETCORE⚡MEDIA nimmt den Schutz personenbezogener Daten ernst — Sicherheit ist bei uns nicht nur Lerninhalt dieses Projekts, sondern gelebter Anspruch an die eigene Infrastruktur. Diese Anwendung verarbeitet personenbezogene Daten ausschließlich im Rahmen der hier beschriebenen Funktionen, im Einklang mit DSGVO und TTDSG.
1. Playground & Zertifikat
Bei Ausstellung eines Zertifikats werden Nutzername, E-Mail-Adresse, Session-ID, Kurs-Typ und Erfolgsquote in einer nicht öffentlich erreichbaren Datenbank ("Vault") gespeichert, um das Zertifikat per Cert-ID erneut abrufbar zu machen und per E-Mail zuzustellen. Eine Weitergabe an Dritte erfolgt nicht. Die Cert-ID selbst fungiert als unguessable Freigabe-Token für die optionale, freiwillig teilbare Verify-Seite.
2. Bug-Reports
Nachrichten aus dem Lightbulb-Formular werden zusammen mit der Service-ID (aus der Session abgeleitet, kein Personenbezug) gespeichert, um Support-Anfragen einem Sitzungsverlauf zuordnen zu können.
3. Besucher-Übersicht (Visitor-Badge)
Zur Anzeige aktiver Besucher/Bots im Header wird eine zufällige, nicht personenbezogene Client-ID (lokal im Browser erzeugt) zusammen mit einem Zeitstempel und dem User-Agent für maximal 24 Stunden gespeichert. Der User-Agent wird ausschließlich zur Erkennung bekannter Suchmaschinen-Crawler ausgewertet, nicht zur individuellen Nutzerverfolgung.
4. Konzentrationsmodus & Musik-Streaming
Der Status "Prüfung aktiv" wird serverseitig in der PHP-Session gespeichert, um den Zugriff auf die Konzentrationsmusik freizugeben. Es werden keine Hörgewohnheiten oder Wiedergabedaten gespeichert.
5. Einstellungen
Theme, Akzentfarben, Textfarbe, Nutzername und Animationsgeschwindigkeit werden ausschließlich lokal im Browser (localStorage) gespeichert und nie an den Server übertragen.
Platzhalter-Datenschutzerklärung — vor Live-Schaltung juristisch prüfen lassen (insbesondere Speicherfristen, Betroffenenrechte, Auftragsverarbeitung des Hosters).
1. Geltungsbereich
Diese Bedingungen gelten für die Nutzung der interaktiven Simulator- und Playground-Umgebung unter ssh.webservice.digital, einem Angebot von NETCORE⚡MEDIA.
2. Leistungsumfang
Die Plattform dient ausschließlich Lern- und Demonstrationszwecken rund um SSH-Schlüssel, Protokollgeschichte und Server-Härtung. Ausgestellte Zertifikate bestätigen den erfolgreichen Durchlauf der interaktiven Übung (Baukasten- bzw. Kommandozeilen-Modus, Mindest-Erfolgsquote 70 %) und stellen keine offizielle, extern anerkannte oder zertifizierungsstellen-akkreditierte Qualifikation dar.
3. Kostenlose Nutzung
Die Nutzung erfolgt unentgeltlich; ein Anspruch auf dauerhafte Verfügbarkeit, bestimmte Reaktionszeiten oder eine Service-Level-Garantie besteht für dieses Lernangebot nicht (anders als bei den kommerziellen Hosting- und Infrastruktur-Leistungen von NETCORE⚡MEDIA unter netcore.digital, für die gesonderte Vereinbarungen gelten).
4. Änderungen
NETCORE⚡MEDIA behält sich vor, Inhalte, Funktionsumfang, Prüfungskriterien und die Konzentrationsmusik-Auswahl jederzeit anzupassen, zu erweitern oder einzustellen.
5. Haftung
Alle Inhalte werden nach bestem Wissen erstellt, es wird jedoch keine Gewähr für Vollständigkeit, Aktualität oder Anwendbarkeit auf reale Produktivsysteme übernommen. Für Schäden durch die Anwendung der gezeigten Befehle auf eigenen oder fremden Systemen wird keine Haftung übernommen.
Platzhalter-AGB — vor Live-Schaltung juristisch prüfen lassen.
Diese Anwendung setzt keine Tracking- oder Werbe-Cookies und keine Cookies von Drittanbietern. Für den Betrieb werden ausschließlich folgende, technisch notwendige Speicher genutzt:
Da keine Einwilligungspflichtigen Cookies (Marketing/Tracking) gesetzt werden, ist aktuell kein Cookie-Consent-Banner im Sinne des TTDSG erforderlich.
Platzhalter-Cookie-Hinweis — bei künftiger Erweiterung um Analyse-/Marketing-Tools entsprechend anpassen und Consent-Banner ergänzen.
Vertiefende Hinweise über die Kachel-Kurzfassungen hinaus.
grep "Failed password" /var/log/auth.log | tail -50 (Debian/Ubuntu) bzw. journalctl -u sshd --since "1 hour ago" (systemd-basiert) zeigen fehlgeschlagene Versuche. Viele Treffer von derselben IP sind ein klares Signal für fail2ban.
Sie schließt Passwort-Brute-Force sicher aus, ersetzt aber keine Systempflege: Betriebssystem-Updates, aktuelle OpenSSH-Version und ein enges AllowUsers/AllowGroups in sshd_config bleiben wichtig.
Vor jedem systemctl reload sshd: sshd -t ausführen. Zusätzlich eine zweite, bereits offene Session behalten, bis die neue Konfiguration bestätigt funktioniert — sonst droht ein Lockout.
Sofort den zugehörigen Public Key aus allen authorized_keys-Dateien entfernen (Rotation), Passphrase allein reicht nicht als alleinige Absicherung bei Verlust. Bei Hardware-Keys (ed25519-sk) ist das Risiko deutlich geringer, da der private Schlüssel nie exportierbar ist.
Kleinere, schnellere Keys allein machen ein System nicht sicherer — kombiniert mit Passphrase, korrekten Rechten und Server-Härtung ergibt sich aber eine deutlich robustere Gesamtkette als ein einzelner starker Baustein.
Inhalt der .pub-Datei mit type $env:USERPROFILE\.ssh\id_ed25519.pub anzeigen, per SSH-Session öffnen und an ~/.ssh/authorized_keys anhängen — oder direkt mit Get-Content ... | ssh user@host "cat >> ~/.ssh/authorized_keys" in einem Schritt.
Ja — pro Account einen eigenen Key erzeugen und in ~/.ssh/config je einen eigenen Host-Alias mit passendem IdentityFile anlegen (z. B. github-privat und github-arbeit), dann per Remote-URL gezielt ansteuern.
Der Host-Key des Servers hat sich geändert — meist nach einer Neuinstallation, kann aber auch ein Angriffsversuch (Man-in-the-Middle) sein. Änderung verifizieren, dann den veralteten Eintrag gezielt mit ssh-keygen -R hostname entfernen statt die ganze known_hosts zu löschen.
ssh -A leitet den lokalen Agent zum Remote-Host weiter, damit dieser sich mit deinem Key bei weiteren Hosts authentifizieren kann. Riskant auf Servern, denen du nicht vollständig vertraust — Root dort kann den weitergeleiteten Agent missbrauchen. Alternative: ProxyJump statt Forwarding.
ssh -J bastion.example.com user@intern.example.com springt über den Bastion-Host, ohne dass der Zielserver direkt erreichbar sein muss. Dauerhaft in ~/.ssh/config als ProxyJump bastion.example.com unter dem Ziel-Host-Eintrag hinterlegen.
OpenSSH probiert alle im Agent geladenen Keys der Reihe nach durch, bis das Server-Limit erreicht ist. Mit IdentitiesOnly yes und explizitem IdentityFile je Host-Eintrag in ~/.ssh/config wird gezielt nur der richtige Key angeboten.
Private Keys grundsätzlich nicht unverschlüsselt synchronisieren (auch nicht über Cloud-Speicher). Sinnvoller: pro Gerät einen eigenen Key erzeugen und alle Public Keys in den jeweiligen authorized_keys hinterlegen — das erhält zusätzlich die Rotations-/Trennungs-Vorteile aus den Best Practices.
known_hosts liegt beim Client und bestätigt die Identität des Servers. authorized_keys liegt beim Server und legt fest, welche Public Keys sich anmelden dürfen. Beide Richtungen der Vertrauensprüfung sind unabhängig voneinander.
Port in sshd_config anpassen, Firewall-Regel für den neuen Port ergänzen, bevor der alte Port geschlossen wird, und die Verbindung über eine zweite offene Session testen. Reduziert automatisiertes Scanner-Rauschen, ersetzt aber keine der anderen Härtungsmaßnahmen.
Über die Server-Konsole des Hosters (z. B. VNC/Rescue-System, unabhängig von SSH) einloggen, sshd -t zur Fehlersuche nutzen, die Konfiguration korrigieren und systemctl restart sshd ausführen. Prävention: Änderungen immer nur bei einer zweiten offenen Session testen (siehe oben).
Zuletzt aktualisiert: 26.07.2026 (v1.7) — 15 FAQs, 15 Tipps in 7 Kategorien.
Versionierte Historie aller Features, Verbesserungen und Fixes dieses Projekts.
currentColor), inkl. Expand-/Collapse-Wechsel je nach Zustand.#playground und wurden dadurch von der Fullscreen-API im Konzentrationsmodus komplett ausgeblendet — alle drei liegen jetzt als Geschwister von .wrap innerhalb der Playground-Sektion (sichtbar im Vollbild, aber vom Abbrechen-Blur-Filter unberührt). Panel-Sichtbarkeit wird zusätzlich beim Moduswechsel innerhalb eines bestehenden Vollbilds neu geprüft.INSERT OR REPLACE umgestellt. Zusätzlich klare Tooltip-Texte für "niemand aktiv" und "Zähler nicht erreichbar" ergänzt.\u2192-Text statt eines echten Pfeils.-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).