Wie man SSH-Schlüssel mit OpenSSH auf macOS oder Linux erstellt

Die SSH-Schlüssel-basierte Authentifizierung ist die branchenübliche Methode zur Sicherung des Remote-Server-Zugriffs. Anstatt ein Passwort über das Netzwerk zu übertragen, beweist Ihr Client seine Identität, indem er eine kryptografische Herausforderung löst, die nur der Inhaber des privaten Schlüssels beantworten kann — der Server sieht den privaten Schlüssel selbst nie.

Ein SSH-Schlüsselpaar besteht aus zwei mathematisch verknüpften Dateien: einem privaten Schlüssel (ausschließlich auf Ihrem lokalen Rechner gespeichert, niemals geteilt) und einem öffentlichen Schlüssel (auf jedem Server bereitgestellt, auf den Sie zugreifen müssen). Wenn Sie eine Verbindung initiieren, verwendet OpenSSH einen Challenge-Response-Handshake, um zu überprüfen, ob Ihr privater Schlüssel dem öffentlichen Schlüssel auf dem Server entspricht, und gewährt Zugang ohne Passwortabfrage.

Warum SSH-Schlüssel der Passwort-Authentifizierung klar überlegen sind

Passwörter sind anfällig für Brute-Force-Angriffe, Credential Stuffing, Phishing und Abfangen in schlecht konfigurierten Netzwerken. SSH-Schlüssel eliminieren alle diese Angriffsvektoren gleichzeitig.

• Kryptografische Stärke: Ein 4096-Bit-RSA-Schlüssel oder ein Ed25519-Schlüssel ist mit aktueller Hardware rechnerisch nicht durch Brute-Force zu knacken.
• Kein Geheimnis wird übertragen: Der private Schlüssel verlässt niemals Ihren Rechner. Das Authentifizierungsprotokoll beweist den Besitz ohne Offenlegung.
• Automatisierungsbereit: CI/CD-Pipelines, Ansible-Playbooks, rsync-Jobs und cron-basierte Backups erfordern alle eine nicht-interaktive Authentifizierung. SSH-Schlüssel machen dies möglich, ohne Klartext-Passwörter in Skripte einzubetten.
• Überprüfbarkeit: Jedes Schlüsselpaar kann eindeutig durch seinen Fingerabdruck identifiziert werden, was es einfach macht, einen einzelnen kompromittierten Schlüssel zu widerrufen, ohne überall Anmeldedaten zu rotieren.
• Kompatibilität mit authorized_keys ACLs: Sie können einen bestimmten öffentlichen Schlüssel darauf beschränken, nur einen Befehl auszuführen, ihn an eine Quell-IP binden oder Port-Weiterleitung verhindern — Kontrollen, die die Passwort-Authentifizierung nicht replizieren kann.

Wenn Sie einen VPS oder einen dedizierten Server verwalten, ist die vollständige Deaktivierung der Passwort-Authentifizierung und die Durchsetzung des schlüsselbasierten Logins einer der wirkungsvollsten Sicherheitshärtungsschritte, die Sie unternehmen können.

Den richtigen Schlüsselalgorithmus wählen

Die ursprüngliche OpenSSH-Dokumentation und die meisten älteren Tutorials verwenden standardmäßig RSA. Das Feld hat sich weiterentwickelt. Hier ist ein präziser Vergleich aller Algorithmen, die ssh-keygen heute unterstützt:

Ed25519 ist der richtige Standard im Jahr 2024. Es erzeugt kürzere Schlüssel, signiert schneller, und seine feste Schlüsselgröße eliminiert das Risiko, versehentlich einen zu kleinen Schlüssel zu generieren. RSA mit 4096 Bit bleibt akzeptabel für Umgebungen, die mit älteren Systemen interoperieren müssen, die Ed25519-Unterstützung nicht haben (OpenSSH < 6.5, veröffentlicht 2014).

Voraussetzungen

• Eine macOS- oder Linux-Workstation mit installiertem OpenSSH. Beide Betriebssysteme liefern OpenSSH standardmäßig mit. Überprüfen Sie dies mit:

ssh -V

• Netzwerkzugang zu einem Remote-Server, auf dem Sie ein Konto haben (root oder ohne Privilegien).
• Grundlegende Vertrautheit mit einem Terminal.

Auf Linux-Distributionen, die eine minimale Installation ausliefern (Alpine, einige Debian-Netinstalls), installieren Sie die Client-Tools mit:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Schritt 1: Ein Terminal öffnen

