TL;DR — Kurzzusammenfassung

SSH-Schlüsselverwaltung für Sysadmins: Ed25519-Schlüssel generieren, ssh-agent nutzen, ~/.ssh/config konfigurieren, Schlüssel rotieren und SSH-Zertifikate.

SSH-Schlüssel sind die Grundlage für den sicheren Fernzugriff jedes Sysadmins und DevOps-Ingenieurs. Dieser SSH-Schlüsselverwaltungs-Leitfaden deckt den gesamten Lebenszyklus ab: Schlüssel generieren, mit ssh-agent cachen, mehrere Hosts mit ~/.ssh/config organisieren, öffentliche Schlüssel bereitstellen, kompromittierte Anmeldedaten rotieren und widerrufen, mit SSH-Zertifikaten skalieren und mit Hardware-Schlüsseln absichern.

Voraussetzungen

  • Linux, macOS oder WSL mit OpenSSH-Client (ssh, ssh-keygen, ssh-agent, ssh-copy-id).
  • SSH-Zugriff auf mindestens einen Remote-Server zum Üben.
  • Optional: ssh-audit (pip install ssh-audit) für Algorithmen-Audits.
  • Optional: YubiKey oder andere FIDO2-Hardware für maximalen Schutz.

SSH-Schlüssel generieren: Ed25519 vs RSA

Ed25519 (empfohlen)

ssh-keygen -t ed25519 -C "sie@beispiel.de"

Ed25519 verwendet elliptische Kurven-Kryptographie auf Curve25519. Schlüssel haben 256 Bit, Signaturen sind schnell und der Algorithmus ist resistent gegen Seitenkanalangriffe. Dies ist die Standardwahl für alle neuen Schlüssel.

RSA (Legacy-Kompatibilität)

ssh-keygen -t rsa -b 4096 -C "sie@beispiel.de"

Verwenden Sie RSA-4096 nur, wenn das Remote-System Ed25519 nicht unterstützt — zum Beispiel sehr alte OpenSSH-Versionen (< 6.5) oder bestimmte Netzwerkgeräte. RSA-2048 wird nicht mehr empfohlen.

Best Practices für Passphrasen

  • Setzen Sie immer eine Passphrase. Sie verschlüsselt Ihren privaten Schlüssel auf der Festplatte. Ein gestohlener Schlüssel ohne Passphrase ist wertlos.
  • Verwenden Sie mindestens 20 Zeichen — eine zufällige Passphrase aus Ihrem Passwort-Manager ist ideal.
  • Speichern Sie sie in Ihrem Passwort-Manager (1Password, Bitwarden, pass).

SSH Agent: Schlüssel für die Sitzung cachen

# Agent starten
eval "$(ssh-agent -s)"

# Schlüssel hinzufügen (fragt einmal nach der Passphrase)
ssh-add ~/.ssh/id_ed25519

# Geladene Schlüssel auflisten
ssh-add -l

# Alle Schlüssel entfernen
ssh-add -D

Sicherheitstipp: Übergeben Sie -t 3600 an ssh-add, um den Schlüssel nach einer Stunde automatisch ablaufen zu lassen:

ssh-add -t 3600 ~/.ssh/id_ed25519

SSH-Konfigurationsdatei: Mehrere Hosts verwalten

# ~/.ssh/config

# Standardeinstellungen für alle Hosts
Host *
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Produktions-Webserver
Host prod-web
    HostName 203.0.113.10
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519_prod

# Interner Datenbankserver über Jump-Host
Host db-internal
    HostName 10.0.1.50
    User dbadmin
    ProxyJump prod-web

# GitHub
Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Mit dieser Konfiguration verbindet sich ssh prod-web mit dem richtigen Benutzer und Schlüssel, und ssh db-internal tunnelt automatisch über den Bastion-Host.

Öffentliche Schlüssel bereitstellen

ssh-copy-id (am einfachsten)

ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@host

Manuelle Bereitstellung

cat ~/.ssh/id_ed25519.pub | ssh benutzer@host \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && \
   chmod 600 ~/.ssh/authorized_keys"

Dateiberechtigungen — kritisch

PfadBerechtigungWarum
~/.ssh/700Nur Eigentümer kann auflisten/betreten
~/.ssh/id_ed25519600Privater Schlüssel — nur Eigentümer lesen/schreiben
~/.ssh/id_ed25519.pub644Öffentlicher Schlüssel — von allen lesbar
~/.ssh/authorized_keys600Nur Eigentümer kann ändern
~/.ssh/config600Verhindert, dass andere Ihre Konfiguration lesen

SSH weigert sich, Schlüssel mit weltlesbaren Berechtigungen zu verwenden und schlägt lautlos fehl.

Schlüssel-Rotationsstrategien

Rotieren Sie SSH-Schlüssel wenn:

  • Ein Schlüssel älter als Ihre Organisationsrichtlinie ist (üblicherweise 1–2 Jahre).
  • Ein Mitarbeiter mit Schlüsselzugang das Unternehmen verlässt.
  • Eine Maschine oder ein Datenträger mit dem privaten Schlüssel außer Betrieb genommen oder verloren wurde.
  • Sie einen Kompromiss vermuten.

Sichere Rotationsprozedur:

  1. Neues Schlüsselpaar generieren: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_neu.
  2. Neuen öffentlichen Schlüssel auf alle Hosts bereitstellen, ohne den alten zu entfernen.
  3. Verifizieren Sie den Login mit dem neuen Schlüssel: ssh -i ~/.ssh/id_ed25519_neu benutzer@host.
  4. ~/.ssh/config aktualisieren, um den neuen Schlüssel zu verwenden.
  5. Alten öffentlichen Schlüssel aus allen authorized_keys-Dateien entfernen.
  6. Alten privaten Schlüssel sicher löschen: shred -u ~/.ssh/id_ed25519_alt.

Kompromittierte Schlüssel widerrufen

SSH hat keine integrierte Widerrufsliste für öffentliche Schlüssel, daher ist der Widerruf ein manueller Prozess:

  1. Schlüssel sofort entfernen aus allen authorized_keys-Dateien auf allen Hosts.
  2. Für SSH-Zertifikats-Infrastrukturen den Schlüssel zu einer RevokedKeys-Datei auf dem Server hinzufügen (RevokedKeys /etc/ssh/revoked_keys in sshd_config).
  3. Login-Logs auditieren (/var/log/auth.log, journalctl -u ssh) für Sitzungen mit dem kompromittierten Schlüssel.
  4. Alle Geheimnisse oder Anmeldedaten rotieren, auf die möglicherweise zugegriffen wurde.

SSH-Zertifikate: Flottenmanagement in großem Maßstab

Wenn Sie Dutzende oder Hunderte von Servern haben, ist die Verwaltung von authorized_keys auf jeder Maschine fehleranfällig. SSH-Zertifikate lösen dies durch eine Zertifizierungsstelle (CA).

CA-Schlüsselpaar erstellen

ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "org-ssh-ca"

Halten Sie ca_key privat und offline. Verteilen Sie ca_key.pub an jeden Server.

Server so konfigurieren, dass sie der CA vertrauen

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

Benutzer-Schlüssel signieren

ssh-keygen -s /etc/ssh/ca_key \
  -I "alice@corp" \
  -n alice,admin \
  -V +30d \
  ~/.ssh/id_ed25519.pub

Vorteile gegenüber authorized_keys

  • Automatischer Ablauf — Zertifikate laufen ohne manuelle Bereinigung ab.
  • Zentrale Kontrolle — Widerrufen durch Entfernen des CA-Vertrauens oder mit RevokedKeys.
  • Principal-Durchsetzung — Ein Zertifikat kann sich nur als bestimmte Benutzernamen anmelden.

Hardware-Schlüssel: YubiKey und FIDO2

# Schlüssel auf YubiKey/FIDO2 gespeichert generieren (OpenSSH 8.2+)
ssh-keygen -t ed25519-sk -O resident -C "yubikey@corp"

Der private Schlüssel verlässt das Gerät nie. Während der Authentifizierung erfordert das Gerät eine physische Berührung, was einen Remote-Schlüsseldiebstahl unmöglich macht.

Vergleichstabelle: Ed25519 vs RSA vs ECDSA

MerkmalEd25519RSA-4096ECDSA P-256
Schlüsselgröße256 Bit4096 Bit256 Bit
SignaturgeschwindigkeitSehr schnellLangsamSchnell
VerifikationsgeschwindigkeitSchnellSchnellSchnell
Schlüsseldateigröße~400 Bytes~3,3 KB~600 Bytes
Legacy-KompatibilitätOpenSSH 6.5+ (2014)UniversalOpenSSH 5.7+ (2011)
SeitenkanalresistenzAusgezeichnetMäßigSchlecht
FIDO2/Hardware-SchlüsselJa (ed25519-sk)NeinJa (ecdsa-sk)
EmpfehlungErste WahlNur LegacyVermeiden

Praxisszenario

Sie haben eine Produktionsflotte von 40 Linux-Servern. Drei Entwickler haben das Unternehmen letzten Monat verlassen. Sie müssen ihren SSH-Zugang sofort ohne Ausfallzeiten widerrufen.

Mit authorized_keys: Sie müssen auf alle 40 Server zugreifen (oder Ansible verwenden), den öffentlichen Schlüssel-Fingerabdruck jedes ausscheidenden Benutzers suchen, diese Zeilen entfernen und wiederholen. Ein vergessener Server ist eine Sicherheitslücke.

Mit SSH-Zertifikaten: Die CA hört einfach auf, Zertifikate für diese Benutzer zu signieren. Bestehende Zertifikate laufen natürlich ab. Für sofortigen Widerruf fügen Sie ihre Fingerabdrücke zur RevokedKeys-Datei hinzu, die in Sekunden via Ansible bereitgestellt wird:

ssh-keygen -lf ausscheidender-benutzer-cert.pub >> /tmp/widerrufen
ansible all -m copy -a "src=/tmp/widerrufen dest=/etc/ssh/revoked_keys mode=0644"
ansible all -m service -a "name=sshd state=reloaded"

In weniger als zwei Minuten auf der gesamten Flotte erledigt.

SSH-Schlüssel auf GitHub und GitLab einrichten

GitHub

gh ssh-key add ~/.ssh/id_ed25519.pub --title "arbeitsstation-2026"

Test: ssh -T git@github.com

GitLab

Schlüssel hinzufügen unter GitLab → Benutzereinstellungen → SSH-Schlüssel.

Test: ssh -T git@gitlab.com

Fallstricke und Sonderfälle

  • StrictHostKeyChecking=no in Skripten — Das Deaktivieren der Host-Schlüssel-Prüfung entfernt den Schutz gegen Man-in-the-Middle-Angriffe. Befüllen Sie stattdessen ~/.ssh/known_hosts während der Bereitstellung mit ssh-keyscan vor.
  • Geteilte Schlüssel — Teilen Sie niemals einen privaten Schlüssel zwischen mehreren Personen oder Maschinen. Jede Person und Maschine sollte ihr eigenes Schlüsselpaar haben.
  • Root-Login — Deaktivieren Sie PermitRootLogin yes in sshd_config. Verwenden Sie einen normalen Benutzer mit sudo.
  • Nicht-Standard-Schlüsselnamen — Wenn Sie einen Schlüssel mit nicht standardmäßigem Namen erstellen, verwendet SSH ihn nicht automatisch. Geben Sie ihn in ~/.ssh/config an oder übergeben Sie -i explizit.

Fehlerbehebung

ProblemLösung
”Permission denied (publickey)“Berechtigungen prüfen mit ls -la ~/.ssh/. Führen Sie ssh -vvv host aus, um zu sehen, welche Schlüssel versucht werden
Agent funktioniert nichtMit ssh-add -l prüfen. Bei “Could not open connection to agent” führen Sie eval $(ssh-agent -s) aus
Falscher Schlüssel für Host verwendetExplizites IdentityFile und IdentitiesOnly yes in ~/.ssh/config hinzufügen
”Host key verification failed”Der Host-Schlüssel des Servers hat sich geändert. Alten Eintrag entfernen: ssh-keygen -R hostname
Zertifikat abgelehntAblauf prüfen mit ssh-keygen -L -f cert.pub. Prüfen Sie, ob der Principal mit dem Benutzernamen übereinstimmt
YubiKey nicht erkanntStellen Sie sicher, dass pcscd läuft (systemctl start pcscd). Versuchen Sie ssh-add -K, um resident keys zu laden

Zusammenfassung

  • Generieren Sie Ed25519-Schlüssel für alle neuen Schlüsselpaare; verwenden Sie RSA-4096 nur für Legacy-Kompatibilität.
  • Setzen Sie immer eine Passphrase und verwenden Sie ssh-agent, um sie für die Sitzung zu cachen.
  • Verwenden Sie ~/.ssh/config mit ProxyJump, um mehrere Hosts und Bastions sauber zu verwalten.
  • Stellen Sie Schlüssel mit ssh-copy-id bereit; teilen Sie niemals private Schlüssel zwischen Personen oder Maschinen.
  • Für Flotten von mehr als ~10 Servern, setzen Sie SSH-Zertifikate ein für Ablauf, Principals und zentralen Widerruf.
  • Speichern Sie Schlüssel auf FIDO2-Hardware (YubiKey) für maximale Sicherheit.
  • Erzwingen Sie korrekte Dateiberechtigungen (700 auf ~/.ssh/, 600 auf Schlüsseln und authorized_keys).
  • Auditieren Sie Ihre SSH-Server-Konfiguration regelmäßig mit ssh-audit.

Verwandte Artikel