Git verwendet keine Anmeldeinformationen für das lokale Repository

Lesezeit: 10 Minuten

Also arbeite ich von zu Hause aus und lasse meine Maschine mit meinen persönlichen Git-Anmeldeinformationen einrichten. Ich habe den Zugriff auf meine Arbeitsprojekte mit meinem persönlichen Git geteilt, aber jetzt, da die Arbeit von zu Hause aus offiziell dauerhaft geworden ist, hatte ich das Gefühl, dass ich dieses Problem beheben und alle meine Commits für Arbeitsprojekte über mein Arbeits-Git-Konto eingehen sollte.

Nachdem ich mich umgesehen hatte, stellte ich fest, dass ich die lokalen Repos einfach einzeln ändern konnte, um meine Work-Git-Anmeldeinformationen zu verwenden. Leicht genug.

Also habe ich die Befehle ausgeführt:

git config --local user.name workUserName

git config --local user.email [email protected]

Ich bin dann gelaufen…

git config --local --get user.name

… um zu überprüfen, ob es funktioniert hat, und es hat funktioniert. Ich habe meine Pushs durchgeführt und die Repos haben begonnen, die Commits erfolgreich als über mein Arbeitskonto kommend zu kennzeichnen.

Also habe ich heute ein neues Projekt gestartet, das nicht mit meinem persönlichen Git-Konto geteilt wurde, und nur mit meinem Arbeitskonto geteilt. Ich habe die gleichen Git-Befehle ausgeführt, um die lokalen Anmeldeinformationen auszutauschen und zu überprüfen, ob die Änderungen erfolgreich waren, und alles ausgecheckt. Wenn ich jedoch versuche, einen Push durchzuführen, heißt es, dass ich keinen Zugriff auf das Repository habe.

remote: Permission to repository.git denied to personalGitAccount.

Der einzige Unterschied scheint zu sein, dass dieses Repo nicht mit meinem persönlichen Git-Konto geteilt wird, das die globalen Anmeldeinformationen auf meinem Computer sind. Ich kann nicht verstehen, warum dies für ein Repository relevant wäre, bei dem die lokalen Anmeldeinformationen geändert wurden. Muss ich dieses Repo sowohl für mein persönliches als auch für mein Arbeitskonto freigeben, um Pushes an die Codebasis vorzunehmen?

  • user.name und user.email Konfigurationswerte sind nicht Referenzen. Dies sind nur die Werte, die zum Ausfüllen des Autors beim Erstellen eines Commits verwendet werden.

    – Strickl

    22. Juli 2021 um 19:26 Uhr

Wie knittl in einem Kommentar feststellte, user.name und user.email sind nicht Referenzen und werden während der Einrichtung und Überprüfung der Anmeldeinformationen nicht verwendet. Das lässt jedoch eine große Frage offen: Woher kommen irgendwelche Anmeldeinformationen? Leider lautet die Antwort: es hängt davon ab, obwas bedeutet, dass wir eine andere Frage haben: hängt davon ab, ob? Der erste Teil davon ist die URL du verwendest:

  • Ein http oder https Die URL bewirkt, dass Git libcurl durchläuft, was bedeutet, dass Sie libcurl-Authentifizierung und Anmeldeinformationen erhalten. Dies wird dann durch Ihr Betriebssystem kompliziert: libcurl wird mit betriebssystemspezifischem Code erstellt.
  • Ein ssh URL bewirkt, dass Git ssh durchläuft, was bedeutet, dass Sie ssh-Authentifizierung und -Anmeldeinformationen erhalten. Dies wird dann durch Ihr Betriebssystem kompliziert: ssh wird nicht nur mit betriebssystemspezifischem Code erstellt, sondern unter Windows neigen die Git-Distributionen dazu, eine ssh-Implementierung zu enthalten, falls Windows keine hat, und dennoch haben einige Versionen von Windows eine.