macOS: Drücken Sie Cmd + Space, geben Sie Terminal ein und drücken Sie Enter. Alternativ navigieren Sie zu Programme > Dienstprogramme > Terminal. Power-User können iTerm2 oder das integrierte Terminal in VS Code verwenden.

Linux: Drücken Sie Ctrl + Alt + T in den meisten Desktop-Umgebungen, oder starten Sie den Terminal-Emulator Ihrer Distribution aus dem Anwendungsmenü.

Schritt 2: Das SSH-Schlüsselpaar generieren

Einen Ed25519-Schlüssel generieren (Empfohlen)

ssh-keygen -t ed25519 -C "your_email@example.com"

Das Flag -C fügt dem öffentlichen Schlüssel einen menschenlesbaren Kommentar hinzu. Verwenden Sie Ihre E-Mail-Adresse, einen Hostnamen oder ein beschreibendes Label wie "deploy-key-prod" — es hat keine kryptografische Funktion, ist aber unschätzbar wertvoll beim Prüfen von authorized_keys-Dateien, die Dutzende von Einträgen ansammeln.

Einen RSA-Schlüssel generieren (Legacy-Kompatibilität)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Verwenden Sie -b 4096 explizit. Der historische Standard von 2048 Bit ist technisch noch akzeptabel, bietet aber weniger Spielraum gegen zukünftige Fortschritte bei Faktorisierungsalgorithmen. Verwenden Sie niemals -b 1024 oder -b 2048 für neue Schlüssel, wenn 4096 verfügbar ist.

Einen benannten Schlüssel für einen bestimmten Host generieren

Wenn Sie mehrere Server oder Rollen verwalten, verwenden Sie unterschiedliche Schlüsseldateien, anstatt einen Schlüssel überall wiederzuverwenden. Ein kompromittierter Schlüssel betrifft dann nur die Systeme, auf denen er bereitgestellt wurde:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Schritt 3: Einen Speicherort wählen

Nach dem Ausführen von ssh-keygen sehen Sie:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Drücken Sie Enter, um den Standard zu akzeptieren (~/.ssh/id_ed25519 für Ed25519, ~/.ssh/id_rsa für RSA), oder geben Sie einen benutzerdefinierten Pfad ein. Der Standardspeicherort ist für einen einzelnen Allzweck-Schlüssel geeignet. Für rollenspezifische Schlüssel geben Sie immer einen beschreibenden Dateinamen an, wie im vorherigen Schritt gezeigt.

Wichtiger Hinweis zu Dateiberechtigungen: Das Verzeichnis ~/.ssh/ muss den Modus 700 haben und private Schlüsseldateien müssen den Modus 600 haben. OpenSSH verweigert die Verwendung von Schlüsseln mit zu freizügigen Berechtigungen und gibt eine Warnung aus. Wenn Sie jemals Schlüssel zwischen Rechnern kopieren, überprüfen Sie sofort die Berechtigungen:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Schritt 4: Eine Passphrase festlegen

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Eine Passphrase verschlüsselt die private Schlüsseldatei auf der Festplatte mit AES-256-CBC (in modernem OpenSSH). Wenn ein Angreifer Ihre private Schlüsseldatei erhält — durch einen gestohlenen Laptop, ein kompromittiertes Backup oder einen falsch konfigurierten Cloud-Snapshot — ist eine starke Passphrase die letzte Verteidigungslinie, die ihn daran hindert, sie zu verwenden.

Wann die Passphrase weggelassen werden sollte: Automatisierte Dienstkonten (Deployment-Pipelines, Backup-Agenten), die unbeaufsichtigt laufen, benötigen legitim passphrasenfreie Schlüssel. Schränken Sie in diesem Fall die Berechtigungen des Schlüssels auf der Serverseite mit authorized_keys-Optionen ein (siehe den erweiterten Abschnitt unten) und speichern Sie den privaten Schlüssel in einem Secrets-Manager anstatt in einem gemeinsam genutzten Dateisystem.

Nach der Bestätigung der Passphrase gibt OpenSSH den Schlüssel-Fingerabdruck und ein Randomart-Bild aus:

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Notieren Sie den Fingerabdruck. Sie werden ihn verwenden, um die Identität des Schlüssels beim Prüfen von Servern zu verifizieren.

Schritt 5: Den öffentlichen Schlüssel auf den Remote-Server kopieren

Methode 1: ssh-copy-id (Schnellste)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

Das Flag -i gibt explizit an, welcher öffentliche Schlüssel kopiert werden soll, und verhindert, dass ssh-copy-id jeden Schlüssel in Ihrem Agenten hochlädt. Sie werden einmalig nach dem Passwort des Servers gefragt. Das Tool übernimmt automatisch die Verzeichniserstellung, das Anhängen von Dateien und das Setzen von Berechtigungen.

