Git Credential Helpers einrichten: Zugangsdaten sicher verwalten

1. Warum HTTPS-Remotes ohne Helper nerven

Wer ein Remote-Repository über HTTPS statt SSH anspricht, muss sich bei jeder Operation, die Kontakt zum Server aufnimmt, authentifizieren. Ohne gespeicherte Zugangsdaten fragt Git bei jedem push, pull oder fetch erneut nach Benutzername und Token.

Das ist nicht nur lästig, es verleitet auch dazu, Zugangsdaten in der Remote-URL selbst zu hinterlegen, etwa als https://user:token@host/repo.git. Solche URLs landen dann im Klartext in .git/config und in der Shell-History, was ein erhebliches Sicherheitsrisiko darstellt.

Ein Credential Helper löst beide Probleme gleichzeitig: Er speichert Zugangsdaten an einer definierten Stelle und liefert sie bei Bedarf automatisch an Git zurück, ohne dass sie in der Konfiguration im Klartext sichtbar sein müssen.

# Ohne Helper: Passwortabfrage bei jeder Netzwerk-Operation
git push origin main
# Username für 'https://github.com': ...
# Password für 'https://user@github.com': ...

# Aktuell konfigurierten Helper anzeigen
git config --get-all credential.helper

2. Der eingebaute Cache Helper

Der einfachste Helper ist cache. Er hält Zugangsdaten für eine begrenzte Zeit im Arbeitsspeicher, ausgeliefert über einen kleinen Hintergrundprozess, den credential-cache--daemon. Standardmäßig beträgt die Gültigkeitsdauer 900 Sekunden.

Der große Vorteil: Es wird nichts dauerhaft auf die Festplatte geschrieben. Nach einem Neustart oder Ablauf der Zeitspanne sind die Daten verschwunden. Für kurze Arbeitssessions mit mehreren Pushes hintereinander ist das ausreichend.

Der Nachteil liegt in der begrenzten Lebensdauer: Wer länger als das konfigurierte Timeout pausiert, muss sich erneut authentifizieren. Für viele Entwickler, die den ganzen Tag am selben Repository arbeiten, ist das zu kurz gegriffen.

# Cache mit Standard-Timeout aktivieren
git config --global credential.helper cache

# Timeout auf vier Stunden verlängern
git config --global credential.helper 'cache --timeout=14400'

# Cache manuell leeren
git credential-cache exit

3. Der Store Helper und seine Risiken

Der store Helper schreibt Zugangsdaten dauerhaft und im Klartext in eine Datei, standardmäßig ~/.git-credentials. Das löst das Timeout-Problem des Cache Helpers vollständig, denn die Daten bleiben erhalten, bis sie explizit entfernt werden.

Genau das ist aber auch das Problem: Jeder Prozess und jeder Benutzer mit Lesezugriff auf diese Datei kann die Zugangsdaten im Klartext auslesen. Auf einem geteilten Rechner oder bei einem kompromittierten System ist das ein erhebliches Risiko.

In der Praxis sollte store nur auf klar abgesicherten Einzelplatz-Systemen eingesetzt werden, und selbst dann ist eine Verschlüsselungsschicht der bessere Weg. Auf allen gängigen Desktop-Betriebssystemen gibt es dafür bessere Alternativen.

# Store aktivieren (Klartext-Datei, nur mit Bedacht einsetzen)
git config --global credential.helper store

# Datei enthält Zeilen wie:
# https://user:token@github.com

# Dateiberechtigungen prüfen, sollten auf 600 stehen
ls -la ~/.git-credentials

4. OS-Keychains als sichere Alternative

Alle großen Betriebssysteme bringen einen eigenen verschlüsselten Schlüsselbund mit, den Git als Backend nutzen kann. Unter macOS ist das die osxkeychain, unter Windows der Windows Credential Manager über wincred, unter Linux libsecret als Anbindung an GNOME Keyring oder KWallet.

Diese Helper speichern Zugangsdaten verschlüsselt und binden sie an das Benutzerkonto des Betriebssystems. Ein Zugriff ist nur über die entsprechenden System-APIs möglich, nicht durch einfaches Lesen einer Textdatei.

Der Nachteil: Unter Linux muss libsecret oft erst kompiliert oder über ein Paket nachinstalliert werden, da es nicht in jeder Git-Distribution enthalten ist. Unter macOS und Windows funktioniert die Anbindung dagegen sofort.

# macOS
git config --global credential.helper osxkeychain

# Windows (Git for Windows bringt manager-core bereits mit)
git config --global credential.helper wincred

# Linux, nach Installation von libsecret
sudo apt install libsecret-1-0 libsecret-1-dev
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

5. Git Credential Manager als plattformübergreifende Lösung

Der Git Credential Manager, kurz GCM, ist ein eigenständiges Projekt von Microsoft, das auf allen drei großen Betriebssystemen dieselbe Erfahrung bietet. Er unterstützt neben klassischen Zugangsdaten auch OAuth-Flows für GitHub, GitLab, Bitbucket und Azure DevOps.

Statt Benutzername und Passwort manuell einzugeben, öffnet GCM bei Bedarf ein Browserfenster für die Anmeldung und speichert danach ein sicheres Token im jeweiligen OS-Keychain im Hintergrund. Das kombiniert Komfort mit dem Sicherheitsniveau der nativen Schlüsselbunde.

