SSH-Schlüsselgenerator

RSA 2048-Bit entspricht den aktuellen Sicherheitsstandards und ist von der NIST bis mindestens 2030 zugelassen. RSA 4096-Bit bietet eine größere Sicherheitsmarge für Schlüssel, die über viele Jahre verwendet werden sollen, ist aber bei Handshake-Operationen deutlich langsamer (ungefähr 4x langsamer als 2048-Bit). Für die meisten Anwendungsfälle — Serverzugriff, GitHub/GitLab, CI/CD-Pipelines — ist 2048-Bit ausreichend. Für Schlüssel, die in Hochsicherheitsumgebungen verwendet werden oder für 10+ Jahre geplant sind, nutzen Sie 4096-Bit. Für die beste Kombination aus Geschwindigkeit und Sicherheit verwenden Sie stattdessen Ed25519.

Eine Passphrase verschlüsselt Ihre private Schlüsseldatei so, dass selbst wenn jemand die Datei erhält, er sie ohne die Passphrase nicht verwenden kann. Wenn Sie den Schlüssel verwenden, fragt Sie Ihr SSH-Client nach der Passphrase, um ihn zu entschlüsseln (ssh-agent kann den entschlüsselten Schlüssel zwischenspeichern, sodass Sie nicht wiederholt gefragt werden). Für benutzerorientierte Schlüssel (Ihr Laptop zu Ihren Servern) verwenden Sie eine Passphrase — sie bietet einen entscheidenden Schutz, falls Ihr Gerät verloren geht oder gestohlen wird. Für automatisierte CI/CD-Deployment-Schlüssel, die ohne menschliche Interaktion laufen, sind mit einer Passphrase geschützte Schlüssel unpraktisch; die Schlüsseldatei muss dann durch andere Mittel gesichert werden (Dateiberechtigungen, Secret Management Systeme).

Kopieren Sie den Inhalt des öffentlichen Schlüssels (beginnend mit "ssh-rsa" oder "ssh-ed25519") und fügen Sie ihn der Datei ~/.ssh/authorized_keys auf Ihrem Server hinzu. Ein öffentlicher Schlüssel pro Zeile. Wenn das Verzeichnis nicht existiert: mkdir -p ~/.ssh && chmod 700 ~/.ssh. Korrekte Berechtigungen setzen: chmod 600 ~/.ssh/authorized_keys. Die schnellste Methode von Ihrer lokalen Maschine aus: ssh-copy-id user@hostname (unter Verwendung Ihres Passworts für dieses einmalige Setup). Danach wird SSH Ihren Schlüssel automatisch verwenden. Ihr privater Schlüssel bleibt nur auf Ihrer lokalen Maschine und wird niemals irgendwo hochgeladen.

Der Kommentar ist ein Label, das im öffentlichen Schlüssel nach den Schlüsseldaten eingebettet ist (z. B. ssh-ed25519 AAAA... user@laptop). Er hat keine Auswirkungen auf die Authentifizierung — er dient rein der Beschreibung. Nutzen Sie ihn, um den Ursprung des Schlüssels zu identifizieren, wenn Sie authorized_keys auf einem Server überprüfen: Wer hat diesen Schlüssel erstellt, von welchem Gerät und für welchen Zweck? Gängige Formate: user@hostname (Standard), Ihre E-Mail-Adresse oder ein beschreibendes Label wie "ci-deploy-prod-2026". Wenn Sie mehrere Schlüssel in authorized_keys haben, hilft ein aussagekräftiger Kommentar dabei zu wissen, welchen Schlüssel Sie widerrufen müssen, wenn etwas schiefgeht.

Der Fingerabdruck ist ein SHA-256 Hash des öffentlichen Schlüssels, der im Base64-Format angezeigt wird (z. B. SHA256:abc123...). Er ist eine kompakte Methode, um einen spezifischen Schlüssel zu identifizieren und zu verifizieren. Wenn Sie sich zum ersten Mal per SSH mit einem Server verbinden, zeigt Ihnen der Server seinen Host-Key-Fingerabdruck an — Sie überprüfen diesen, um sicherzustellen, dass Sie sich mit dem richtigen Server verbinden. Wenn Sie einen öffentlichen Schlüssel zu GitHub, GitLab oder anderen Diensten hochladen, zeigen diese Ihnen den Fingerabdruck an. Wenn der Fingerabdruck mit dem übereinstimmt, den dieses Tool anzeigt, wurde der Schlüssel korrekt hochgeladen. Sie können auch ssh-keygen -l -f ~/.ssh/id_ed25519 auf Ihrem Gerät ausführen, um Fingerabdrücke lokal zu verifizieren.

Ja. Die gesamte Schlüsselgenerierung verwendet die Web Crypto API, eine native Browser-API, die kryptographisch sichere Operationen bereitstellt, die durch die Entropiequelle des Betriebssystems gestützt werden. Die Zufallszahlengenerierung verwendet crypto.getRandomValues(), nicht das unsichere Math.random(). Die generierten Schlüssel sind in ihrer Sicherheit vergleichbar mit denen, die mit ssh-keygen in der Befehlszeile erzeugt werden. Es wird nichts an einen Server gesendet — das Schlüsselpaar existiert nur in Ihrer Browser-Sitzung.

Ersetzen Sie niemals Ihre vorhandenen authorized_keys — fügen Sie Ihren neuen öffentlichen Schlüssel als zusätzlichen Eintrag hinzu. Öffnen Sie dann eine zweite SSH-Sitzung (ohne die aktuelle zu schließen), um den neuen Schlüssel zu testen. Erst nachdem Sie bestätigt haben, dass der neue Schlüssel funktioniert, sollten Sie alte Schlüssel entfernen oder Ihre Passwortrichtlinie ändern. Wenn Sie sich selbst aussperren, benötigen Sie einen Konsolenzugriff auf den Server (Cloud-Anbieter nennen dies oft "emergency console" oder "rescue mode"), um authorized_keys manuell zu bearbeiten.