Methode 2: Manuelle Bereitstellung (Wenn ssh-copy-id nicht verfügbar ist)

Dies ist der richtige Ansatz, wenn das Remote-System Windows ist, ein Netzwerkgerät oder ein Container ohne ssh-copy-id im Pfad.

Zeigen Sie zunächst Ihren öffentlichen Schlüssel an:

cat ~/.ssh/id_ed25519.pub

Kopieren Sie die gesamte Ausgabe — es ist eine einzelne Zeile, die mit ssh-ed25519 (oder ssh-rsa) beginnt. Melden Sie sich dann beim Server an und hängen Sie ihn an:

ssh user@your-server.com

Nach der Verbindung:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Häufiger Fehler: Die Verwendung von > anstelle von >> überschreibt die gesamte authorized_keys-Datei und sperrt jeden anderen Schlüssel aus. Verwenden Sie immer >> zum Anhängen.

Methode 3: Über SSH in einem Befehl weiterleiten

Wenn Sie bereits Passwort-Zugang haben und ohne interaktives Einloggen bereitstellen möchten:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Schritt 6: Die Verbindung testen

ssh -i ~/.ssh/id_ed25519 user@your-server.com

Eine erfolgreiche Verbindung ohne Passwortabfrage (oder nur mit einer Passphrasen-Abfrage für Ihren lokalen Schlüssel) bestätigt, dass die Einrichtung korrekt ist. Wenn die Verbindung fehlschlägt, führen Sie mit ausführlicher Ausgabe zur Diagnose aus:

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

Das Flag -vvv gibt das vollständige Aushandlungsprotokoll aus und zeigt genau, welcher Schlüssel angeboten wurde, ob der Server ihn akzeptiert hat und wo der Handshake fehlgeschlagen ist.

Schritt 7: ~/.ssh/config für persistente Host-Profile konfigurieren

Das vollständige ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 jedes Mal einzutippen ist fehleranfällig und langsam. Die SSH-Client-Konfigurationsdatei eliminiert dies:

nano ~/.ssh/config

Fügen Sie einen Host-Block hinzu:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Verbinden Sie sich jetzt einfach mit:

ssh prod-web

Dieses Muster skaliert sauber auf Dutzende von Servern und ist für jeden Ingenieur, der Infrastruktur in großem Maßstab verwaltet, unerlässlich. Die Direktive ServerAliveInterval 60 sendet alle 60 Sekunden ein Keepalive-Paket und verhindert, dass inaktive Verbindungen von Firewalls getrennt werden — eine häufige Frustration bei Cloud-Anbietern.

Mehrere Schlüssel mit dem SSH-Agenten verwalten

Der SSH-Agent hält entschlüsselte private Schlüssel für die Dauer Ihrer Sitzung im Speicher, sodass Sie die Passphrase einmal eingeben, anstatt bei jeder Verbindung.

Starten Sie den Agenten und fügen Sie einen Schlüssel hinzu:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Unter macOS können Sie Schlüssel über Neustarts hinweg persistieren, indem Sie folgendes zu ~/.ssh/config hinzufügen:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

Die Direktive UseKeychain yes integriert sich mit dem macOS-Schlüsselbund und speichert die Passphrase sicher, sodass sie Systemneustarts übersteht.

Alle aktuell im Agenten geladenen Schlüssel auflisten:

ssh-add -l

Einen bestimmten Schlüssel aus dem Agenten entfernen:

ssh-add -d ~/.ssh/id_ed25519

Erweitert: Schlüssel in authorized_keys einschränken

Die Datei authorized_keys unterstützt schlüsselspezifische Optionen, die den Schadensradius eines kompromittierten Schlüssels erheblich reduzieren. Diese werden vor dem Schlüsseltyp in derselben Zeile platziert:

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Diese Optionen sind besonders wertvoll für Deployment-Schlüssel auf dedizierten Servern, wo ein einzelner kompromittierter CI/CD-Schlüssel keinen vollständigen Shell-Zugang gewähren sollte.

Den SSH-Daemon nach der Schlüsselbereitstellung härten

Sobald die schlüsselbasierte Authentifizierung funktioniert, deaktivieren Sie die Passwort-Authentifizierung vollständig auf dem Server. Bearbeiten Sie /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Setzen Sie die folgenden Direktiven:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Laden Sie den Daemon neu, ohne Ihre aktuelle Sitzung zu trennen:

sudo systemctl reload sshd

Schließen Sie Ihre bestehende SSH-Sitzung nicht, bevor Sie eine neue Verbindung in einem separaten Terminal testen. Eine Fehlkonfiguration, die Sie aussperrt, ist über die Konsole behebbar, ist aber störend und vermeidbar.

Für Server, die cPanel VPS-Umgebungen betreiben, beachten Sie, dass einige cPanel-Versionen ihre eigene SSH-Konfiguration verwalten. Überprüfen Sie, dass sshd_config-Änderungen nach cPanel-Updates bestehen bleiben, indem Sie /etc/ssh/sshd_config.d/ auf Override-Dateien prüfen.

SSH-Schlüssel rotieren und widerrufen

Die Schlüsselrotation ist eine Sicherheitshygiene-Praxis, die das Expositionsfenster begrenzt, wenn ein Schlüssel stillschweigend kompromittiert wird. Ein praktischer Rotationsplan ist alle 12 Monate für persönliche Schlüssel und alle 90 Tage für Dienstkonto-Schlüssel.

Um einen Schlüssel zu widerrufen: Entfernen Sie seine Zeile aus ~/.ssh/authorized_keys auf jedem Server, auf dem er bereitgestellt wurde. Es gibt keinen zentralen Widerrufsmechanismus in Standard-OpenSSH — deshalb ist die Pflege eines Inventars, wo jeder Schlüssel-Fingerabdruck bereitgestellt ist, wichtig.

Um einen Schlüssel zu rotieren:

1. Generieren Sie ein neues Schlüsselpaar.
2. Stellen Sie den neuen öffentlichen Schlüssel auf allen Zielservern bereit.
3. Testen Sie die Konnektivität mit dem neuen Schlüssel.
4. Entfernen Sie den alten öffentlichen Schlüssel aus allen authorized_keys-Dateien.
5. Löschen oder archivieren Sie den alten privaten Schlüssel lokal.

Für Umgebungen mit VPS-Hosting in mehreren Regionen ist ein Konfigurationsmanagement-Tool wie Ansible die praktische Lösung für die Verbreitung von Schlüsselrotationen in großem Maßstab.

Schlüssel zwischen Rechnern übertragen

Wenn Sie eine neue Workstation einrichten, müssen Sie Ihre vorhandenen privaten Schlüssel migrieren, anstatt neue zu generieren (was eine erneute Bereitstellung öffentlicher Schlüssel überall erfordern würde).

Kopieren Sie den privaten Schlüssel sicher mit scp oder rsync über SSH:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Alternativ verwenden Sie ein verschlüsseltes USB-Laufwerk oder einen Passwort-Manager, der SSH-Schlüsselspeicherung unterstützt (1Password, Bitwarden und HashiCorp Vault unterstützen dies alle). Senden Sie niemals private Schlüssel per E-Mail oder speichern Sie sie in unverschlüsseltem Cloud-Speicher.

Überprüfen Sie nach der Übertragung sofort die Berechtigungen auf dem neuen Rechner:

chmod 600 ~/.ssh/id_ed25519

Den Host-Schlüssel-Fingerabdruck eines Servers verifizieren

Wenn Sie sich zum ersten Mal mit einem Server verbinden, präsentiert OpenSSH den Host-Schlüssel-Fingerabdruck des Servers und bittet Sie, ihn zu bestätigen:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Geben Sie niemals yes blind ein. Holen Sie den erwarteten Fingerabdruck über einen Out-of-Band-Kanal ein — das Kontrollpanel Ihres Hosting-Anbieters, einen Kollegen, der den Server bereitgestellt hat, oder die Konsolenausgabe des Servers. Dieser Schritt verhindert Man-in-the-Middle-Angriffe. Für Shared-Hosting-Umgebungen ist der erwartete Fingerabdruck typischerweise im Kontrollpanel unter den SSH-Zugriffseinstellungen aufgeführt.

Nach der Akzeptanz wird der Fingerabdruck in ~/.ssh/known_hosts gespeichert. Wenn sich der Fingerabdruck bei einer nachfolgenden Verbindung unerwartet ändert, verweigert OpenSSH die Verbindung und zeigt eine Warnung an — behandeln Sie dies als ernstes Sicherheitsereignis, das eine Untersuchung erfordert, bevor Sie fortfahren.

Entscheidungsmatrix und technische Checkliste

Verwenden Sie diese Checkliste, bevor Sie Ihre SSH-Schlüsseleinrichtung als produktionsbereit betrachten:

• [ ] Schlüsselalgorithmus ist Ed25519 (oder RSA 4096 für Legacy-Kompatibilität) — DSA und ECDSA 256 sind für neue Bereitstellungen nicht akzeptabel
• [ ] Private Schlüsseldatei-Berechtigungen sind 600; ~/.ssh/-Verzeichnisberechtigungen sind 700
• [ ] Eine starke Passphrase ist für alle interaktiven Benutzerschlüssel gesetzt
• [ ] Dienstkonto-Schlüssel ohne Passphrasen sind über authorized_keys-Optionen eingeschränkt (command=, from=, no-pty)
• [ ] PasswordAuthentication no ist in /etc/ssh/sshd_config auf allen Servern gesetzt
• [ ] PermitRootLogin prohibit-password oder PermitRootLogin no wird durchgesetzt
• [ ] Server-Host-Schlüssel-Fingerabdrücke wurden Out-of-Band verifiziert
• [ ] Ein Schlüsselinventar existiert, das jeden Fingerabdruck den Servern zuordnet, auf denen er bereitgestellt ist
• [ ] Schlüsselrotationsplan ist definiert und im Kalender eingetragen
• [ ] ~/.ssh/config-Host-Blöcke sind konfiguriert, um manuelle -i-Flag-Verwendung zu vermeiden
• [ ] SSH-Agent wird verwendet, um wiederholte Passphrasen-Eingabe während Arbeitssitzungen zu vermeiden
• [ ] known_hosts-Einträge werden regelmäßig auf veraltete oder unerwartete Einträge überprüft

FAQ

Was ist der Unterschied zwischen Ed25519- und RSA-SSH-Schlüsseln?

Ed25519 verwendet elliptische Kurven-Kryptografie mit einem festen 256-Bit-Schlüssel, der ungefähr 128 Bit Sicherheit bietet, Operationen schneller als RSA signiert und kürzere Schlüsselstrings erzeugt. RSA mit 4096 Bit bietet vergleichbare Sicherheit, ist aber langsamer und erzeugt größeres Schlüsselmaterial. Verwenden Sie Ed25519 für alle neuen Schlüssel, es sei denn, Sie müssen sich mit einem System verbinden, das OpenSSH älter als Version 6.5 ausführt.

Kann ich dasselbe SSH-Schlüsselpaar für mehrere Server verwenden?

Ja, technisch gesehen. Die beste Praxis ist jedoch, unterschiedliche Schlüsselpaare pro Rolle oder Umgebung zu verwenden (persönlicher Workstation-Zugang, CI/CD-Deployment, Datenbankwartung). Dies begrenzt die Auswirkungen eines einzelnen kompromittierten Schlüssels und macht den Widerruf unkompliziert, ohne nicht verwandte Systeme zu stören.

Was passiert, wenn ich meinen privaten Schlüssel verliere?

Sie verlieren die Möglichkeit, sich mit diesem Schlüsselpaar zu authentifizieren. Der öffentliche Schlüssel auf dem Server wird nutzlos. Sie müssen über eine alternative Methode auf den Server zugreifen — Konsolenzugang, einen sekundären Schlüssel oder den Notfallzugang Ihres Hosting-Anbieters — und dann den verwaisten öffentlichen Schlüssel aus authorized_keys entfernen und ein neues Schlüsselpaar bereitstellen.

Warum fragt SSH nach einem Passwort, nachdem ich meinen öffentlichen Schlüssel kopiert habe?

Die häufigsten Ursachen sind: falsche Berechtigungen auf ~/.ssh/ (muss 700 sein) oder ~/.ssh/authorized_keys (muss 600 sein) auf dem Server; das Home-Verzeichnis selbst ist world-writable; SELinux oder AppArmor blockiert den Zugang zum .ssh-Verzeichnis; oder PubkeyAuthentication no ist in /etc/ssh/sshd_config gesetzt. Führen Sie ssh -vvv aus, um genau zu identifizieren, welche Authentifizierungsmethode versucht und abgelehnt wird.

Wie entferne ich einen SSH-Schlüssel von einem Server, auf den ich keinen Zugang mehr habe?

Wenn Sie keine andere Authentifizierungsmethode haben, wenden Sie sich an das Support-Team Ihres Hosting-Anbieters oder verwenden Sie den Out-of-Band-Konsolenzugang (verfügbar für VPS– und dedizierte Server-Kunden), um sich einzuloggen und ~/.ssh/authorized_keys direkt zu bearbeiten. Deshalb ist die separate Pflege von Konsolenzugangs-Anmeldedaten von SSH-Schlüsseln eine nicht verhandelbare betriebliche Anforderung.