Es war ein Dienstagnachmittag, als mich ein panischer Anruf eines befreundeten Systemadministrators erreichte. Er hatte den gesamten Vormittag damit verbracht, für sein Team neue Zugänge zu einem kritischen Cloud-Cluster einzurichten. Sein Fehler war klassisch: Er verließ sich auf eine veraltete Anleitung für Generating SSH Key In Windows, die er irgendwo in einem Forenbeitrag von 2015 gefunden hatte. Er nutzte PuttyGen, speicherte den privaten Schlüssel im .ppk-Format und versuchte, ihn direkt in eine moderne OpenSSH-Umgebung zu drücken. Das Ergebnis? Drei gesperrte Benutzerkonten, eine falsch konfigurierte authorized_keys-Datei und vier Stunden Ausfallzeit, weil die automatisierten Deployments den Dienst verweigerten. Solche Patzer kosten in der echten Welt bares Geld, weil Entwickler untätig herumsitzen, während die IT-Abteilung verzweifelt versucht, Dateiberechtigungen unter Windows-Dateisystemen zu biegen, die SSH-Schlüssel eigentlich gar nicht mögen.
Das Märchen vom universellen PuTTY-Standard
Viele Leute denken immer noch, dass PuTTY das Maß aller Dinge ist, wenn es um Windows geht. Das ist Unsinn. Ich habe Projekte gesehen, bei denen Firmen Tausende von Euro in externe Berater gesteckt haben, nur weil sie ihre gesamte Infrastruktur auf dem proprietären .ppk-Format von PuTTY aufgebaut hatten. Sobald dann jemand mit einem Mac oder einem Linux-Laptop ins Team kam, fing das Chaos an.
PuTTY ist ein Relikt aus einer Zeit, in der Windows kein eingebautes SSH besaß. Wenn Sie heute anfangen, einen Schlüssel zu erstellen, benutzen Sie das Terminal. Punkt. Der größte Fehler ist die Annahme, dass man für diesen Vorgang eine grafische Benutzeroberfläche braucht. Grafische Tools verstecken oft, was im Hintergrund passiert. Sie wissen am Ende nicht, wo Ihr privater Schlüssel liegt oder welche Verschlüsselungsstärke gewählt wurde. Wer heute noch blind auf "Generate" in einem alten GUI-Tool klickt, ohne die Parameter zu kennen, spielt russisches Roulette mit der Sicherheit seiner Server.
In der Praxis bedeutet das: Wenn Sie einen Schlüssel im falschen Format generieren, wird der Zielserver die Verbindung einfach ablehnen. Sie suchen dann stundenlang nach Fehlern in der Firewall oder beim Provider, dabei liegt das Problem schlicht an einem Header in einer Textdatei, den OpenSSH nicht lesen kann.
Die Wahl des Algorithmus entscheidet über Ihre Sicherheit
Ein weiterer kritischer Punkt beim Generating SSH Key In Windows ist die Wahl des Algorithmus. Standardmäßig schlagen viele alte Tutorials RSA vor. Das ist zwar nicht grundsätzlich falsch, aber oft wird eine zu geringe Bit-Länge verwendet. 1024-Bit RSA-Schlüssel sind seit Jahren unsicher. Selbst 2048 Bit gelten heute als das absolute Minimum und werden von sicherheitsbewussten Organisationen wie dem BSI kritisch beäugt.
Ich sehe immer wieder, dass Entwickler einfach ssh-keygen tippen und alle Standardwerte mit Enter bestätigen. Das erzeugt oft einen RSA-Schlüssel mit Standardlänge. Das ist bequem, aber kurzsichtig. Ein moderner Angreifer lacht über schwache Schlüssel. Wenn Sie heute Infrastruktur aufbauen, die die nächsten fünf Jahre halten soll, müssen Sie Ed25519 verwenden.
Ed25519-Schlüssel sind kürzer, schneller und bieten eine höhere Sicherheit bei geringerer Rechenlast. Es gibt keinen vernünftigen Grund, bei einer Neuinstallation auf Windows 10 oder 11 noch mit sperrigen RSA-Monstern zu arbeiten, es sei denn, Sie müssen sich mit einem uralten Legacy-System verbinden, das seit zehn Jahren kein Update gesehen hat. Wer hier am falschen Ende spart, zahlt später drauf, wenn die gesamte Key-Infrastruktur wegen einer neuen Sicherheitsrichtlinie hastig ausgetauscht werden muss.
Der richtige Pfad für Generating SSH Key In Windows
Wo landen Ihre Schlüssel eigentlich? In meiner Laufbahn habe ich die abenteuerlichsten Orte gesehen. Leute speichern ihre privaten Schlüssel auf dem Desktop, in ihrem Download-Ordner oder – mein absoluter Favorit im negativen Sinne – in einer unverschlüsselten Dropbox-Cloud. Das ist grob fahrlässig.
Windows hat einen festen Platz für diese Dinge: %USERPROFILE%\.ssh. Wenn Sie beim Generating SSH Key In Windows den Pfad manuell ändern, weil Sie denken, "im Projektordner ist es übersichtlicher", haben Sie schon verloren. SSH-Clients unter Windows, egal ob Git Bash, PowerShell oder das Windows-Terminal, suchen standardmäßig in diesem einen Unterordner.
Das Berechtigungs-Dilemma unter NTFS
Hier scheitern die meisten. SSH ist extrem pingelig, was die Dateiberechtigungen angeht. Wenn Ihr privater Schlüssel für jeden Nutzer auf dem Computer lesbar ist, wird der SSH-Client den Dienst verweigern. Er gibt eine Fehlermeldung aus, dass der Schlüssel "too open" ist. Unter Linux ist das ein einfacher chmod 600 Befehl. Unter Windows müssen Sie sich mit NTFS-Berechtigungen, Vererbung und Benutzergruppen herumschlagen.
Ein falscher Klick in den Sicherheitseigenschaften der Datei und Ihr Schlüssel ist wertlos, weil der Client ihn aus Sicherheitsgründen ignoriert. Ich habe Techniker gesehen, die entnervt aufgegeben haben und stattdessen Passwörter benutzten, was die Sicherheit des gesamten Unternehmens untergrub. Die Lösung ist, die Vererbung in den Dateieigenschaften zu deaktivieren und nur dem eigenen Benutzer Vollzugriff zu gewähren. Alles andere muss raus.
Warum die Passphrase kein optionales Extra ist
"Ich brauche keine Passphrase, mein Computer ist doch passwortgeschützt." Das ist der gefährlichste Satz, den ich je von einem Junior-Dev gehört habe. Ein SSH-Schlüssel ohne Passphrase ist wie ein Hausschlüssel, den man direkt unter die Fußmatte legt. Wenn jemand Zugriff auf Ihr Dateisystem erhält – sei es durch Malware, einen ungesperrten Laptop im Café oder ein Backup, das in falsche Hände gerät – hat er sofortigen Zugriff auf alle Ihre Server.
In der täglichen Arbeit nervt die Passphrase natürlich. Jedes Mal, wenn man einen git push macht, soll man das Passwort eingeben? Das macht niemand lange mit. Aber die Lösung ist nicht der Verzicht auf das Passwort, sondern die Nutzung des SSH-Agenten. Der Agent läuft im Hintergrund, Sie geben das Passwort einmal pro Sitzung ein, und er hält den entsperrten Schlüssel im Speicher bereit.
Wer ohne Passphrase arbeitet, handelt unprofessionell. Es gibt keine Entschuldigung dafür. Wenn ich bei einem Audit sehe, dass Schlüssel ohne Schutz auf Festplatten liegen, ist das ein sofortiger Rapport beim Sicherheitsbeauftragten. Es dauert genau zehn Sekunden länger, eine Passphrase zu setzen, aber es schützt Sie vor einem kompletten Identitätsdiebstahl im Netzwerk.
Vorher und Nachher: Ein Praxisbeispiel aus der Systemadministration
Schauen wir uns an, wie dieser Prozess in der Realität schiefgeht und wie er richtig aussieht.
Das falsche Szenario (Der langsame Weg zum Disaster):
Ein Administrator möchte Zugriff auf einen neuen Webserver. Er öffnet eine alte Version von PuTTYgen. Er bewegt die Maus im Fenster, um Zufallsdaten zu generieren. Er speichert den Private Key als my_key.ppk auf seinem Desktop. Den Public Key kopiert er aus dem Textfeld des Programms und fügt ihn in die authorized_keys auf dem Server ein.
Zwei Wochen später muss er ein Skript schreiben, das Dateien via SCP überträgt. Das Skript schlägt fehl, weil das SCP-Tool auf der Kommandozeile mit dem .ppk-Format nichts anfangen kann. Er versucht, den Schlüssel umzuwandeln, verliert dabei die Passphrase oder erstellt einen Schlüssel ohne Header. Er verbringt drei Stunden damit, Foren zu wälzen, warum seine Verbindung mit "Permission denied (publickey)" abgelehnt wird. Am Ende gibt er auf und aktiviert den Passwort-Login am Server – ein riesiges Sicherheitsrisiko.
Das richtige Szenario (Der Profi-Weg): Der Administrator öffnet die PowerShell. Er tippt einen einzigen Befehl ein, der einen Ed25519-Schlüssel direkt im korrekten Verzeichnis erstellt. Er vergibt eine starke Passphrase. Dann nutzt er einen einfachen Befehl, um den öffentlichen Teil auf den Server zu schieben. Der gesamte Vorgang dauert zwei Minuten. Da der Schlüssel im Standardformat OpenSSH vorliegt, funktioniert er sofort mit Git, VS Code, dem Windows-Terminal und sogar in automatisierten CI/CD-Pipelines. Er muss nie wieder über Formate nachdenken. Sein System ist sauber, standardisiert und hochsicher.
Der Unterschied ist gewaltig. Im ersten Fall wurde wertvolle Arbeitszeit für das Lösen von Problemen verschwendet, die durch die Wahl des falschen Werkzeugs erst entstanden sind. Im zweiten Fall wurde ein Standard etabliert, der jahrelang ohne Wartung funktioniert.
Warum "ssh-copy-id" unter Windows fehlt und was Sie stattdessen tun
Ein echtes Ärgernis für alle, die von Linux kommen, ist das Fehlen des Befehls ssh-copy-id. Unter Linux ist das der Standardweg, um den öffentlichen Schlüssel auf einen Server zu bringen. Windows-Nutzer stehen oft ratlos da und versuchen, den Text manuell per Copy-and-Paste in Vim oder Nano auf dem Server einzufügen. Dabei passieren oft Fehler: Zeilenumbrüche werden falsch kopiert, Leerzeichen schleichen sich ein oder der Schlüssel wird versehentlich abgeschnitten.
Ein einziger falscher Buchstabe im öffentlichen Schlüssel sorgt dafür, dass die Anmeldung fehlschlägt. Wenn Sie dann den Passwort-Login am Server bereits deaktiviert haben, haben Sie sich effektiv ausgesperrt. Ich habe erlebt, wie ein Kollege ein Rechenzentrum anrufen musste, um über die serielle Konsole wieder Zugriff zu erhalten, nur weil beim Kopieren des Schlüssels ein "n" am Ende fehlte.
Man kann sich unter Windows mit einem kleinen PowerShell-Einzeiler behelfen, der genau das tut, was ssh-copy-id macht. Er liest den Inhalt der .pub-Datei und hängt ihn per SSH-Befehl an die ~/.ssh/authorized_keys auf der Gegenseite an. Das ist sicher, schnell und verhindert Formatierungsfehler. Wer das manuell macht, geht ein unnötiges Risiko ein.
Die unterschätzte Gefahr: SSH-Keys in der Cloud-Konsole
Viele Cloud-Anbieter wie AWS, Azure oder Hetzner bieten an, SSH-Schlüssel direkt bei der Erstellung einer Instanz zu hinterlegen. Das ist bequem, führt aber oft zu schlechten Angewohnheiten. Oft generiert das Web-Interface des Anbieters einen Schlüssel für Sie und lässt Sie den privaten Teil herunterladen.
Tun Sie das nicht.
Erzeugen Sie Ihre Schlüssel immer lokal auf Ihrer eigenen Maschine. Sie sollten niemals einen privaten Schlüssel besitzen, der über ein Netzwerk zu Ihnen übertragen wurde oder der auf dem Server eines Drittanbieters generiert wurde. Das widerspricht dem Grundprinzip der Public-Key-Kryptographie. Der private Schlüssel heißt "privat", weil er Ihre Maschine niemals verlassen darf.
Wenn Sie einen Schlüssel von einer Webseite herunterladen, wissen Sie nicht, ob dieser dort zwischengespeichert wurde. In meiner Praxis ist es eine eiserne Regel: Wir laden nur den Public Key hoch. Der Private Key wird lokal generiert und bleibt dort. Wer das ignoriert, schafft eine zentrale Schwachstelle. Wenn der Cloud-Anbieter kompromittiert wird, sind es Ihre Zugänge auch.
Realitätscheck
Kommen wir zum Punkt. SSH-Schlüssel unter Windows zu verwalten, ist kein Hexenwerk, aber es verzeiht keine Schlamperei. Die Technik hat sich in den letzten Jahren massiv verbessert, und Windows ist endlich ein erstklassiger Bürger in der SSH-Welt geworden. Aber das nützt Ihnen nichts, wenn Sie noch in den Denkmustern von 2010 feststecken.
Es braucht keine teure Software und keine komplizierten GUIs. Es braucht Disziplin. Sie müssen verstehen, wo Ihre Dateien liegen, wie die Berechtigungen funktionieren und warum ein moderner Algorithmus wie Ed25519 keine Verhandlungssache ist. Wer glaubt, er könne Sicherheit "nebenbei" machen, ohne sich mit diesen Grundlagen zu beschäftigen, wird früher oder später vor einem gesperrten Server oder – schlimmer noch – einer gehackten Infrastruktur stehen.
Es gibt keine Abkürzung. Wenn Sie zu faul für eine Passphrase sind oder zu bequem, um die Kommandozeile zu lernen, dann ist die Administration von Servern vielleicht nicht das richtige Feld für Sie. Erfolg in diesem Bereich kommt durch Standardisierung und das Vermeiden von unnötiger Komplexität. Nutzen Sie die eingebauten Tools, halten Sie sich an die Pfade und schützen Sie Ihre Identität mit allem, was Sie haben. Das ist die einzige Wahrheit, die in der Praxis zählt. Alles andere ist Theorie, die Sie beim ersten echten Notfall im Stich lässt.
