Einführung

Sich an einem Git-Remote zu authentifizieren ist meist unsichtbar, bis es schiefgeht. Die zwei Hauptmechanismen sind SSH-Schlüssel und HTTPS-Credentials (Passwörter oder, heute üblicher, Personal Access Tokens).

SSH-Schlüssel

Einen modernen Schlüssel generieren:

ssh-keygen -t ed25519 -C "[email protected]"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519     # macOS
ssh-add ~/.ssh/id_ed25519                           # Linux

Fügen Sie den öffentlichen Schlüssel (~/.ssh/id_ed25519.pub) zu Ihrem Hosting-Konto hinzu. Testen:

ssh -T [email protected]
# Hi ada! You've successfully authenticated...

SSH-Konfig

Pro-Host-Überschreibungen gehen in ~/.ssh/config:

Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

HTTPS-Credentials

Die meisten Hosts akzeptieren keine Konto-Passwörter mehr; verwenden Sie ein Personal Access Token (PAT) mit den richtigen Scopes. Git speichert es über einen Credential-Helper:

git config --global credential.helper cache              # In-Memory, läuft ab
git config --global credential.helper "cache --timeout=86400"
git config --global credential.helper osxkeychain        # macOS
git config --global credential.helper manager            # Windows
git config --global credential.helper store              # Klartext-Datei (nur falls nötig)

Beim ersten Push fragt Git nach, und der Helper speichert das Token.

Inspizieren und Löschen

echo "url=https://github.com" | git credential fill
echo "url=https://github.com" | git credential reject

git credential ist eine Low-Level-Schnittstelle zum Helper.

Pro-Host-Helper

git config --global credential.https://github.com.helper manager
git config --global credential.https://gitlab.com.helper cache

Nützlich, wenn verschiedene Hosts verschiedene Auth-Methoden erfordern.

Commits und Tags signieren

Authentifizierung und Signierung sind unterschiedlich. Signierung beweist die Urheberschaft eines Commits:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git commit -S -m "Signed commit"
git log --show-signature -1

2FA und SSO

Wenn Ihr Host 2FA erfordert, braucht HTTPS-Auth ein PAT (Passwörter sind blockiert). Für SSO-geschützte Organisationen muss das PAT auch SSO-autorisiert sein; sonst erhalten Pushes einen vagen "permission denied"-Fehler.

Pro-URL-Credentials

Gits Credential-System kann verschiedene Credentials pro Host oder Pfad speichern. Der Match-Schlüssel ist das URL-Präfix, sodass Sie etwa separate Tokens für Ihre persönliche und Arbeits-GitHub-Organisation haben können:

git config --global credential.https://github.com/work-org.helper manager
git config --global credential.https://github.com/personal.helper "store --file ~/.git-creds-personal"
git credential fill <<<"url=https://github.com/work-org/repo"

Die Einstellung credential.useHttpPath sagt Git, den Pfad in den Lookup-Schlüssel einzubeziehen, was pro-Repo-Credentials erlaubt. Verwenden Sie es nur bei Bedarf; es vervielfacht die Zahl gespeicherter Einträge.

Häufige Fehler

Mit einem Token pushen, dem die richtigen Scopes fehlen (z. B. read-only); die Fehlermeldung ist generisch. Übermäßig breite Scopes "zur Sicherheit" gewähren; minimieren. Tokens in credential.helper store auf gemeinsam genutzten Maschinen speichern; es ist eine Klartext-Datei. Vergessen, Ihren öffentlichen SSH-Schlüssel zum Host hochzuladen, und durch "permission denied (publickey)" verwirrt sein; ssh -vT git@host zeigt, was passiert. Schließlich: Protokolle mischen: Stellen Sie sicher, dass Ihre Remote-URL zu Ihrer Auth-Methode passt; git remote set-url kann wechseln.