Dies führt Sie zu den nächsten Schritten. Angesichts der von Ihnen bereitgestellten Informationen können wir eigentlich nicht mehr gehen – aber ich habe eine Vermutung, basierend auf der Tatsache, dass Sie das github-Tag eingefügt haben und dass GitHub die Leute dazu gedrängt hat, ssh zu verwenden (unter anderem durch vorübergehend ab und zu den https-Zugriff ganz deaktivieren). Ich weiß nicht, was Ihr Betriebssystem ist, daher kann ich keine Windows- oder macOS-spezifischen Elemente einschließen (und würde es sowieso nicht tun, da ich Windows nicht verwende und versuche, mich nicht auf macOS-spezifische Tricks zu verlassen, da ich Unix verwende /Linux-y-Systeme auch sehr oft). Aber wir können ziemlich weit kommen, wenn wir nur ssh-und-GitHub annehmen, weil Sie sich bei GitHub bei ihren Computern “anmelden” müssen.

SSH-Authentifizierung

Bei der Verwendung von ssh im Allgemeinen ist die Art und Weise, wie die Authentifizierung funktioniert, ein mehrstufiger Prozess:

  • Zuerst sucht Ihr Computer nach einem beliebigen Hostnamen, den Sie angeben (via ssh [email protected] command oder scp file [email protected]:path oder Wasauchimmer; mit Git-URLs ist es ssh://[email protected]/path oder [email protected]:path wenn Sie die Kurzschreibweise verwenden). Dies wird in eine IP-Adresse – IPv4 oder IPv6 – übersetzt, um den Host zu kontaktieren. Oder wenn Sie eine IP-Adresse direkt angeben, verwendet ssh diese.

  • Als nächstes kontaktiert Ihr ssh den ssh-Server auf diesem Host und erhält die Server “Fingerabdruck”. Ihr Computer kann diesen Fingerabdruck mit einem vergleichen, der in a gespeichert ist known_hosts Datei oder ähnliches. Ihr ssh kann Sie nun je nach Option auffordern, zu bestätigen, dass dies die Maschine ist, die Sie kontaktieren wollten, oder ob sie bereits in der aufgelistet ist known_hosts Datei und der Fingerabdruck übereinstimmt, einfach davon ausgehen dass es die richtige Maschine ist.

  • Ihr SSH-Client und der SSH-Server (sshd) durchlaufen nun einen ziemlich ausgefallenen Tanz, bei dem sie Protokollinformationen und Informationen zum Schlüsselaustausch austauschen. Auf diese Weise können sie Dinge verschlüsseln, noch bevor sie an den Punkt der Authentifizierung kommen. All das können wir hier ignorieren, obwohl viel dahintersteckt. (Verwenden Sie die -v Option zu sshmehrmals, um weitere Debug-Informationen zu erhalten, und Sie werden einiges davon sehen.)

  • Schließlich stellt Ihr von Git aufgerufenes ssh dem Server die Nutzername Sie bereitgestellt haben – was für GitHub muss sein git– zusammen mit A Öffentlicher Schlüssel. Seit der Nutzername die Git hier bereitstellen muss muss sein git, dürfen wir auch diesen ignorieren! (Außer, dass wir es irgendwo buchstabieren müssen, z. B. in der URL als ssh://[email protected]/path/to/repo.git.) Der Server – in diesem Fall GitHub – verwendet diese Informationen, um herauszufinden, wer Sie sind behauptet zu sein. Wir kommen gleich darauf zurück.

  • Jetzt, da der Server sshd Sie kennt Anspruch zu sein, sshd schickt dir mehr Sachen, die deine ssh muss entschlüsseln mit Ihrem Privat Schlüssel. Wenn Ihr ssh dazu in der Lage ist, glaubt der Server sshd jetzt, dass Sie tatsächlich die Person sind, für die Sie sich ausgaben. Daten können jetzt über die ssh/sshd-Verbindung fließen; Auf GitHub ruft sshd jetzt das GitHub-Git auf (durch einen zusätzlichen Code, den die GitHub-Leute geschrieben haben, der Zugriff auf die Informationen der Person hat, von denen Sie behaupteten zu sein, wie von GitHubs sshd verifiziert: dieser zusätzliche Code führt alle erforderlichen Überprüfungen durch) .

Der obige fettgedruckte Satz enthält daher den Schlüssel (wenn Sie den Ausdruck verzeihen), um den GitHub sshd dazu zu bringen, Sie “richtig” zu authentifizieren, für Ihre persönliche Definition von “richtig”. Seit du muss vorgeben zu sein gitdas Eigentliche Nutzername ist hier überhaupt nicht vorgesehen. Stattdessen ist es heimlich über den öffentlichen Schlüssel eingeschmuggelt.

Wenn Sie die GitHub-Webschnittstelle verwenden, um Ihren Public-Key-Zugriff auf Ihre Repositories einzurichten, authentifizieren Sie sich bei GitHub über https (nicht ssh). Auf diese Weise können Sie einen Benutzernamen eingeben und einen kopieren und einfügen ssh-keygen-generierter öffentlicher Schlüssel. Wenn Sie all dies tun, speichert GitHub den öffentlichen Schlüssel zusammen mit Ihrem Benutzernamen. Später, wenn Sie GitHub einen öffentlichen Schlüssel geben, werden sie nachschlagen diesen öffentlichen Schlüssel in ihrer Datenbank mit “allen öffentlichen Schlüsseln, die von einem Benutzer verwendet werden”. Diese Datenbank bietet ihnen die Nutzername.

Was das unterm Strich bedeutet, ist: Wenn Sie ssh auf GitHub verwenden, kommt der Benutzername, den Sie zur Authentifizierung verwenden, überhaupt nicht über das Internet. Es ist nur vermutet über den von Ihnen gesendeten öffentlichen Schlüssel. Sie müssen es also sein sehr präzise Über welche öffentlichen Schlüssel Sie senden. Der erste öffentliche Schlüssel, den Sie senden und den sie akzeptieren, bestimmt wer sie glauben, dass du bist.

Ihr ssh wird im Allgemeinen Schlüssel von Ihrem “Schlüsselbund” nacheinander ausprobieren, bis einer funktioniert oder ihm die Schlüssel ausgehen. Dies schafft Probleme.

Sie haben einen Benutzernamen pro öffentlichem Schlüssel für GitHub

Wenn Sie nur haben ein öffentlichen Schlüssel, den Sie mit GitHub verwenden, ist alles einfach (ish). Es gibt nur einen Schlüssel, der im Schloss funktionieren kann. Dieser eine Schlüssel ist Ihrem einen Benutzernamen zugeordnet An GitHub. Sie verwenden diesen Schlüssel und sie wissen, wer Sie sind.

Wenn Sie haben zwei öffentliche Schlüssel, aber und zwei Benutzernamen, jetzt wird es kompliziert. An jeden Ihrer beiden öffentlichen Schlüssel ist ein Benutzername angehängt. Nennen wir diese Tasten EIN und Bund die zugehörigen Benutzernamen ua und ub.

  • Wenn Sie den Schlüssel vorlegen EIN Erstens funktioniert es und GitHub glaubt, dass Sie es sind ua.

  • Wenn Sie den Schlüssel vorlegen B Erstens funktioniert es und GitHub glaubt, dass Sie es sind ub.

Ob ua und ub Zugang haben zu verschiedene Depotsmüssen Sie vorsichtig sein, welchen Schlüssel Sie präsentieren.

(Es gibt ein verwandtes Problem: Wenn Sie Tausende oder Millionen von Schlüsseln haben und Ihren ssh sie alle nacheinander ausprobieren lassen, einschließlich aller falschen, kann sein sshd misstrauisch werden. Stellen Sie sich vor, wie Sie sich fühlen würden, wenn Sie at zu Hause und ein Fremder kam an Ihre verschlossene Haustür und hat gerade angefangen, eine Million Schlüssel in Ihrem Schloss zu versuchen. Wir werden dies hier jedoch ignorieren.)

Steuern des Schlüssels, den Ihr ssh präsentiert

Jedes Betriebssystem kann seine eigenen Add-Ons für ssh haben, und sie können zusätzliche Falten in diesen Prozess werfen, aber auf der Basisebene von ssh-for-all-OSes liest ssh selbst eine Konfigurationsdatei. In dieser Konfigurationsdatei können Sie verschiedene Optionen festlegen:

  • IdentityFile benennt eine Datei auf Ihrem System, die die öffentlichen und/oder privaten Schlüssel enthält (sie sind normalerweise gepaart, so dass ~/.ssh/id1 und ~/.ssh/id1.pub sind die privaten und öffentlichen Schlüssel für id1zum Beispiel).
  • Das IdentitiesOnly flag sagt Ihrem ssh, es nicht anzubieten zusätzlich Schlüssel nicht aufgelistet über IdentityFile Linien.
  • User ist praktisch: Sie können dies verwenden, um das Tippen zu vermeiden [email protected].
  • HostName ist auch bequem: siehe unten.

Sie sollten daher mindestens diese Optionen verwenden: IdentitiesOnly um es deinem ssh zu sagen Probieren Sie keine anderen Schlüssel aus und IdentityFile um es deinem ssh zu sagen versuchen Sie es mit diesem Schlüssel.

Um Ihr ssh-Programm zu bekommen Spiel den richtigen Eintrag, werden Sie wahrscheinlich verwenden wollen Host Linien. Hier ist ein Beispiel ~/.ssh/config Datei. Seien Sie vorsichtig beim Ausschneiden und Einfügen von diesem; siehe fetter Text unten.

Host gh-work
        HostName github.com
        User git
        IdentityFile ~/.ssh/id_work.github.pub
        IdentitiesOnly yes
Host gh-home
        HostName github.com
        User git
        IdentityFile ~/.ssh/id_home.github.pub
        IdentitiesOnly yes

Sie können jetzt verwenden ssh://gh-work/corp/work-repo.git und ssh://gh-home/me/personal-project.git B. die Git-URLs für einige Unternehmensarbeits-Repositorys und einige persönliche Projekte. Das gh-work “Hostname” stimmt mit dem entsprechenden Eintrag in überein ~/.ssh/config. Das User git und HostName github.com Teile werden ersetzt gh-work mit [email protected], und die Identitätslinien stellen sicher, dass Sie nur den einen richtigen Schlüssel angeben, sodass GitHub Sie als Ihre „Arbeitspersona“ identifiziert. Das gh-home entry funktioniert fast identisch, präsentiert sich aber anders Schlüsseldamit GitHub Sie als Ihre „Home Persona“ identifiziert.

Diese beiden Einträge Liste .pub Dateien. Dies ist der Schlüssel, den Ihr Git senden soll. Dies funktioniert im Allgemeinen gut, wenn Sie eine verwenden ssh-agent. Es kann funktionieren oder nicht wenn du nicht den Agenten verwenden. Du kann müssen die Dateinamen ohne die auflisten .pub Teil, damit Ihr IdentityFile Linie zeigt auf die Privat Schlüssel. Machen Sie sich keine Sorgen, wenn Sie dies tun müssen: Ihr ssh sendet den öffentlichen Schlüssel, nicht den privaten (use ssh -Tvv gh-work oder ssh -Tvv gh-home um dies zu verifizieren). Ziehen Sie jedoch in Betracht, den Agenten zu verwenden, damit Sie dies nicht tun müssen und den privaten Schlüssel in einigen Fällen überhaupt nicht auf diesem bestimmten Host speichern müssen. Der Agent fügt eine zusätzliche Sicherheitsebene hinzu.

(Es gibt noch viel mehr, was Sie mit ssh tun können, aber das reicht für den Moment.)

  • Dies ist eine außergewöhnliche Antwort. Ich hatte keine Ahnung, welche Dose voller Würmer ich damit öffnete und wie komplex der Prozess hinter den Kulissen war, zwei separate GitHub-Konten zu führen. Dies gibt mir definitiv viel Google-Munition, obwohl ich besser verstehe, was die tatsächlichen Hürden sind, die ich überwinden muss. Danke für die ausführliche Antwort. Dies sollte ein Blogbeitrag werden.

    – Dale Spiteri

    23. Juli 2021 um 2:06 Uhr

1013820cookie-checkGit verwendet keine Anmeldeinformationen für das lokale Repository

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy