Ich saß vor zwei Jahren in einem stickigen Serverraum eines mittelständischen Logistikunternehmens in Hamburg, während der CTO blass neben mir stand. Ein Angreifer hatte über Nacht drei ihrer Hauptserver verschlüsselt. Der Grund war lächerlich banal: Ein Junior-Entwickler hatte gegoogelt, How To Generate SSH Key, und das erstbeste Tutorial befolgt, das ihm ein veraltetes RSA-Verfahren mit einer Schlüssellänge von 1024 Bit empfahl. Der Schlüssel war innerhalb weniger Stunden per Brute-Force geknackt worden, weil er schlicht nicht mehr dem Stand der Technik entsprach. Dieser kleine Fehler kostete das Unternehmen am Ende knapp 45.000 Euro für Datenwiederherstellung und Systembereinigung. In meiner Laufbahn habe ich das oft erlebt: Leute denken, ein Schlüssel ist ein Schlüssel, aber die Realität in der Kryptografie verzeiht keine Nachlässigkeit. Wer heute noch blindlings Befehle kopiert, ohne zu verstehen, welchen Algorithmus er da eigentlich in seine Infrastruktur lässt, spielt russisches Roulette mit seinen Daten.
Der Fehler der Bequemlichkeit beim How To Generate SSH Key
Der häufigste Fehler, den ich sehe, ist das blinde Vertrauen in Standardeinstellungen. Viele Nutzer geben einfach ssh-keygen in ihr Terminal ein und drücken so lange die Enter-Taste, bis sie fertig sind. Das Problem dabei ist, dass ältere Betriebssysteme oder schlecht konfigurierte Umgebungen standardmäßig auf RSA setzen. RSA ist zwar ein Klassiker, aber er ist im Vergleich zu modernen Alternativen wie Ed25519 massiv unterlegen, was sowohl die Sicherheit als auch die Geschwindigkeit angeht.
Wenn Sie den Prozess starten, müssen Sie explizit angeben, was Sie wollen. Ich habe Entwickler gesehen, die dachten, sie seien sicher, weil sie ein langes Passwort für ihren privaten Schlüssel vergeben haben. Das bringt Ihnen aber gar nichts, wenn die mathematische Grundlage des Schlüssels selbst durch moderne Rechenpower angreifbar ist. Ein Ed25519-Schlüssel ist kürzer, schneller beim Verbindungsaufbau und bietet bei weitem mehr Schutz gegen aktuelle Angriffsvektoren. Wer heute noch RSA nutzt, muss mindestens 4096 Bit wählen, um halbwegs ruhig schlafen zu können, aber selbst das ist nur eine Übergangslösung.
Warum Ed25519 die einzige vernünftige Wahl ist
Ed25519 basiert auf elliptischen Kurven. Im Gegensatz zu RSA, das auf der Schwierigkeit der Faktorisierung großer Primzahlen beruht, bietet dieser Algorithmus ein höheres Sicherheitsniveau bei deutlich kürzeren Schlüssellängen. Das bedeutet weniger Last für Ihren Prozessor bei jedem Login und eine kleinere Angriffsfläche. Ich rate jedem in der Praxis: Wenn Ihr System Ed25519 nicht unterstützt, ist nicht der Schlüssel das Problem, sondern Ihr veraltetes System, das Sie dringend aktualisieren müssen.
Das Märchen vom passwortlosen Schlüssel
Es gibt diesen gefährlichen Ratschlag in vielen Foren: "Lass die Passphrase einfach leer, dann geht der Login schneller." Das ist der sicherheitstechnische Gegenpart zum Verstecken des Hausschlüssels unter der Fußmatte. Wenn Ihr Laptop gestohlen wird oder sich jemand unbefugt Zugriff auf Ihr lokales Benutzerkonto verschafft, hat er sofortigen Zugriff auf alle Ihre Server. Ich habe erlebt, wie eine gesamte Cloud-Infrastruktur gelöscht wurde, weil ein entlassener Mitarbeiter noch die ungeschützten Schlüssel auf seinem privaten Rechner hatte.
Die Passphrase ist Ihre zweite Verteidigungslinie. Sie verschlüsselt den privaten Schlüssel auf Ihrer Festplatte. Ohne diese zusätzliche Hürde ist Ihr SSH-Key nichts weiter als eine Textdatei, die jeder kopieren und missbrauchen kann. Nutzen Sie einen SSH-Agenten, um die Passphrase während Ihrer Sitzung zu speichern, damit Sie sie nicht jedes Mal neu eintippen müssen. Das ist der goldene Mittelweg zwischen Sicherheit und Komfort, den Profis gehen. Alles andere ist pure Faulheit, die früher oder später bestraft wird.
Vernachlässigung der Dateiberechtigungen auf dem Server
Sie haben einen starken Schlüssel erstellt und ihn auf den Server übertragen. Jetzt denken Sie, alles ist sicher. Falsch gedacht. Ein Fehler, der oft zu "Permission Denied" Fehlern führt oder – noch schlimmer – den Zugriff für Dritte öffnet, sind falsch gesetzte Rechte im Verzeichnis .ssh. Der Server ist extrem penibel, was das angeht. Wenn die Datei authorized_keys für andere Benutzer lesbar ist, verweigert der SSH-Dienst oft aus Sicherheitsgründen den Dienst, oder er ignoriert die Datei schlichtweg.
In der Praxis bedeutet das: Ihr Verzeichnis braucht die Rechte 700 und die Datei mit den öffentlichen Schlüsseln die Rechte 600. Ich habe Stunden damit verbracht, Fehler bei Kunden zu suchen, die einfach nur chmod 777 auf alles angewendet hatten, weil sie dachten, das würde Verbindungsprobleme lösen. Damit machen Sie die Haustür nicht nur auf, Sie hängen sie gleich ganz aus den Angeln. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seinen Leitfäden zur Serverhärtung explizit die strikte Trennung und minimale Rechtevergabe für Identitätsdateien. Das ist kein optionaler Schritt, das ist das Fundament.
Die Verwechslung von Public und Private Key
Es klingt banal, aber ich habe es erlebt: Ein Administrator postete seinen privaten Schlüssel in ein öffentliches GitHub-Repository, weil er dachte, das sei der Teil, den man "teilen" muss. Der Schaden war immens. Der öffentliche Schlüssel (meist mit der Endung .pub) ist derjenige, den Sie auf den Server laden. Der private Schlüssel bleibt bei Ihnen und verlässt niemals, absolut niemals, Ihren Rechner.
Stellen Sie sich das wie ein Schloss und einen Schlüssel vor. Das Schloss (Public Key) können Sie an jede Tür hängen. Der Schlüssel (Private Key) in Ihrer Tasche öffnet all diese Schlösser. Wenn Sie Ihren Schlüssel kopieren und verteilen, brauchen Sie sich nicht zu wundern, wenn Fremde in Ihrem Wohnzimmer stehen. Es gibt Tools wie ssh-copy-id, die diesen Prozess automatisieren und sicherstellen, dass nur der öffentliche Teil übertragen wird. Wer manuell mit Copy-and-Paste arbeitet, riskiert nicht nur Formatierungsfehler, die den Schlüssel unbrauchbar machen, sondern eben auch diese fatale Verwechslung.
Ein Vorher-Nachher-Vergleich aus der echten Welt
Schauen wir uns an, wie ein typischer Amateur-Ansatz im Vergleich zu einer professionellen Umsetzung aussieht.
Vorher (Der Amateur-Weg):
Ein Nutzer erstellt einen RSA-Schlüssel ohne Passphrase. Er kopiert den Inhalt der Datei manuell per SSH-Sitzung in eine Datei auf dem Server, die er mit nano öffnet. Dabei entstehen Zeilenumbrüche, wo keine sein sollten. Der Server verweigert den Dienst. Frustriert setzt der Nutzer die Dateiberechtigungen auf dem Server auf 777, damit es "endlich funktioniert". Der Login klappt nun zwar, aber jeder andere Nutzer auf diesem Shared-Hosting-Server kann nun den öffentlichen Schlüssel manipulieren oder die Logs mitlesen. Monate später wundert sich der Nutzer über seltsame Prozesse auf seinem Server. Ein Angreifer hat die schwache Konfiguration ausgenutzt und den Server in ein Botnetz eingegliedert.
Nachher (Der Profi-Weg):
Der Profi weiß genau, How To Generate SSH Key funktioniert nur dann sicher, wenn man den Typ Ed25519 wählt und einen Kommentar mit seiner E-Mail-Adresse für die Zuordnung hinzufügt. Er vergibt eine starke Passphrase, die er in seinem Passwortmanager speichert. Zur Übertragung nutzt er ssh-copy-id, was automatisch die richtigen Berechtigungen auf dem Zielserver setzt. Auf dem Server deaktiviert er zusätzlich den Passwort-Login in der sshd_config und erlaubt nur noch den Zugriff via Public-Key. Das Ergebnis: Die Verbindung ist innerhalb von Millisekunden aufgebaut, und selbst wenn ein Angreifer das Passwort des Benutzers errät, kommt er ohne den physischen Besitz des verschlüsselten privaten Schlüssels nicht ins System. Das System ist gegen 99 % der automatisierten Angriffe immun.
Die Gefahr veralteter Protokolle in der SSH-Konfiguration
Viele konzentrieren sich nur auf die Erstellung des Schlüssels, vergessen aber die Gegenseite: den SSH-Daemon auf dem Server. Wenn Sie einen hochmodernen Schlüssel generieren, Ihr Server aber noch uralte Ciphers oder das veraltete SSH-Protokoll 1 zulässt, haben Sie nichts gewonnen. Ein Angreifer wird immer den schwächsten Punkt wählen. In meiner Praxis konfiguriere ich Server so, dass sie nur die sichersten Schlüsselaustausch-Algorithmen akzeptieren.
Es bringt Ihnen wenig, einen Tresor mit einem biometrischen Schloss zu haben, wenn die Rückwand des Tresors aus Pappe besteht. Prüfen Sie Ihre /etc/ssh/sshd_config. Deaktivieren Sie RootLogin und stellen Sie sicher, dass nur Protokoll 2 verwendet wird. Das sind Handgriffe von fünf Minuten, die darüber entscheiden, ob Ihr Server morgen noch Ihnen gehört oder Teil einer kriminellen Infrastruktur ist. Ich habe Kunden gesehen, die dachten, eine Firewall reicht aus. Eine Firewall schützt Sie aber nicht vor einem autorisierten Zugriff über einen schwachen oder kompromittierten SSH-Kanal.
Realitätscheck
Kommen wir zur Sache: SSH-Schlüssel sind kein "Set-and-forget"-Werkzeug. Die Technologie entwickelt sich weiter, und was vor fünf Jahren sicher war, ist heute ein Risiko. Wer Erfolg haben will und seine Infrastruktur wirklich schützen möchte, muss begreifen, dass Sicherheit Arbeit bedeutet. Es gibt keine magische Software, die Ihnen das Denken abnimmt. Wenn Sie zu faul sind, eine Passphrase zu nutzen oder sich mit den Unterschieden der Algorithmen zu beschäftigen, werden Sie scheitern. Es ist nur eine Frage der Zeit.
In der echten Welt gibt es keinen perfekten Schutz, nur Risikominimierung. Ein korrekt generierter und verwalteter SSH-Key ist Ihr wichtigstes Werkzeug. Aber er ist nur so stark wie das schwächste Glied in Ihrer Kette – und das ist meistens der Mensch vor dem Bildschirm, der aus Bequemlichkeit Abkürzungen nimmt. Wenn Sie die hier beschriebenen Schritte ignorieren, sparen Sie vielleicht heute fünf Minuten Zeit, zahlen aber in einem Jahr mit Ihren Daten, Ihrem Ruf oder Ihrem Geld. So funktioniert das in der IT-Sicherheit nun mal. Klappt nicht mit Halbwissen, da müssen Sie schon richtig ran.
