# SSH Agent & Forwarding: Komfort ohne Sicherheitsverlust

TL;DR / Management Summary Wer viele Server mit passwortgeschützten SSH-Keys verwaltet, will nicht bei jeder Verbindung die Passphrase tippen. Der SSH-Agent speichert entschlüsselte Schlüssel sicher im Arbeitsspeicher. Ein Senior Admin nutzt zudem Agent Forwarding, um seine Identität über Jump-Hosts hinweg mitzunehmen. Aber Vorsicht: Agent Forwarding hat eine dunkle Seite – wer Root-Zugriff auf einen Zwischen-Host hat, kann Ihren Agenten missbrauchen. Wir lernen, wie man dies durch ProxyJump sicher umgeht.

# 1. Einführung & Architektur

Der Identitäts-Speicher.

Der ssh-agent ist ein Hintergrundprozess, der Schlüssel für die Dauer der Sitzung vorhält. Das SSH-Client-Programm fragt den Agenten nach der Signatur, anstatt den Private-Key von der Platte zu lesen.

# Der Forwarding-Flow (Mermaid)

graph LR
    A[Local Machine: Agent with Key] -->|SSH -A| B[Jump Host / Bastion]
    B -->|Forwarded Identity| C[Production Server]
    subgraph "The Danger Zone"
        B --- D[Attacker with Root on B]
        D -.->|Can access Socket| A
    end

# 2. Den SSH-Agent nutzen

Einmal tippen, oft nutzen.

# Agent starten und Key laden

# Startet den Agenten in der aktuellen Shell
eval $(ssh-agent)

# Key hinzufügen (fragt nach Passphrase)
ssh-add ~/.ssh/id_ed25519

# Status prüfen
ssh-add -l

# Automatisch beim Login (Zsh/Bash)

Fügen Sie Plugins wie ssh-agent (in Oh-My-Zsh) hinzu oder nutzen Sie keychain, um den Agenten über Sitzungen hinweg persistent zu halten.

# 3. Agent Forwarding: Nutzen und Risiko

Der bequeme Tunnel.

Mit dem Flag -A wird Ihr lokaler Agent-Socket auf den Ziel-Server gespiegelt.

ssh -A user@jump-host
# Auf dem Jump-Host können Sie nun:
ssh user@production-server # (Kein Key auf Jump-Host nötig!)

# 4. Die sichere Alternative: ProxyJump

Kein Forwarding nötig.

Ab OpenSSH 7.3 nutzen wir bevorzugt ProxyJump (-J). Dabei wird kein Agent-Socket auf dem Jump-Host erstellt. Der Traffic wird lediglich durchgereicht.

# Nutzung via CLI

ssh -J user@jump-host:22 user@production-server

# Nutzung via Config (~/.ssh/config)

Host prod
    HostName 10.0.0.50
    User admin
    ProxyJump jump-host

# 5. Troubleshooting & “War Stories”

Wenn der Agent den Dienst verweigert.

# Story 1: “Der hängende Agent-Socket”

Symptom: Ein Admin hat 10 SSH-Instanzen offen, aber ssh-add -l meldet “Could not open a connection to your authentication agent”. Ursache: Jede Shell-Instanz braucht die Umgebungsvariable $SSH_AUTH_SOCK. Diese geht oft verloren, wenn man su oder sudo -i nutzt. Lösung: Nutzen Sie sudo -E um die Umgebung zu behalten, oder nutzen Sie Tools wie direnv, um den Socket-Pfad automatisch zu setzen.

# Story 2: “Too many authentication failures”

Symptom: Der Login bricht sofort ab, noch bevor nach dem Passwort gefragt wird. Ursache: Der Agent hat 10 verschiedene Keys geladen. SSH probiert alle durch. Der Zielserver bricht nach 3-5 Versuchen ab. Lösung: Nutzen Sie IdentitiesOnly yes in Ihrer ~/.ssh/config, damit SSH nur den Key nutzt, der explizit für diesen Host definiert wurde.

# 6. Fazit & Empfehlung

• Pflicht: Nutzen Sie einen Agenten, um Ihre Keys mit starken Passphrasen zu schützen.
• Wahl: Vermeiden Sie -A (Forwarding) wo immer möglich. Nutzen Sie stattdessen ProxyJump.
• Sicherheit: Nutzen Sie ssh-add -t 1h, um die Gültigkeit von Schlüsseln im Agenten zeitlich zu begrenzen.

# Anhang: Cheatsheet