English ▾ Themen ▾ Neueste Version ▾ git-credential zuletzt aktualisiert in 2.46.0

NAME

git-credential - Benutzeranmeldedaten abrufen und speichern

SYNOPSIS

'git credential' (fill|approve|reject|capability)

BESCHREIBUNG

Git verfügt über eine interne Schnittstelle zum Speichern und Abrufen von Anmeldedaten von systemspezifischen Helfern sowie zum Abfragen des Benutzers nach Benutzernamen und Passwörtern. Der Befehl git-credential stellt diese Schnittstelle für Skripte bereit, die Anmeldedaten auf die gleiche Weise wie Git abrufen, speichern oder abfragen möchten. Das Design dieser skriptfähigen Schnittstelle orientiert sich an der internen C-API. Weitere Hintergrundinformationen zu den Konzepten finden Sie in credential.h.

git-credential nimmt eine "action"-Option auf der Kommandozeile (eine von fill, approve oder reject) entgegen und liest eine Beschreibung der Anmeldedaten von stdin (siehe EIN-/AUSGABEFORMAT).

Wenn die Aktion fill ist, versucht git-credential, die Attribute "username" und "password" zur Beschreibung hinzuzufügen, indem es Konfigurationsdateien liest, konfigurierte Anmeldedaten-Helfer kontaktiert oder den Benutzer auffordert. Die Attribute "username" und "password" der Anmeldedatenbeschreibung werden dann zusammen mit den bereits bereitgestellten Attributen nach stdout ausgegeben.

Wenn die Aktion approve ist, sendet git-credential die Beschreibung an alle konfigurierten Anmeldedaten-Helfer, die die Anmeldedaten für die spätere Verwendung speichern können.

Wenn die Aktion reject ist, sendet git-credential die Beschreibung an alle konfigurierten Anmeldedaten-Helfer, die übereinstimmende gespeicherte Anmeldedaten löschen können.

Wenn die Aktion capability ist, kündigt git-credential alle unterstützten Fähigkeiten auf der Standardausgabe an.

Wenn die Aktion approve oder reject ist, sollte keine Ausgabe erfolgen.

TYPISCHE VERWENDUNG VON GIT CREDENTIAL

Eine Anwendung, die git-credential verwendet, wird typischerweise git credential nach folgenden Schritten verwenden:

  1. Generieren einer Beschreibung der Anmeldedaten basierend auf dem Kontext.

    Wenn wir beispielsweise ein Passwort für https://example.com/foo.git benötigen, könnten wir die folgende Beschreibung der Anmeldedaten generieren (vergessen Sie nicht die Leerzeile am Ende; sie teilt git credential mit, dass die Anwendung das Einspeisen aller verfügbaren Informationen beendet hat)

    protocol=https
    host=example.com
    path=foo.git
  2. Fordern Sie git-credential auf, uns einen Benutzernamen und ein Passwort für diese Beschreibung zu geben. Dies geschieht durch Ausführen von git credential fill, wobei die Beschreibung aus Schritt (1) an seine Standardeingabe übergeben wird. Die vollständige Beschreibung der Anmeldedaten (einschließlich der Anmeldedaten selbst, d. h. Login und Passwort) wird auf der Standardausgabe ausgegeben, wie z. B.:

    protocol=https
    host=example.com
    username=bob
    password=secr3t

    In den meisten Fällen werden die in der Eingabe angegebenen Attribute in der Ausgabe wiederholt, aber Git kann die Beschreibung der Anmeldedaten auch ändern, z. B. durch Entfernen des path-Attributs, wenn das Protokoll HTTP(s) ist und credential.useHttpPath falsch ist.

    Wenn git credential das Passwort kannte, war dieser Schritt möglicherweise nicht mit der tatsächlichen Eingabe des Passworts durch den Benutzer verbunden (der Benutzer hat möglicherweise stattdessen ein Passwort zur Entsperrung des Schlüsselbunds eingegeben oder es wurde keine Benutzerinteraktion durchgeführt, wenn der Schlüsselbund bereits entsperrt war), bevor er password=secr3t zurückgab.

  3. Verwenden Sie die Anmeldedaten (z. B. greifen Sie mit dem Benutzernamen und dem Passwort aus Schritt (2) auf die URL zu) und prüfen Sie, ob sie akzeptiert werden.

  4. Melden Sie den Erfolg oder Misserfolg des Passworts. Wenn die Anmeldedaten den Vorgang erfolgreich abschließen konnten, können sie mit der Aktion "approve" markiert werden, um git credential anzuweisen, sie bei der nächsten Aufrufung wiederzuverwenden. Wenn die Anmeldedaten während des Vorgangs abgelehnt wurden, verwenden Sie die Aktion "reject", damit git credential bei der nächsten Aufrufung nach einem neuen Passwort fragt. In beiden Fällen sollte git credential mit der aus Schritt (2) erhaltenen Beschreibung der Anmeldedaten (die auch die in Schritt (1) bereitgestellten Felder enthält) gespeist werden.

EIN-/AUSGABEFORMAT

git credential liest und/oder schreibt (abhängig von der verwendeten Aktion) Informationen zu Anmeldedaten in seine Standardeingabe/-ausgabe. Diese Informationen können sich entweder auf Schlüssel beziehen, für die git credential die Anmeldeinformationen (z. B. Host, Protokoll, Pfad) abruft, oder auf die eigentlichen abzurufenden Anmeldedaten (Benutzername/Passwort).

Die Anmeldedaten sind in eine Reihe benannter Attribute aufgeteilt, mit einem Attribut pro Zeile. Jedes Attribut wird durch ein Schlüssel-Wert-Paar angegeben, getrennt durch ein = (Gleichheitszeichen), gefolgt von einem Zeilenumbruch.

Der Schlüssel kann beliebige Bytes außer =, Zeilenumbruch oder NUL enthalten. Der Wert kann beliebige Bytes außer Zeilenumbruch oder NUL enthalten. Eine Zeile, einschließlich des abschließenden Zeilenumbruchs, darf nicht länger als 65535 Bytes sein, um eine effiziente Analyse durch Implementierungen zu ermöglichen.

Attribute mit Schlüsseln, die auf C-Style-Klammern [] enden, können mehrere Werte haben. Jede Instanz eines mehrwertigen Attributs bildet eine geordnete Liste von Werten – die Reihenfolge der wiederholten Attribute bestimmt die Reihenfolge der Werte. Ein leeres mehrwertiges Attribut (key[]=\n) löscht alle vorherigen Einträge und setzt die Liste zurück.

In allen Fällen werden alle Bytes so behandelt, wie sie sind (d. h. es gibt kein Quoting, und man kann keinen Wert mit einem Zeilenumbruch oder NUL darin übertragen). Die Liste der Attribute wird durch eine Leerzeile oder das Ende der Datei beendet.

Git versteht die folgenden Attribute:

protocol

Das Protokoll, über das die Anmeldedaten verwendet werden (z. B. https).

host

Der Remote-Hostname für eine Netzwerkanmeldedaten. Dies schließt die Portnummer ein, falls eine angegeben wurde (z. B. "example.com:8088").

path

Der Pfad, mit dem die Anmeldedaten verwendet werden. Z. B. für den Zugriff auf ein entferntes https-Repository ist dies der Pfad des Repositories auf dem Server.

username

Der Benutzername der Anmeldedaten, falls wir bereits einen haben (z. B. aus einer URL, der Konfiguration, dem Benutzer oder von einem zuvor ausgeführten Helfer).

password

Das Passwort der Anmeldedaten, falls wir es speichern lassen.

password_expiry_utc

Generierte Passwörter wie OAuth-Zugriffstoken können ein Ablaufdatum haben. Beim Lesen von Anmeldedaten von Helfern ignoriert git credential fill abgelaufene Passwörter. Dargestellt als Unix-Zeit UTC, Sekunden seit 1970.

oauth_refresh_token

Ein OAuth-Refresh-Token kann ein Passwort begleiten, das ein OAuth-Zugriffstoken ist. Helfer müssen dieses Attribut wie das Passwort-Attribut vertraulich behandeln. Git selbst hat kein spezielles Verhalten für dieses Attribut.

url