Für Teams, die sowohl unter macOS als auch unter Windows und Linux arbeiten, reduziert GCM den Konfigurationsaufwand erheblich, da eine einzige Lösung für alle Plattformen dieselben Befehle und dasselbe Verhalten liefert.

# GCM als Helper eintragen (nach Installation des Pakets)
git config --global credential.helper manager

# Bei GitHub anmelden, öffnet den Browser für OAuth
git push origin main
# Browserfenster öffnet sich automatisch zur Anmeldung

6. Mehrere Helper kombinieren und Prioritäten setzen

Git erlaubt es, mehrere credential.helper Einträge gleichzeitig zu konfigurieren. Sie werden der Reihe nach abgefragt, bis einer davon gültige Zugangsdaten liefert. Neue oder aktualisierte Daten werden an alle konfigurierten Helper gleichzeitig weitergereicht.

Eine gängige Kombination ist ein schneller cache Helper für kurzfristige Wiederholungen innerhalb einer Session, zusätzlich zu einem persistenten Keychain-Helper für die langfristige Speicherung. So entfällt selbst der kurze Zugriff auf den Systemschlüsselbund bei jeder einzelnen Operation.

Wichtig ist, die Reihenfolge zu verstehen: Ein leerer credential.helper Wert löscht zunächst alle zuvor gesetzten Helper aus vorherigen Konfigurationsebenen, bevor neue definiert werden. Das wird oft übersehen, wenn globale und lokale Konfiguration kombiniert werden.

# Zwei Helper kombinieren: schneller Cache plus persistenter Keychain
git config --global --unset-all credential.helper
git config --global --add credential.helper cache
git config --global --add credential.helper osxkeychain

# Aktive Helper in der richtigen Reihenfolge anzeigen
git config --get-all credential.helper

7. Unterschiedliche Helper pro Host

In Projekten mit mehreren Git-Hosts, etwa einem internen GitLab und gleichzeitig GitHub für Open-Source-Beiträge, lassen sich Helper pro URL konfigurieren. Das verhindert, dass ein Token für den falschen Dienst verwendet wird.

Die Konfiguration erfolgt über credential.<url>.helper, wobei die URL den Host oder sogar einen Pfad einschränken kann. Kombiniert mit includeIf lassen sich sogar ganze Konfigurationsblöcke abhängig vom Arbeitsverzeichnis laden, etwa unterschiedliche Identitäten für Firmen- und private Repositories.

Diese Granularität zahlt sich besonders in Teams aus, in denen Entwickler an mehreren Kundenprojekten mit jeweils eigenem Git-Server arbeiten. Ein falsch zugeordnetes Token fällt so gar nicht erst als Fehlerquelle ins Gewicht.

# Eigener Helper nur für einen bestimmten Host
git config --global credential.https://gitlab.internal.example.com.helper store
git config --global credential.https://github.com.helper osxkeychain

# includeIf für verzeichnisbasierte Konfiguration
[includeIf "gitdir:~/projekte/kunde-a/"]
    path = ~/.gitconfig-kunde-a

8. Personal Access Tokens statt Passwörter

GitHub, GitLab und Bitbucket verlangen bei HTTPS-Zugriffen inzwischen fast durchgängig Personal Access Tokens statt des Kontopassworts. Tokens lassen sich mit eingeschränktem Scope erzeugen, zeitlich begrenzen und jederzeit einzeln widerrufen, ohne das Hauptpasswort zu ändern.

Ein kompromittierter Token verursacht deutlich weniger Schaden als ein kompromittiertes Passwort, weil er nur für die Aktionen gültig ist, für die er ausgestellt wurde. Für CI-Systeme und Automatisierung sollten grundsätzlich eigene, eng begrenzte Tokens verwendet werden.

Wo möglich, ist SSH mit einem dedizierten Schlüsselpaar dennoch die robustere Alternative zu HTTPS-Tokens, da hier kein Credential Helper nötig ist. In vielen Unternehmensumgebungen ist SSH aber aus Firewall-Gründen blockiert, sodass HTTPS mit Token die einzig praktikable Option bleibt.

# Token statt Passwort bei der ersten Authentifizierung eingeben
git push origin main
# Username: dein-benutzername
# Password: ghp_xxxxxxxxxxxxxxxxxxxx   (Personal Access Token)

# Token-Scope so eng wie möglich wählen, z.B. nur repo:status

9. Debugging von Credential Helpern

Wenn Git trotz konfiguriertem Helper immer wieder nach Zugangsdaten fragt, hilft die eingebaute Diagnose-Umgebungsvariable. Sie zeigt exakt an, welche Helper in welcher Reihenfolge aufgerufen werden und was sie zurückliefern.

Ein weiteres nützliches Werkzeug ist git credential fill, das den Helper-Mechanismus isoliert von einer echten Netzwerk-Operation testet. So lässt sich schnell feststellen, ob das Problem am Helper selbst oder an der eigentlichen Authentifizierung beim Server liegt.

Häufige Fehlerquellen sind veraltete, im Keychain gespeicherte Tokens nach einem Passwort- oder Token-Wechsel, sowie widersprüchliche Konfiguration auf globaler und Repository-Ebene, die sich gegenseitig überschreiben.

# Detailliertes Tracing der Credential-Abfrage
GIT_TRACE=1 git push origin main

# Helper isoliert testen
echo -e "protocol=https\nhost=github.com" | git credential fill

# Veralteten Eintrag im macOS Keychain entfernen
git credential-osxkeychain erase <<< "protocol=https
host=github.com"

10. Zusammenfassung

11. FAQ: Credential Helpers