{"id":58,"date":"2026-06-11T16:21:39","date_gmt":"2026-06-11T16:21:39","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/11\/ssh-key-erstellen-ed25519-2026\/"},"modified":"2026-06-11T16:21:39","modified_gmt":"2026-06-11T16:21:39","slug":"ssh-key-erstellen-ed25519-2026","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/11\/ssh-key-erstellen-ed25519-2026\/","title":{"rendered":"SSH-Key erstellen: Ed25519 in 8 Schritten [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Ein gestohlenes Passwort ist 2026 die h\u00e4ufigste Eintrittst\u00fcr in fremde Server. SSH-Keys schlie\u00dfen diese T\u00fcr: Statt einer Zeichenkette, die man erraten, abfangen oder per Phishing abgreifen kann, authentifizierst du dich mit einem kryptografischen Schl\u00fcsselpaar, das niemals \u00fcber die Leitung wandert. In diesem Tutorial lernst du, einen <strong>SSH-Key zu erstellen<\/strong>, ihn auf Server und in GitHub einzubinden und deinen Zugang so zu h\u00e4rten, dass Passwort-Logins komplett verschwinden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wir setzen auf Ed25519, den 2026 empfohlenen Standard, zeigen alle Befehle f\u00fcr Linux, macOS und Windows 11 und gehen bis zu FIDO2-Hardware-Keys und post-quanten-sicherem Schl\u00fcsselaustausch in OpenSSH 10. Am Ende steht ein komplettes, lauff\u00e4higes Projekt: ein abgesicherter SSH-Zugang von Null auf, in unter 30 Minuten. Alle Befehle sind getestet, jede Konfiguration kommentiert.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"warum-du-2026-einen-ssh-key-erstellen-solltest\">Warum du 2026 einen SSH-Key erstellen solltest<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">SSH (Secure Shell) nutzt asymmetrische Kryptografie. Du erzeugst ein Paar aus privatem und \u00f6ffentlichem Schl\u00fcssel. Der private Schl\u00fcssel bleibt auf deinem Rechner und verl\u00e4sst ihn nie. Den \u00f6ffentlichen Schl\u00fcssel legst du auf jedem Server ab, auf den du zugreifen willst. Beim Login beweist dein Client, dass er den passenden privaten Schl\u00fcssel besitzt, ohne ihn jemals zu \u00fcbertragen. Genau dieses Prinzip kennst du aus den <a href=\"\/digital-signatures\/\">digitalen Signaturen<\/a>: Wer den privaten Schl\u00fcssel h\u00e4lt, kann signieren, und jeder mit dem \u00f6ffentlichen Schl\u00fcssel kann die Signatur pr\u00fcfen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Sicherheitsgewinn ist messbar. Ein automatisierter Brute-Force-Angriff testet Tausende Passw\u00f6rter pro Minute gegen offene SSH-Ports. Gegen einen Ed25519-Schl\u00fcssel ist dieser Angriff sinnlos: Der Schl\u00fcsselraum ist so gro\u00df, dass Raten unm\u00f6glich wird. Sobald du Passwort-Logins abschaltest, fallen die typischen W\u00f6rterbuch- und Credential-Stuffing-Angriffe einfach ins Leere. Bots, die deinen Port scannen, bekommen schlicht keinen Hebel mehr.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Hinzu kommt der Komfort. Hast du einen <strong>SSH-Key erstellt<\/strong> und in den ssh-agent geladen, loggst du dich ohne Passworteingabe ein. Du verbindest dich mit Servern, ziehst Code von GitHub und automatisierst Deployments, ohne st\u00e4ndig Zeichenketten einzutippen. Sicherheit und Bequemlichkeit ziehen hier ausnahmsweise am selben Strang. Wer einmal sauber eingerichtet hat, will nicht zur\u00fcck.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein dritter Punkt betrifft die Zukunft. Klassische Schl\u00fcsselaustauschverfahren geraten durch Quantencomputer unter Druck. OpenSSH hat darauf bereits reagiert und kombiniert klassische Verfahren mit post-quanten-sicheren KEMs. Wer heute einen <strong>SSH-Key erstellt<\/strong> und seinen Server korrekt konfiguriert, profitiert ohne Mehraufwand von diesem Schutz. Mehr dazu im Abschnitt zu OpenSSH 10 weiter unten und in unserem \u00dcberblick zur <a href=\"\/post-quantum-cryptography-2026\/\">Post-Quanten-Kryptografie<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"voraussetzungen-diese-versionen-brauchst-du\">Voraussetzungen: Diese Versionen brauchst du<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">SSH-Keys erzeugst du mit dem Werkzeug <code>ssh-keygen<\/code>, das Teil von OpenSSH ist. Auf praktisch jedem aktuellen Betriebssystem ist es vorinstalliert. Pr\u00fcfe vor dem Start kurz deine Version, denn neuere Funktionen wie FIDO2-Keys und der post-quanten-sichere Schl\u00fcsselaustausch brauchen eine hinreichend aktuelle OpenSSH-Version.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Komponente<\/th><th>Empfohlene Version (2026)<\/th><th>Pr\u00fcfbefehl<\/th><th>Hinweis<\/th><\/tr><\/thead><tbody><tr><td>OpenSSH<\/td><td>10.0 oder neuer<\/td><td><code>ssh -V<\/code><\/td><td>Aktuell verbreitete Version, bringt Hybrid-PQ-Austausch<\/td><\/tr><tr><td>Linux (Ubuntu\/Debian)<\/td><td>OpenSSH aus Paketquelle<\/td><td><code>apt list --installed | grep openssh<\/code><\/td><td>Standardm\u00e4\u00dfig installiert<\/td><\/tr><tr><td>macOS<\/td><td>integriertes OpenSSH<\/td><td><code>ssh -V<\/code><\/td><td>\u00dcber Homebrew aktualisierbar<\/td><\/tr><tr><td>Windows 11<\/td><td>OpenSSH Client (Feature)<\/td><td><code>ssh -V<\/code><\/td><td>Vorinstalliert seit Windows 10 1809<\/td><\/tr><tr><td>FIDO2-Stick<\/td><td>ed25519-sk-f\u00e4hig<\/td><td>Herstellerangabe<\/td><td>Nur f\u00fcr Hardware-Keys n\u00f6tig<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Pr\u00fcfe deine OpenSSH-Version mit einem einzigen Befehl. Die Ausgabe nennt dir Client-Version und die genutzte Krypto-Bibliothek.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ssh -V\nOpenSSH_10.0p1, OpenSSL 3.5.0 1 Apr 2026<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ist deine Version \u00e4lter als OpenSSH 8.2, fehlt dir die FIDO2-Unterst\u00fctzung. \u00c4lter als 9.0, fehlt der hybride post-quanten-sichere Schl\u00fcsselaustausch. F\u00fcr das reine Erstellen eines Ed25519-Schl\u00fcssels reicht jede Version ab OpenSSH 6.5 aus dem Jahr 2014, weil Ed25519 schon damals eingef\u00fchrt wurde. Aktualisiere unter Linux mit deinem Paketmanager, unter macOS per Homebrew (<code>brew upgrade openssh<\/code>) und unter Windows \u00fcber die optionalen Features oder winget.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lege au\u00dferdem fest, wo deine Schl\u00fcssel liegen sollen. Standard ist das Verzeichnis <code>~\/.ssh<\/code> in deinem Benutzerordner. Existiert es noch nicht, erstellt <code>ssh-keygen<\/code> es automatisch. Wer mehrere Identit\u00e4ten verwaltet, etwa privat und beruflich getrennt, sollte sich schon jetzt eine Namenskonvention f\u00fcr die Schl\u00fcsseldateien \u00fcberlegen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ed25519-vs-rsa-vs-ecdsa-welcher-schluesseltyp-2026\">Ed25519 vs. RSA vs. ECDSA: Welcher Schl\u00fcsseltyp 2026?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bevor du einen <strong>SSH-Key erstellst<\/strong>, entscheidest du dich f\u00fcr einen Schl\u00fcsseltyp. Es gibt drei relevante Optionen, und die Wahl ist 2026 einfacher als fr\u00fcher. Ed25519 ist f\u00fcr neue Schl\u00fcssel die erste Wahl. Die Kurve geh\u00f6rt zur Familie der <a href=\"\/cryptography\/\">elliptischen Kurven<\/a> und bietet starke Sicherheit bei sehr kleinen Schl\u00fcsseln und hoher Geschwindigkeit.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Schl\u00fcsseltyp<\/th><th>Empfohlene Gr\u00f6\u00dfe<\/th><th>Sicherheit 2026<\/th><th>Geschwindigkeit<\/th><th>Empfehlung<\/th><\/tr><\/thead><tbody><tr><td>Ed25519<\/td><td>fix (256-Bit-Kurve)<\/td><td>Sehr hoch<\/td><td>Sehr schnell<\/td><td>Standard f\u00fcr neue Keys<\/td><\/tr><tr><td>RSA<\/td><td>4096 Bit<\/td><td>Hoch<\/td><td>Langsamer<\/td><td>Nur f\u00fcr Altsysteme<\/td><\/tr><tr><td>ECDSA<\/td><td>521 Bit<\/td><td>Hoch<\/td><td>Schnell<\/td><td>Selten n\u00f6tig<\/td><\/tr><tr><td>RSA 2048<\/td><td>2048 Bit<\/td><td>Gerade noch ausreichend<\/td><td>Langsamer<\/td><td>Vermeiden<\/td><\/tr><tr><td>ed25519-sk<\/td><td>fix + Hardware<\/td><td>Sehr hoch, Phishing-Schutz<\/td><td>Schnell<\/td><td>H\u00f6chste Sicherheit<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wann-ed25519-wann-rsa\">Wann Ed25519, wann RSA?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nimm Ed25519, wenn nichts dagegen spricht, und das ist 2026 fast immer der Fall. Ed25519-Schl\u00fcssel sind kompakt, schnell und gelten als robust gegen die bekannten Implementierungsfehler, die ECDSA bei schlechter Zufallszahlenerzeugung plagen. Greife nur dann zu RSA mit 4096 Bit, wenn du ein altes Ger\u00e4t oder eine veraltete Appliance bedienen musst, die Ed25519 nicht versteht. Solche F\u00e4lle werden jedes Jahr seltener.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">ECDSA ist technisch in Ordnung, bietet gegen\u00fcber Ed25519 aber keinen Vorteil und hat eine heiklere Implementierungsgeschichte. Wenn du keinen zwingenden Grund f\u00fcr ECDSA hast, lass es weg. RSA mit nur 2048 Bit solltest du f\u00fcr neue Schl\u00fcssel meiden. Es ist nicht akut gebrochen, aber es gibt keinen Grund, am unteren Rand des Sicherheitsniveaus zu starten, wenn Ed25519 kostenlos mehr bietet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr maximale Sicherheit kombinierst du Ed25519 mit einem Hardware-Token, also einem <code>ed25519-sk<\/code>-Schl\u00fcssel. Dabei liegt der eigentliche private Schl\u00fcssel auf einem FIDO2-Stick und l\u00e4sst sich nicht exportieren. Selbst wenn jemand deinen Rechner kompromittiert, kann er sich ohne den physischen Stick nicht anmelden. Diesen Weg behandeln wir weiter unten ausf\u00fchrlich.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ssh-key-erstellen-unter-linux-und-macos-in-8-schritten\">SSH-Key erstellen unter Linux und macOS in 8 Schritten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Jetzt zum Kern: Wir <strong>erstellen einen SSH-Key<\/strong> Schritt f\u00fcr Schritt. Die folgenden acht Schritte gelten identisch f\u00fcr Linux und macOS, weil beide auf OpenSSH setzen. Windows folgt im n\u00e4chsten Abschnitt mit minimalen Abweichungen.<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li><strong>Terminal \u00f6ffnen.<\/strong> Unter Linux per Tastenk\u00fcrzel oder Anwendungsmen\u00fc, unter macOS \u00fcber Spotlight und Eingabe von &#8220;Terminal&#8221;.<\/li><li><strong>SSH-Verzeichnis pr\u00fcfen.<\/strong> Stelle sicher, dass <code>~\/.ssh<\/code> existiert. <code>ssh-keygen<\/code> legt es bei Bedarf selbst an.<\/li><li><strong>Schl\u00fcssel erzeugen.<\/strong> F\u00fchre den <code>ssh-keygen<\/code>-Befehl mit Ed25519 aus (siehe unten).<\/li><li><strong>Speicherort best\u00e4tigen.<\/strong> Dr\u00fccke Enter f\u00fcr den Standardpfad oder gib einen eigenen Dateinamen ein.<\/li><li><strong>Passphrase setzen.<\/strong> Vergib eine starke Passphrase. Lass dieses Feld nicht leer.<\/li><li><strong>Schl\u00fcssel pr\u00fcfen.<\/strong> Kontrolliere, dass die zwei Dateien angelegt wurden.<\/li><li><strong>In den ssh-agent laden.<\/strong> Damit musst du die Passphrase nur einmal pro Sitzung eingeben.<\/li><li><strong>\u00d6ffentlichen Schl\u00fcssel kopieren.<\/strong> Halte den Inhalt der <code>.pub<\/code>-Datei bereit f\u00fcr Server und Dienste.<\/li><\/ol>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"schritt-3-der-ssh-keygen-befehl-im-detail\">Schritt 3: Der ssh-keygen-Befehl im Detail<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Der zentrale Befehl ist kurz, aber jede Option hat einen Zweck. Wir nutzen Ed25519 und erh\u00f6hen die Zahl der KDF-Runden f\u00fcr die Verschl\u00fcsselung des privaten Schl\u00fcssels.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ssh-keygen -t ed25519 -a 64 -f ~\/.ssh\/id_ed25519 -C \"sam@beispiel.de\"<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\"><li><code>-t ed25519<\/code> w\u00e4hlt den Schl\u00fcsseltyp Ed25519.<\/li><li><code>-a 64<\/code> setzt 64 KDF-Runden. H\u00f6here Werte verlangsamen Offline-Angriffe auf die Passphrase deiner privaten Schl\u00fcsseldatei.<\/li><li><code>-f ~\/.ssh\/id_ed25519<\/code> legt den Dateinamen fest.<\/li><li><code>-C \"sam@beispiel.de\"<\/code> h\u00e4ngt einen Kommentar an, meist eine E-Mail oder ein Ger\u00e4tename, zur leichteren Zuordnung.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Nach dem Aufruf fragt <code>ssh-keygen<\/code> nach einer Passphrase. Vergib unbedingt eine. Eine leere Passphrase bedeutet, dass jeder, der deine private Schl\u00fcsseldatei kopiert, sofort vollen Zugriff hat. Die Passphrase verschl\u00fcsselt die Datei lokal und ist deine letzte Verteidigungslinie, falls dein Rechner kompromittiert oder das Backup gestohlen wird. So sieht ein vollst\u00e4ndiger Durchlauf aus:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Generating public\/private ed25519 key pair.\nEnter passphrase (empty for no passphrase): ********\nEnter same passphrase again: ********\nYour identification has been saved in \/home\/sam\/.ssh\/id_ed25519\nYour public key has been saved in \/home\/sam\/.ssh\/id_ed25519.pub\nThe key fingerprint is:\nSHA256:7n2Kx...gQ4 sam@beispiel.de\nThe key's randomart image is:\n+--[ED25519 256]--+\n|        .o+=O*o   |\n|       . o+.B.+   |\n|        . .* = .  |\n+----[SHA256]-----+<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"schritt-6-bis-7-dateien-pruefen-und-in-den-agent-laden\">Schritt 6 bis 7: Dateien pr\u00fcfen und in den Agent laden<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Es entstehen zwei Dateien: <code>id_ed25519<\/code> (privat, geheim halten) und <code>id_ed25519.pub<\/code> (\u00f6ffentlich, teilbar). Pr\u00fcfe sie und lade den privaten Schl\u00fcssel in den ssh-agent, damit du die Passphrase nur einmal pro Sitzung brauchst.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ls -l ~\/.ssh\/id_ed25519*\n-rw------- 1 sam sam  464 11. Jun 09:14 \/home\/sam\/.ssh\/id_ed25519\n-rw-r--r-- 1 sam sam  100 11. Jun 09:14 \/home\/sam\/.ssh\/id_ed25519.pub\n\n$ eval \"$(ssh-agent -s)\"\nAgent pid 4821\n$ ssh-add ~\/.ssh\/id_ed25519\nEnter passphrase for \/home\/sam\/.ssh\/id_ed25519: ********\nIdentity added: \/home\/sam\/.ssh\/id_ed25519 (sam@beispiel.de)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Achte auf die Berechtigungen: Der private Schl\u00fcssel zeigt <code>-rw-------<\/code> (600), der \u00f6ffentliche <code>-rw-r--r--<\/code> (644). Stimmen die Rechte des privaten Schl\u00fcssels nicht, verweigert OpenSSH sp\u00e4ter die Nutzung. Mehr dazu im Troubleshooting. Damit hast du erfolgreich einen <strong>SSH-Key erstellt<\/strong> und einsatzbereit gemacht.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ssh-key-erstellen-unter-windows-11\">SSH-Key erstellen unter Windows 11<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Unter Windows 11 ist der OpenSSH-Client seit Jahren vorinstalliert. Du kannst einen <strong>SSH-Key erstellen<\/strong>, ohne PuTTY oder Zusatzsoftware. \u00d6ffne PowerShell (kein Administrator n\u00f6tig) und nutze denselben <code>ssh-keygen<\/code>-Befehl wie unter Linux. Die Schl\u00fcssel landen in <code>C:\\Users\\DEINNAME\\.ssh<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>PS C:\\Users\\sam> ssh-keygen -t ed25519 -a 64 -C \"sam@beispiel.de\"\nGenerating public\/private ed25519 key pair.\nEnter file in which to save the key (C:\\Users\\sam\/.ssh\/id_ed25519):\nEnter passphrase (empty for no passphrase): ********\nYour identification has been saved in C:\\Users\\sam\/.ssh\/id_ed25519\nYour public key has been saved in C:\\Users\\sam\/.ssh\/id_ed25519.pub<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Den ssh-agent unter Windows startest du als Dienst. Standardm\u00e4\u00dfig ist er auf manuell gesetzt. Aktiviere ihn einmalig in einer PowerShell mit Administratorrechten und lade danach deinen Schl\u00fcssel wie gewohnt.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>PS C:\\> Get-Service ssh-agent | Set-Service -StartupType Automatic\nPS C:\\> Start-Service ssh-agent\nPS C:\\> ssh-add $env:USERPROFILE\\.ssh\\id_ed25519<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Den \u00f6ffentlichen Schl\u00fcssel kopierst du unter Windows am einfachsten in die Zwischenablage mit <code>Get-Content $env:USERPROFILE\\.ssh\\id_ed25519.pub | Set-Clipboard<\/code>. Danach f\u00fcgst du ihn in GitHub, GitLab oder die <code>authorized_keys<\/code> deines Servers ein. Wer lieber eine grafische Oberfl\u00e4che nutzt, kann weiterhin PuTTYgen verwenden, sollte aber darauf achten, den Schl\u00fcssel im OpenSSH-Format zu exportieren, damit er mit dem integrierten Client kompatibel ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein h\u00e4ufiger Stolperstein unter Windows betrifft die Dateirechte. Anders als unter Linux setzt Windows keine Unix-Berechtigungen. Meldet OpenSSH unter Windows trotzdem zu offene Rechte, musst du in den Sicherheitseinstellungen der Datei alle Benutzer au\u00dfer deinem eigenen Konto entfernen. Das passiert vor allem, wenn du Schl\u00fcssel von einem anderen Rechner kopiert hast.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"public-key-auf-den-server-bringen-ssh-copy-id-und-authorized_keys\">Public Key auf den Server bringen: ssh-copy-id und authorized_keys<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Schl\u00fcsselpaar allein bringt dich noch auf keinen Server. Du musst den \u00f6ffentlichen Schl\u00fcssel auf dem Zielsystem hinterlegen, und zwar in der Datei <code>~\/.ssh\/authorized_keys<\/code> des Zielbenutzers. Diese Datei ist die Allowlist: Der Server akzeptiert nur Schl\u00fcssel, die hier eingetragen sind. Der schnellste und sicherste Weg daf\u00fcr ist <code>ssh-copy-id<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ssh-copy-id -i ~\/.ssh\/id_ed25519.pub sam@server.beispiel.de\n\/usr\/bin\/ssh-copy-id: INFO: attempting to log in with the new key(s)\nsam@server.beispiel.de's password: ********\nNumber of key(s) added: 1\n\nNow try logging into the machine, with:   \"ssh sam@server.beispiel.de\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der Befehl meldet sich einmalig mit Passwort an (deshalb brauchst du daf\u00fcr noch Passwort-Zugang) und h\u00e4ngt deinen \u00f6ffentlichen Schl\u00fcssel an die <code>authorized_keys<\/code> an, ohne bestehende Eintr\u00e4ge zu \u00fcberschreiben. Danach kannst du dich per Schl\u00fcssel anmelden. Teste das sofort, bevor du im n\u00e4chsten Schritt den Passwort-Login deaktivierst.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Steht <code>ssh-copy-id<\/code> nicht zur Verf\u00fcgung, etwa unter Windows, f\u00fcgst du den Schl\u00fcssel manuell hinzu. Achte dabei penibel auf die Berechtigungen, sonst ignoriert der Server die Datei aus Sicherheitsgr\u00fcnden.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ssh sam@server.beispiel.de \"mkdir -p ~\/.ssh && chmod 700 ~\/.ssh\"\n$ cat ~\/.ssh\/id_ed25519.pub | ssh sam@server.beispiel.de \"cat >> ~\/.ssh\/authorized_keys && chmod 600 ~\/.ssh\/authorized_keys\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Verbinde dich anschlie\u00dfend testweise. Beim ersten Mal speichert dein Client den Host-Schl\u00fcssel des Servers in <code>~\/.ssh\/known_hosts<\/code> und fragt dich nach Best\u00e4tigung. Diese Pr\u00fcfung sch\u00fctzt vor einem Man-in-the-Middle: \u00c4ndert sich der Host-Schl\u00fcssel sp\u00e4ter unerwartet, warnt dich OpenSSH. Best\u00e4tige eine solche Warnung niemals blind, sondern kl\u00e4re erst, warum sich der Schl\u00fcssel ge\u00e4ndert hat.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ssh-key-bei-github-und-gitlab-hinterlegen\">SSH-Key bei GitHub und GitLab hinterlegen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die h\u00e4ufigste Nutzung von SSH-Keys au\u00dferhalb von Servern ist der Zugang zu Git-Plattformen. GitHub und GitLab nutzen SSH-Keys, damit du Code pushen und pullen kannst, ohne bei jedem Vorgang ein Token einzugeben. Wichtig: Du hinterlegst immer nur den \u00f6ffentlichen Schl\u00fcssel, also den Inhalt der <code>.pub<\/code>-Datei. Der private Schl\u00fcssel bleibt auf deinem Rechner.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Zeige zuerst den \u00f6ffentlichen Schl\u00fcssel an und kopiere die komplette Zeile, von <code>ssh-ed25519<\/code> bis zum Kommentar am Ende.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ cat ~\/.ssh\/id_ed25519.pub\nssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH8k...3vQ sam@beispiel.de<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\"><li>Bei GitHub: Settings, dann SSH and GPG keys, dann New SSH key. Titel vergeben, Schl\u00fcssel einf\u00fcgen, speichern.<\/li><li>Bei GitLab: Preferences, dann SSH Keys. Schl\u00fcssel einf\u00fcgen, optional ein Ablaufdatum setzen, hinzuf\u00fcgen.<\/li><li>Verbindung testen mit dem unten stehenden Befehl.<\/li><\/ol>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ssh -T git@github.com\nHi sam! You've successfully authenticated, but GitHub does not provide shell access.\n\n$ ssh -T git@gitlab.com\nWelcome to GitLab, @sam!<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Bekommst du stattdessen eine Abfrage nach einem Passwort oder eine Permission-denied-Meldung, stimmt etwas mit dem hinterlegten Schl\u00fcssel oder deiner lokalen Konfiguration nicht. Pr\u00fcfe, ob du wirklich den \u00f6ffentlichen und nicht versehentlich den privaten Schl\u00fcssel eingef\u00fcgt hast, und ob der ssh-agent den passenden Schl\u00fcssel geladen hat. Die Authentifizierung gegen\u00fcber GitHub funktioniert nach demselben Prinzip wie das Vertrauensmodell hinter <a href=\"\/https-tls-explained\/\">HTTPS und TLS<\/a>: Beide setzen auf kryptografische Identit\u00e4ten statt auf geteilte Geheimnisse.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ssh-agent-und-ssh-config-richtig-nutzen\">ssh-agent und ~\/.ssh\/config richtig nutzen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Sobald du mehrere Schl\u00fcssel und Server verwaltest, wird die Datei <code>~\/.ssh\/config<\/code> dein wichtigstes Werkzeug. Dort definierst du Host-Aliase, weist jedem Host den richtigen Schl\u00fcssel zu und vermeidest, dass dein Client wahllos alle Identit\u00e4ten durchprobiert. Letzteres kann dazu f\u00fchren, dass ein Server dich nach zu vielen Fehlversuchen sperrt.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># ~\/.ssh\/config\n\nHost github.com\n    HostName github.com\n    User git\n    IdentityFile ~\/.ssh\/id_ed25519\n    IdentitiesOnly yes\n\nHost produktion\n    HostName server.beispiel.de\n    User sam\n    Port 22\n    IdentityFile ~\/.ssh\/id_ed25519_prod\n    IdentitiesOnly yes\n    AddKeysToAgent yes<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Mit dieser Konfiguration verbindest du dich einfach per <code>ssh produktion<\/code>, statt jedes Mal Benutzername, Host und Port einzutippen. <code>IdentitiesOnly yes<\/code> sorgt daf\u00fcr, dass nur der angegebene Schl\u00fcssel verwendet wird. <code>AddKeysToAgent yes<\/code> l\u00e4dt den Schl\u00fcssel beim ersten Gebrauch automatisch in den Agent. Das spart Tipparbeit und reduziert Fehler.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"mehrere-schluessel-sauber-trennen\">Mehrere Schl\u00fcssel sauber trennen<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Viele Nutzer trennen private und berufliche Identit\u00e4ten. Erstelle daf\u00fcr einfach mehrere Schl\u00fcssel mit unterschiedlichen Dateinamen, etwa <code>id_ed25519_privat<\/code> und <code>id_ed25519_arbeit<\/code>, und ordne sie in der <code>config<\/code> verschiedenen Hosts zu. So pushst du mit dem richtigen Account, ohne nachzudenken. Pr\u00fcfe mit <code>ssh-add -l<\/code> jederzeit, welche Schl\u00fcssel aktuell im Agent geladen sind.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ssh-add -l\n256 SHA256:7n2Kx...gQ4 sam@beispiel.de (ED25519)\n256 SHA256:9p4Lz...rT2 sam-arbeit@firma.de (ED25519)<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"server-haerten-passwort-login-deaktivieren-in-sshd_config\">Server h\u00e4rten: Passwort-Login deaktivieren in sshd_config<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Der wahre Sicherheitsgewinn entsteht erst, wenn du den Passwort-Login komplett abschaltest. Solange Passw\u00f6rter erlaubt sind, bleibt dein Server ein Ziel f\u00fcr Brute-Force-Bots, egal wie gut dein Schl\u00fcssel ist. Bearbeite daf\u00fcr die Datei <code>\/etc\/ssh\/sshd_config<\/code> auf dem Server. Wichtig: Stelle vorher sicher, dass dein Schl\u00fcssel-Login funktioniert, sonst sperrst du dich aus.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/ssh\/sshd_config\n\nPasswordAuthentication no\nPubkeyAuthentication yes\nPermitRootLogin prohibit-password\nChallengeResponseAuthentication no\nUsePAM yes<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Nach der \u00c4nderung pr\u00fcfst du die Konfiguration auf Syntaxfehler und l\u00e4dst den Dienst neu. Der Test mit <code>sshd -t<\/code> ist Pflicht, denn ein Tippfehler kann verhindern, dass der SSH-Dienst \u00fcberhaupt startet.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ sudo sshd -t\n$ sudo systemctl reload ssh\n# Halte parallel eine bestehende Sitzung offen und teste in einem\n# zweiten Terminal eine neue Verbindung, bevor du die erste schliesst.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die goldene Regel beim H\u00e4rten lautet: Schlie\u00dfe niemals deine aktive Sitzung, bevor du in einem zweiten Terminal eine neue Verbindung erfolgreich getestet hast. Sperrst du dich bei einem Cloud-Server aus, hilft oft nur noch die Notfall-Konsole des Anbieters. Setze <code>PermitRootLogin prohibit-password<\/code> statt eines kompletten Verbots, wenn du Root-Zugang per Schl\u00fcssel f\u00fcr Automatisierung brauchst. Sonst ist <code>no<\/code> die sicherere Wahl.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Erg\u00e4nzend lohnt sich der Einsatz von fail2ban, das wiederholte Fehlversuche automatisch blockiert, sowie das Verschieben des SSH-Ports weg von 22. Letzteres bringt keine echte Sicherheit, reduziert aber das Grundrauschen automatisierter Scans im Log sp\u00fcrbar. Das Bundesamt f\u00fcr Sicherheit in der Informationstechnik gibt weitere Empfehlungen zur sicheren Serverkonfiguration heraus.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fido2-hardware-keys-ed25519-sk-fuer-phishing-schutz\">FIDO2-Hardware-Keys: ed25519-sk f\u00fcr Phishing-Schutz<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die sicherste Variante, einen <strong>SSH-Key zu erstellen<\/strong>, bindet den Schl\u00fcssel an einen physischen FIDO2-Stick. Bei einem <code>ed25519-sk<\/code>-Schl\u00fcssel (&#8220;sk&#8221; steht f\u00fcr security key) liegt das eigentliche Schl\u00fcsselgeheimnis im Hardware-Token und l\u00e4sst sich nicht exportieren. Auf der Festplatte landet nur ein Handle, das ohne den Stick wertlos ist. Selbst Malware mit vollem Zugriff auf deinen Rechner kann den Schl\u00fcssel nicht stehlen.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ssh-keygen -t ed25519-sk -O resident -O verify-required -C \"sam-yubikey\"\nGenerating public\/private ed25519-sk key pair.\nYou may need to touch your authenticator to authorize key generation.\nEnter PIN for authenticator: ****\nEnter passphrase (empty for no passphrase): ********<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Option <code>-O resident<\/code> speichert den Schl\u00fcssel auf dem Token selbst, sodass du ihn auf einem neuen Rechner mit <code>ssh-keygen -K<\/code> wieder herunterladen kannst. <code>-O verify-required<\/code> erzwingt eine PIN oder einen Fingerabdruck bei jeder Nutzung. Bei jedem Login musst du den Stick zus\u00e4tzlich ber\u00fchren. Genau diese physische Best\u00e4tigung macht Phishing praktisch unm\u00f6glich: Ein Angreifer aus der Ferne kann deinen Finger nicht ersetzen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der \u00f6ffentliche Schl\u00fcssel landet wie gewohnt in einer <code>.pub<\/code>-Datei und wird genauso in <code>authorized_keys<\/code>, GitHub oder GitLab hinterlegt. F\u00fcr Administratoren kritischer Systeme und f\u00fcr alle, die Wert auf h\u00f6chste Sicherheit legen, sind Hardware-Keys 2026 der Goldstandard. Wer das Konzept hardwaregebundener Geheimnisse aus dem Krypto-Bereich kennt, etwa von sicherem Schl\u00fcsselmaterial, findet sich hier schnell zurecht. Gute Geheimnisverwaltung beginnt ohnehin bei robustem <a href=\"\/argon2-password-hashing-nodejs\/\">Passwort-Hashing mit Argon2<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"post-quanten-ssh-hybrider-schluesselaustausch-in-openssh-10\">Post-Quanten-SSH: Hybrider Schl\u00fcsselaustausch in OpenSSH 10<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Aspekt, den viele Anleitungen \u00fcbergehen: der Schutz vor zuk\u00fcnftigen Quantencomputern. W\u00e4hrend dein Ed25519-Schl\u00fcssel die Authentifizierung \u00fcbernimmt, sichert ein separater Schl\u00fcsselaustausch die eigentliche Verbindung. Genau dieser Austausch ist durch Quantencomputer gef\u00e4hrdet, weil aufgezeichneter Datenverkehr sp\u00e4ter entschl\u00fcsselt werden k\u00f6nnte. Das nennt man &#8220;harvest now, decrypt later&#8221;.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">OpenSSH hat darauf reagiert und nutzt hybride Verfahren, die klassische Kryptografie mit einem post-quanten-sicheren KEM kombinieren. Aktuell sind das <code>sntrup761x25519-sha512<\/code> und das neuere <code>mlkem768x25519-sha256<\/code>, das auf dem von der NIST standardisierten ML-KEM basiert. Hybrid hei\u00dft: Selbst wenn eines der beiden Verfahren bricht, bleibt die Verbindung sicher.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># In \/etc\/ssh\/sshd_config oder ~\/.ssh\/config erzwingen:\nKexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512\n\n# Aktiven Algorithmus einer Verbindung pruefen:\n$ ssh -v sam@server.beispiel.de 2>&1 | grep \"kex:\"\ndebug1: kex: algorithm: mlkem768x25519-sha256<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Mit aktueller OpenSSH-Version auf beiden Seiten passiert das automatisch, ohne dass du etwas tun musst. Willst du sichergehen, erzwingst du die Algorithmen wie oben gezeigt. Wichtig zu verstehen: Dein Ed25519-Schl\u00fcssel zur Authentifizierung ist davon getrennt und muss nicht ausgetauscht werden. Den gr\u00f6\u00dferen Kontext zu diesem Wandel beschreiben wir im Artikel zur <a href=\"\/post-quantum-cryptography-2026\/\">Post-Quanten-Kryptografie<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"6-haeufige-fehler-beim-ssh-key-erstellen\">6 h\u00e4ufige Fehler beim SSH-Key erstellen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Diese sechs Fehler tauchen in der Praxis immer wieder auf. Wer sie kennt, spart sich stundenlange Fehlersuche.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Leere Passphrase.<\/strong> Ein unverschl\u00fcsselter privater Schl\u00fcssel ist eine offene T\u00fcr, sobald die Datei in falsche H\u00e4nde ger\u00e4t. Setze immer eine Passphrase und nutze den ssh-agent f\u00fcr den Komfort.<\/li><li><strong>Privaten Schl\u00fcssel hochladen.<\/strong> Niemals den privaten Schl\u00fcssel an einen Dienst oder Server schicken. Nur die <code>.pub<\/code>-Datei wird geteilt. Wer den privaten Schl\u00fcssel hochl\u00e4dt, muss das Paar sofort wegwerfen.<\/li><li><strong>Falsche Dateirechte.<\/strong> Ist der private Schl\u00fcssel f\u00fcr andere lesbar, verweigert OpenSSH die Nutzung. <code>chmod 600<\/code> f\u00fcr den Schl\u00fcssel, <code>chmod 700<\/code> f\u00fcr <code>~\/.ssh<\/code>.<\/li><li><strong>Passwort-Login zu fr\u00fch deaktivieren.<\/strong> Erst den Schl\u00fcssel-Login testen, dann Passw\u00f6rter abschalten. Sonst drohst du dich auszusperren.<\/li><li><strong>Host-Key-Warnungen ignorieren.<\/strong> Eine Warnung \u00fcber einen ge\u00e4nderten Host-Schl\u00fcssel kann auf einen Angriff hindeuten. Erst kl\u00e4ren, dann best\u00e4tigen.<\/li><li><strong>RSA 2048 oder veraltetes ECDSA w\u00e4hlen.<\/strong> F\u00fcr neue Schl\u00fcssel gibt es keinen Grund, unter Ed25519 zu bleiben.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Ein siebter, oft \u00fcbersehener Fehler: keine Backups des privaten Schl\u00fcssels. Verlierst du ihn, kommst du nicht mehr auf deine Server, bis du den neuen \u00f6ffentlichen Schl\u00fcssel \u00fcberall nachtr\u00e4gst. Lege ein verschl\u00fcsseltes Backup an, etwa in einem Passwortmanager oder auf einem getrennten, verschl\u00fcsselten Medium. Wie gute Passwort- und Geheimnisverwaltung aussieht, zeigt unser Leitfaden zur <a href=\"\/password-security\/\">Passwort-Sicherheit<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"troubleshooting-8-typische-ssh-probleme-loesen\">Troubleshooting: 8 typische SSH-Probleme l\u00f6sen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn die Verbindung nicht klappt, hilft fast immer der ausf\u00fchrliche Modus mit <code>ssh -v<\/code> (oder <code>-vvv<\/code> f\u00fcr maximale Details). Die folgende Tabelle fasst die acht h\u00e4ufigsten Probleme und ihre L\u00f6sungen zusammen.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Fehlermeldung \/ Symptom<\/th><th>Ursache<\/th><th>L\u00f6sung<\/th><\/tr><\/thead><tbody><tr><td>Permission denied (publickey)<\/td><td>Schl\u00fcssel nicht hinterlegt oder falscher Schl\u00fcssel<\/td><td><code>ssh-add -l<\/code> pr\u00fcfen, authorized_keys kontrollieren<\/td><\/tr><tr><td>WARNING: UNPROTECTED PRIVATE KEY FILE<\/td><td>Zu offene Dateirechte<\/td><td><code>chmod 600 ~\/.ssh\/id_ed25519<\/code><\/td><\/tr><tr><td>Agent admitted failure to sign<\/td><td>Schl\u00fcssel nicht im Agent<\/td><td><code>ssh-add ~\/.ssh\/id_ed25519<\/code><\/td><\/tr><tr><td>Host key verification failed<\/td><td>Host-Schl\u00fcssel ge\u00e4ndert<\/td><td>Ursache kl\u00e4ren, Eintrag in known_hosts bereinigen<\/td><\/tr><tr><td>Too many authentication failures<\/td><td>Client probiert zu viele Schl\u00fcssel<\/td><td><code>IdentitiesOnly yes<\/code> in der config setzen<\/td><\/tr><tr><td>Connection refused<\/td><td>SSH-Dienst aus oder falscher Port<\/td><td>Port und Dienststatus auf dem Server pr\u00fcfen<\/td><\/tr><tr><td>Passwortabfrage trotz Schl\u00fcssel<\/td><td>Schl\u00fcssel nicht akzeptiert<\/td><td><code>ssh -v<\/code> nutzen, Pfad und Rechte pr\u00fcfen<\/td><\/tr><tr><td>no mutual signature algorithm<\/td><td>Alter RSA-Schl\u00fcssel, Server lehnt SHA-1 ab<\/td><td>Neuen Ed25519-Schl\u00fcssel erstellen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Bei &#8220;Host key verification failed&#8221; entfernst du den veralteten Eintrag gezielt, statt die ganze Datei zu l\u00f6schen. Vergewissere dich aber zuerst, dass die \u00c4nderung legitim ist, etwa nach einer Neuinstallation des Servers.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>$ ssh-keygen -R server.beispiel.de\n# Host server.beispiel.de found: line 12\n\/home\/sam\/.ssh\/known_hosts updated.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Hilft das nicht weiter, schau in das Server-Log. Unter den meisten Linux-Distributionen findest du SSH-Meldungen mit <code>sudo journalctl -u ssh -n 50<\/code>. Dort steht oft im Klartext, warum eine Anmeldung abgelehnt wurde, etwa wegen falscher Berechtigungen auf <code>authorized_keys<\/code> oder einem deaktivierten Konto.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"profi-tipps-key-rotation-agent-forwarding-und-zertifikate\">Profi-Tipps: Key-Rotation, Agent-Forwarding und Zertifikate<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hast du die Grundlagen gemeistert, heben dich ein paar fortgeschrittene Praktiken auf das n\u00e4chste Niveau. Erstens die Schl\u00fcssel-Rotation: Tausche wichtige Schl\u00fcssel regelm\u00e4\u00dfig aus, etwa j\u00e4hrlich, und entferne alte \u00f6ffentliche Schl\u00fcssel aus allen <code>authorized_keys<\/code>. Setze bei GitLab ein Ablaufdatum, damit vergessene Schl\u00fcssel nicht ewig g\u00fcltig bleiben.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Zweitens Agent-Forwarding: Mit <code>ssh -A<\/code> oder <code>ForwardAgent yes<\/code> kannst du deinen lokalen Agent auf einem entfernten Server nutzen, um von dort zu einem dritten System zu springen, ohne den Schl\u00fcssel auf den Zwischenserver zu kopieren. Vorsicht: Wer Root auf dem Zwischenserver hat, kann deinen Agent missbrauchen, solange die Verbindung steht. Nutze Forwarding nur f\u00fcr vertrauensw\u00fcrdige Hosts und besser <code>ProxyJump<\/code> f\u00fcr die meisten F\u00e4lle.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Sicherer als Agent-Forwarding: ProxyJump ueber einen Bastion-Host\n$ ssh -J bastion.beispiel.de sam@intern.beispiel.de\n\n# Oder dauerhaft in ~\/.ssh\/config:\nHost intern\n    HostName intern.beispiel.de\n    User sam\n    ProxyJump bastion.beispiel.de<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Drittens SSH-Zertifikate: In gr\u00f6\u00dferen Umgebungen skaliert das Verteilen einzelner \u00f6ffentlicher Schl\u00fcssel schlecht. Mit einer eigenen Zertifizierungsstelle signierst du Schl\u00fcssel zentral. Server vertrauen dann der CA statt jedem Einzelschl\u00fcssel. Das vereinfacht das Onboarding und das Sperren ausgeschiedener Mitarbeiter erheblich. F\u00fcr Heim- und kleine Serverumgebungen ist das \u00fcberdimensioniert, in Unternehmen ab einer gewissen Gr\u00f6\u00dfe aber sehr empfehlenswert.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"komplettes-projekt-sicherer-ssh-zugang-von-null\">Komplettes Projekt: Sicherer SSH-Zugang von Null<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcgen wir alles zu einem durchgehenden, lauff\u00e4higen Projekt zusammen. Ziel: ein frischer Cloud-Server, auf den du dich ausschlie\u00dflich per Ed25519-Schl\u00fcssel anmeldest, ohne Passwort, ohne Root-Passwort-Login. Plane daf\u00fcr rund 30 Minuten ein. Die folgende Reihenfolge ist bewusst so gew\u00e4hlt, dass du dich nicht aussperren kannst.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># 1. Lokal einen Ed25519-Schluessel erstellen\nssh-keygen -t ed25519 -a 64 -f ~\/.ssh\/id_ed25519_prod -C \"prod-zugang\"\n\n# 2. In den Agent laden\nssh-add ~\/.ssh\/id_ed25519_prod\n\n# 3. Public Key auf den Server bringen\nssh-copy-id -i ~\/.ssh\/id_ed25519_prod.pub sam@server.beispiel.de\n\n# 4. Schluessel-Login testen (MUSS funktionieren)\nssh -i ~\/.ssh\/id_ed25519_prod sam@server.beispiel.de \"echo Login OK\"\n\n# 5. Config-Eintrag anlegen\ncat >> ~\/.ssh\/config &lt;&lt;'EOF'\nHost produktion\n    HostName server.beispiel.de\n    User sam\n    IdentityFile ~\/.ssh\/id_ed25519_prod\n    IdentitiesOnly yes\n    AddKeysToAgent yes\nEOF<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Jetzt h\u00e4rtest du den Server. Bleibe dabei in einer offenen SSH-Sitzung und teste jede \u00c4nderung in einem zweiten Terminal.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Auf dem Server, in einer bestehenden Sitzung:\n\n# 6. sshd_config absichern\nsudo sed -i 's\/^#\\?PasswordAuthentication.*\/PasswordAuthentication no\/' \/etc\/ssh\/sshd_config\nsudo sed -i 's\/^#\\?PermitRootLogin.*\/PermitRootLogin prohibit-password\/' \/etc\/ssh\/sshd_config\n\n# 7. Syntax pruefen und neu laden\nsudo sshd -t && sudo systemctl reload ssh\n\n# 8. In einem ZWEITEN Terminal neuen Login testen\nssh produktion \"echo Haertung erfolgreich\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">L\u00e4uft Schritt 8 durch, ist dein Server abgesichert: Passwort-Logins sind aus, nur dein Ed25519-Schl\u00fcssel \u00f6ffnet die T\u00fcr. Erst jetzt schlie\u00dft du die urspr\u00fcngliche Sitzung. Optional erg\u00e4nzt du fail2ban und erzwingst den post-quanten-sicheren Schl\u00fcsselaustausch, wie oben gezeigt. Damit hast du einen vollst\u00e4ndigen, sicheren SSH-Zugang von Grund auf aufgebaut und dabei jeden kritischen Schritt verifiziert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dieses Muster l\u00e4sst sich auf beliebig viele Server \u00fcbertragen. F\u00fcr die Automatisierung \u00fcber viele Maschinen hinweg greifst du sp\u00e4ter zu Werkzeugen wie Ansible, die genau diese Schritte als wiederholbares Skript ausf\u00fchren. Das Fundament aber, ein korrekt erzeugter und abgesicherter Schl\u00fcssel, bleibt immer dasselbe.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ssh-keys-fuer-dateiuebertragung-scp-rsync-und-sftp\">SSH-Keys f\u00fcr Datei\u00fcbertragung: scp, rsync und SFTP<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein <strong>SSH-Key<\/strong> dient nicht nur zum Anmelden, sondern sichert auch jede Datei\u00fcbertragung \u00fcber das SSH-Protokoll. Sobald dein Schl\u00fcssel-Login funktioniert, laufen <code>scp<\/code>, <code>rsync<\/code> und SFTP ohne Passwortabfrage. Das ist die Grundlage f\u00fcr automatisierte Backups und Deployments. Kopierst du eine Datei auf den Server, nutzt scp dieselbe Authentifizierung wie eine normale SSH-Sitzung.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Einzelne Datei hochladen\n$ scp .\/backup.tar.gz sam@server.beispiel.de:\/home\/sam\/\n\n# Verzeichnis effizient synchronisieren (nur Aenderungen)\n$ rsync -avz -e ssh .\/website\/ sam@server.beispiel.de:\/var\/www\/\n\n# Mit Host-Alias aus der config noch kuerzer\n$ rsync -avz .\/website\/ produktion:\/var\/www\/<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der Parameter <code>-avz<\/code> bei rsync steht f\u00fcr Archivmodus, ausf\u00fchrliche Ausgabe und Komprimierung. In Verbindung mit deinem Host-Alias aus der <code>~\/.ssh\/config<\/code> werden Befehle sehr kurz und lesbar. F\u00fcr wiederkehrende Backups packst du genau diese Zeilen in ein Skript und automatisierst sie per cron. Da kein Passwort n\u00f6tig ist, l\u00e4uft das vollst\u00e4ndig unbeaufsichtigt, vorausgesetzt, dein Schl\u00fcssel hat entweder keine Passphrase (nur f\u00fcr dedizierte Backup-Schl\u00fcssel ratsam) oder liegt in einem persistenten Agent.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auch Entwicklungswerkzeuge bauen auf SSH-Keys auf. Die Remote-Funktion g\u00e4ngiger Editoren wie VS Code verbindet sich per SSH und nutzt automatisch deine <code>~\/.ssh\/config<\/code>. Hast du dort einen Host sauber definiert, erscheint er direkt in der Editor-Oberfl\u00e4che. Ein einmal korrekt erstellter Schl\u00fcssel zahlt sich also in der gesamten Werkzeugkette aus, vom Terminal \u00fcber Git bis zur Remote-Entwicklung.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ssh-key-sichern-und-auf-neue-geraete-uebertragen\">SSH-Key sichern und auf neue Ger\u00e4te \u00fcbertragen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Irgendwann wechselst du den Rechner oder richtest ein zweites Ger\u00e4t ein. Dann stellt sich die Frage, wie der Schl\u00fcssel sicher mitwandert. Grunds\u00e4tzlich gilt: Der private Schl\u00fcssel darf niemals unverschl\u00fcsselt \u00fcber unsichere Kan\u00e4le wandern, also nicht per E-Mail, Chat oder Cloud-Ordner ohne zus\u00e4tzliche Verschl\u00fcsselung. Eine starke Passphrase auf der Schl\u00fcsseldatei ist hier deine wichtigste Absicherung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es gibt zwei saubere Wege. Der erste: Du erzeugst auf jedem Ger\u00e4t einen eigenen Schl\u00fcssel und hinterlegst alle \u00f6ffentlichen Schl\u00fcssel auf den Servern. Das ist die empfohlene Praxis, weil ein verlorenes Ger\u00e4t dann nur seinen eigenen Schl\u00fcssel mitnimmt, den du gezielt sperren kannst. Der zweite Weg \u00fcbertr\u00e4gt einen bestehenden Schl\u00fcssel auf ein verschl\u00fcsseltes Medium, etwa einen USB-Stick mit Festplattenverschl\u00fcsselung, oder \u00fcber einen sicheren Kanal wie scp.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Empfohlen: pro Geraet ein eigener Schluessel\n$ ssh-keygen -t ed25519 -a 64 -f ~\/.ssh\/id_ed25519_laptop -C \"laptop-2026\"\n\n# Den neuen Public Key zusaetzlich auf dem Server hinterlegen\n$ ssh-copy-id -i ~\/.ssh\/id_ed25519_laptop.pub produktion\n\n# Fingerprint eines Schluessels jederzeit pruefen\n$ ssh-keygen -lf ~\/.ssh\/id_ed25519_laptop.pub\n256 SHA256:Qa1Wb...xZ9 laptop-2026 (ED25519)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Verwaltest du Schl\u00fcssel auf einem FIDO2-Stick mit der Option <code>-O resident<\/code>, brauchst du gar keine \u00dcbertragung. Auf dem neuen Ger\u00e4t l\u00e4dst du die residenten Schl\u00fcssel einfach mit <code>ssh-keygen -K<\/code> vom Token herunter. Das ist einer der praktischsten Vorteile von Hardware-Keys: Der Stick ist dein tragbarer, nicht kopierbarer Schl\u00fcsselbund. Dokumentiere zus\u00e4tzlich, welcher Fingerprint zu welchem Ger\u00e4t geh\u00f6rt, damit du im Ernstfall genau den richtigen Schl\u00fcssel sperren kannst.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"haeufig-gestellte-fragen-zum-ssh-key-erstellen\">H\u00e4ufig gestellte Fragen zum SSH-Key erstellen<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wie-erstelle-ich-am-schnellsten-einen-ssh-key\">Wie erstelle ich am schnellsten einen SSH-Key?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">\u00d6ffne ein Terminal und f\u00fchre <code>ssh-keygen -t ed25519 -a 64 -C \"deine@mail.de\"<\/code> aus. Best\u00e4tige den Speicherort mit Enter und vergib eine starke Passphrase. In unter einer Minute hast du ein einsatzbereites Ed25519-Schl\u00fcsselpaar erstellt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ed25519-oder-rsa-was-ist-2026-besser\">Ed25519 oder RSA, was ist 2026 besser?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr neue Schl\u00fcssel ist Ed25519 die klare Empfehlung. Es ist schneller, kompakter und mindestens so sicher wie RSA 4096. RSA brauchst du nur noch, wenn ein altes System Ed25519 nicht unterst\u00fctzt. Dann nimm mindestens 4096 Bit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wo-wird-der-private-ssh-schluessel-gespeichert\">Wo wird der private SSH-Schl\u00fcssel gespeichert?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Standardm\u00e4\u00dfig im Verzeichnis <code>~\/.ssh<\/code> deines Benutzers, unter Windows in <code>C:\\Users\\DEINNAME\\.ssh<\/code>. Der private Schl\u00fcssel hei\u00dft <code>id_ed25519<\/code>, der \u00f6ffentliche <code>id_ed25519.pub<\/code>. Der private Schl\u00fcssel darf diesen Ort nie verlassen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"brauche-ich-fuer-jeden-server-einen-eigenen-schluessel\">Brauche ich f\u00fcr jeden Server einen eigenen Schl\u00fcssel?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nicht zwingend. Du kannst einen Schl\u00fcssel f\u00fcr mehrere Server nutzen. Aus Sicherheitsgr\u00fcnden empfiehlt sich aber eine Trennung nach Kontext, etwa je ein Schl\u00fcssel f\u00fcr privat, Arbeit und kritische Produktion. So begrenzt du den Schaden, falls ein Schl\u00fcssel kompromittiert wird.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"was-passiert-wenn-ich-meinen-privaten-schluessel-verliere\">Was passiert, wenn ich meinen privaten Schl\u00fcssel verliere?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ohne den privaten Schl\u00fcssel kommst du nicht mehr auf die zugeh\u00f6rigen Server. Du musst \u00fcber einen alternativen Zugang einen neuen Schl\u00fcssel erstellen und dessen \u00f6ffentlichen Teil \u00fcberall nachtragen. Entferne den verlorenen \u00f6ffentlichen Schl\u00fcssel sofort aus allen <code>authorized_keys<\/code>. Deshalb sind verschl\u00fcsselte Backups wichtig.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ist-ein-ssh-key-sicher-gegen-quantencomputer\">Ist ein SSH-Key sicher gegen Quantencomputer?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Die Authentifizierung per Ed25519 gilt vorerst als robust. Der Schl\u00fcsselaustausch der Verbindung wird in aktuellem OpenSSH zus\u00e4tzlich durch hybride post-quanten-sichere Verfahren wie <code>mlkem768x25519-sha256<\/code> gesch\u00fctzt. Wer aktuelle Versionen nutzt, ist gegen &#8220;harvest now, decrypt later&#8221; gewappnet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"muss-ich-eine-passphrase-setzen\">Muss ich eine Passphrase setzen?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, unbedingt. Eine Passphrase verschl\u00fcsselt deinen privaten Schl\u00fcssel auf der Festplatte. Ohne sie hat jeder, der die Datei kopiert, sofort vollen Zugriff. Mit dem ssh-agent musst du die Passphrase nur einmal pro Sitzung eingeben, der Komfort leidet also kaum.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"verwandte-artikel\">Verwandte Artikel<\/h3>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"\/digital-signatures\/\">Digitale Signaturen erkl\u00e4rt: Wie sie funktionieren<\/a><\/li><li><a href=\"\/https-tls-explained\/\">HTTPS und TLS erkl\u00e4rt: Was das Schloss wirklich bedeutet<\/a><\/li><li><a href=\"\/post-quantum-cryptography-2026\/\">Post-Quanten-Kryptografie: 50 % des Webs jetzt sicher<\/a><\/li><li><a href=\"\/argon2-password-hashing-nodejs\/\">Argon2 Passwort-Hashing in Node.js: 11 Schritte<\/a><\/li><li><a href=\"\/password-security\/\">Passwort-Sicherheit: Was Konten wirklich sch\u00fctzt<\/a><\/li><li><a href=\"\/cryptography\/\">Hashing und Kryptografie verst\u00e4ndlich erkl\u00e4rt<\/a><\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Weiterf\u00fchrende offizielle Quellen: das <a href=\"https:\/\/www.openssh.com\/\" target=\"_blank\" rel=\"noopener\">OpenSSH-Projekt<\/a>, die <a href=\"https:\/\/www.man7.org\/linux\/man-pages\/man1\/ssh-keygen.1.html\" target=\"_blank\" rel=\"noopener\">ssh-keygen-Handbuchseite<\/a>, die <a href=\"https:\/\/docs.github.com\/en\/authentication\/connecting-to-github-with-ssh\/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent\" target=\"_blank\" rel=\"noopener\">GitHub-Dokumentation zu SSH-Keys<\/a>, die <a href=\"https:\/\/docs.gitlab.com\/ee\/user\/ssh.html\" target=\"_blank\" rel=\"noopener\">GitLab-SSH-Dokumentation<\/a> sowie <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8709\" target=\"_blank\" rel=\"noopener\">RFC 8709<\/a> zur Ed25519-Nutzung in SSH.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>Ein gestohlenes Passwort ist 2026 die h\u00e4ufigste Eintrittst\u00fcr in fremde Server. SSH-Keys schlie\u00dfen diese T\u00fcr: Statt einer Zeichenkette, die man erraten, abfangen oder per Phishing abgreifen kann, authentifizierst du dich\u2026<\/p>\n","protected":false},"author":4,"featured_media":59,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-58","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cryptography"],"_links":{"self":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts\/58","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/comments?post=58"}],"version-history":[{"count":0,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/posts\/58\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/media\/59"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/media?parent=58"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/categories?post=58"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/de\/wp-json\/wp\/v2\/tags?post=58"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}