Wenn dieses spezielle Attribut von git credential gelesen wird, wird der Wert als URL analysiert und so behandelt, als ob seine Bestandteile gelesen worden wären (z. B. würde url=https://example.com sich so verhalten, als wären protocol=https und host=example.com bereitgestellt worden). Dies kann Aufrufern helfen, URLs selbst zu parsen.

Beachten Sie, dass die Angabe eines Protokolls obligatorisch ist und wenn die URL keinen Hostnamen angibt (z. B. "cert:///path/to/file"), die Anmeldedaten ein Hostnamenattribut enthalten, dessen Wert eine leere Zeichenkette ist.

In der URL fehlende Komponenten (z. B. gibt es im obigen Beispiel keinen Benutzernamen) bleiben unbesetzt.

authtype

Dies zeigt an, dass das betreffende Authentifizierungsschema verwendet werden soll. Gängige Werte für HTTP und HTTPS sind basic, bearer und digest, wobei letzteres unsicher ist und nicht verwendet werden sollte. Wenn credential verwendet wird, kann dies auf eine beliebige Zeichenkette gesetzt werden, die für das betreffende Protokoll (normalerweise HTTP) geeignet ist.

Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt.

credential

Die vorcodierten Anmeldedaten, die für das betreffende Protokoll (normalerweise HTTP) geeignet sind. Wenn dieser Schlüssel gesendet wird, ist authtype obligatorisch, und username und password werden nicht verwendet. Für HTTP verkettet Git den authtype-Wert und diesen Wert mit einem einzelnen Leerzeichen, um den Authorization-Header zu ermitteln.

Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt.

ephemeral

Dieser boolesche Wert gibt an, wenn er wahr ist, dass der Wert im Feld credential nicht vom Anmeldedaten-Helfer gespeichert werden sollte, da seine Nützlichkeit zeitlich begrenzt ist. Zum Beispiel wird ein HTTP-Digest-Anmeldedaten-Wert mit einer Nonce berechnet, und die Wiederverwendung führt nicht zu einer erfolgreichen Authentifizierung. Dies kann auch für kurzzeitige Anmeldedaten (z. B. 24 Stunden) verwendet werden. Der Standardwert ist false.

Der Anmeldedaten-Helfer wird trotzdem mit store oder erase aufgerufen, damit er feststellen kann, ob der Vorgang erfolgreich war.

Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt.

state[]

Dieser Wert liefert einen undurchsichtigen Zustand, der an diesen Helfer zurückgegeben wird, wenn er erneut aufgerufen wird. Jeder verschiedene Anmeldedaten-Helfer kann dies einmal angeben. Der Wert sollte ein Präfix enthalten, das für den Anmeldedaten-Helfer eindeutig ist, und Werte ignorieren, die nicht zu seinem Präfix passen.

Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt.

continue

Dies ist ein boolescher Wert, der, wenn er aktiviert ist, anzeigt, dass diese Authentifizierung ein nicht endgültiger Teil eines mehrstufigen Authentifizierungsschritts ist. Dies ist üblich bei Protokollen wie NTLM und Kerberos, bei denen zwei Runden der Client-Authentifizierung erforderlich sind, und das Setzen dieses Flags ermöglicht es dem Anmeldedaten-Helfer, den mehrstufigen Authentifizierungsschritt zu implementieren. Dieses Flag sollte nur gesendet werden, wenn eine weitere Stufe erforderlich ist; das heißt, wenn eine weitere Authentifizierungsrunde erwartet wird.

Dieser Wert sollte nicht gesendet werden, es sei denn, die entsprechende Fähigkeit (siehe unten) wird in der Eingabe bereitgestellt. Dieses Attribut ist einseitig von einem Anmeldedaten-Helfer, um Informationen an Git (oder andere Programme, die git credential aufrufen) weiterzugeben.

wwwauth[]

Wenn eine HTTP-Antwort von Git empfangen wird, die einen oder mehrere WWW-Authenticate-Authentifizierungs-Header enthält, werden diese von Git an die Anmeldedaten-Helfer weitergeleitet.

Jeder WWW-Authenticate-Header-Wert wird als mehrwertiges Attribut wwwauth[] übergeben, wobei die Reihenfolge der Attribute der Reihenfolge entspricht, in der sie in der HTTP-Antwort erscheinen. Dieses Attribut ist einseitig von Git, um zusätzliche Informationen an Anmeldedaten-Helfer weiterzugeben.

capability[]

Dies signalisiert, dass Git oder der Helfer, je nach Fall, die betreffende Fähigkeit unterstützt. Dies kann verwendet werden, um bessere, spezifischere Daten als Teil des Protokolls bereitzustellen. Eine capability[]-Direktive muss jedem Wert vorausgehen, der von ihr abhängt, und diese Direktiven sollten der erste im Protokoll angekündigte Punkt sein.

Es gibt zwei derzeit unterstützte Fähigkeiten. Die erste ist authtype, die anzeigt, dass die Werte authtype, credential und ephemeral verstanden werden. Die zweite ist state, die anzeigt, dass die Werte state[] und continue verstanden werden.

Es ist nicht obligatorisch, die zusätzlichen Funktionen zu nutzen, nur weil die Fähigkeit unterstützt wird, aber sie sollten nicht ohne die Fähigkeit bereitgestellt werden.

Nicht erkannte Attribute und Fähigkeiten werden stillschweigend verworfen.

FÄHIGKEITEN EIN-/AUSGABEFORMAT

Für git credential capability ist das Format etwas anders. Zuerst wird eine Ankündigung version 0 gemacht, um die aktuelle Version des Protokolls anzuzeigen, und dann wird jede Fähigkeit mit einer Zeile wie capability authtype angekündigt. Anmeldedaten-Helfer können dieses Format ebenfalls implementieren, wiederum mit dem Argument capability. Zukünftig können weitere Zeilen hinzugefügt werden; Aufrufer sollten Zeilen ignorieren, die sie nicht verstehen.

Da dies ein neuer Teil des Anmeldedaten-Helfer-Protokolls ist, werden ältere Versionen von Git sowie einige Anmeldedaten-Helfer es möglicherweise nicht unterstützen. Wenn ein Nicht-Null-Exit-Status empfangen wird oder wenn die erste Zeile nicht mit dem Wort version und einem Leerzeichen beginnt, sollten Aufrufer davon ausgehen, dass keine Fähigkeiten unterstützt werden.

Die Absicht dieses Formats besteht darin, es eindeutig vom Anmeldedaten-Output zu unterscheiden. Es ist möglich, sehr einfache Anmeldedaten-Helfer (z. B. Inline-Shell-Skripte) zu verwenden, die immer identische Ausgaben erzeugen. Die Verwendung eines separaten Formats ermöglicht es Benutzern, diese Syntax weiterhin zu verwenden, ohne sich um die korrekte Implementierung von Fähigkeitsanzeigen kümmern oder versehentlich Aufrufer verwirren zu müssen, die nach Fähigkeiten fragen.

GIT

Teil der git[1] Suite