# SSH Keys Mastery: Kryptografisches Identitätsmanagement

TL;DR / Management Summary Ein Passwort kann erraten werden, ein kryptografischer Schlüssel nicht. In der Enterprise-Welt nutzen wir ausschließlich SSH-Keys zur Authentifizierung. Während der alte RSA-Standard ausgedient hat, setzen wir heute auf Ed25519 für maximale Sicherheit und Performance. In diesem Modul lernen wir, wie wir Schlüssel sicher generieren, an hunderte Server verteilen und – am wichtigsten – wie wir sie regelmäßig rotieren, um den Zugriffsschutz aufrechtzuerhalten.

# 1. Einführung & Architektur

Die Wahl des Algorithmus.

Nicht alle Schlüssel sind gleich. Die Wahl des Algorithmus bestimmt die Sicherheit und Kompatibilität.

# Der Algorithmus-Check (Mermaid)

graph TD
    A[SSH Key Algorithm] --> B[RSA: Legacy / Wide Compat]
    A --> C[ECDSA: Faster / Shorter]
    A --> D[Ed25519: Modern / High Security]
    B --> B1[Min 3072 bit required]
    C --> C1[Curve NIST P-256]
    D --> D1[The Gold Standard for Enterprise]

# 2. Schlüssel sicher generieren

Vom Client zum Server.

# Der moderne Standard: Ed25519

Ed25519-Schlüssel sind klein (nur 68 Zeichen) und extrem sicher gegen Angriffe (inkl. Side-Channel).

ssh-keygen -t ed25519 -C "admin@company.com"

# 3. Schlüsselverteilung (Distribution)

Weg von Copy-Paste.

# ssh-copy-id

Der sicherste Weg, den öffentlichen Schlüssel auf einen Server zu bringen:

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

Dies setzt automatisch die korrekten Berechtigungen für den .ssh Ordner (700) und die authorized_keys Datei (600).

# 4. Day-2 Operations: Key Rotation

Den Zugriff aktuell halten.

In einer professionellen IT müssen Schlüssel regelmäßig getauscht werden (z.B. alle 12 Monate oder wenn ein Mitarbeiter das Team verlässt).

# Der Rotations-Workflow

1. Neuen Key generieren: ssh-keygen -t ed25519 ...
2. Zweiten Key hinzufügen: Fügen Sie den neuen Public Key zur authorized_keys hinzu, ohne den alten zu löschen.
3. Test: Einloggen mit dem neuen Key prüfen.
4. Alten Key entfernen: Löschen Sie den alten Eintrag aus der authorized_keys.

Automatisierungstipp: Nutzen Sie Ansible (Artikel 050), um die authorized_keys auf tausenden Servern gleichzeitig zu managen.

# 5. Troubleshooting & “War Stories”

Wenn der Zugriff verweigert wird.

# Story 1: “Die Permissions-Falle”

Symptom: Der Key liegt in der authorized_keys, aber der Server verlangt trotzdem ein Passwort. Ursache: SSH ist extrem penibel. Wenn das Home-Verzeichnis oder der .ssh Ordner für andere User schreibbar ist (777 oder 775), ignoriert SSH die Keys aus Sicherheitsgründen. Lösung: chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys.

# Story 2: “Der kompromittierte Admin-Laptop”

Symptom: Ein Laptop eines Admins wurde gestohlen. Auf dem Laptop lagen unverschlüsselte SSH-Keys zu 500 Servern. Ursache: Fehlende Passphrase und mangelndes Key-Management. Lösung: Sofortige Sperrung des Public Keys auf allen 500 Servern via Ansible. Prävention: Nutzen Sie Hardware-Security-Module (YubiKeys), um SSH-Keys physisch zu binden. Der Key kann den YubiKey niemals verlassen.

# 6. Fazit & Empfehlung

• Algorithmus: Nutzen Sie ausschließlich Ed25519, wo immer es die Software zulässt.
• Sicherheit: Nutzen Sie einen SSH-Agent (ssh-add), um Ihre Passphrase nur einmal pro Sitzung eingeben zu müssen.
• Hygiene: Nutzen Sie das Feld -C (Comment) beim Generieren, um zu wissen, zu welchem Gerät/User ein Key gehört.

# Anhang: Cheatsheet