Warnung
Behandle deine Zugriffstoken wie Kennwörter. Weitere Informationen findest du unter Schützen deiner personal access tokens.
Informationen zu personal access token
Personal access token stellen eine Alternative für die Verwendung von Kennwörtern für die Authentifizierung bei GitHub über die GitHub-API oder die Befehlszeile dar.
Personal access token sind für den Zugriff auf GitHub-Ressourcen in deinem Namen vorgesehen. Für den Zugriff auf Ressourcen im Auftrag einer Organisation oder für langfristige Integrationen sollte eine GitHub App verwendet werden. Weitere Informationen finden Sie unter Informationen zum Erstellen von GitHub-Apps.
Ein Token verfügt über die gleichen Funktionen für den Zugriff auf Ressourcen und zum Ausführen von Aktionen für diese Ressourcen, über die der Besitzer des Tokens verfügt. Er ist zudem durch alle Bereiche oder Berechtigungen beschränkt, die dem Token zugewiesen werden. Ein Token kann einem Benutzer keine zusätzlichen Zugriffsfunktionen gewähren. Beispielsweise kann ein personal access token mit einem admin:org-Bereich konfiguriert werden, aber wenn der Besitzer des Tokens kein Organisationsbesitzer ist, erhält das Token keinen Administratorzugriff auf die Organisation.
Arten von personal access token
GitHub unterstützt derzeit zwei Arten von personal access token: fine-grained personal access token und personal access tokens (classic). GitHub empfiehlt, nach Möglichkeit fine-grained personal access token anstelle von personal access tokens (classic) zu verwenden.
Hinweis
Fine-grained personal access token sind zwar sicherer und besser kontrollierbar, haben jedoch weniger Anwendungsfälle als ein personal access token (classic). Weitere Informationen findest du weiter unten im Abschnitt zu Einschränkungen von Fine-grained personal access tokens.
Sowohl fine-grained personal access tokens als auch personal access tokens (classic)s sind an den Benutzer gebunden, der sie erstellt hat, und werden inaktiv, wenn der Benutzer den Zugriff auf die Ressource verliert.
Organisationsbesitzerinnen können eine Richtlinie festlegen, um den Zugriff von personal access tokens (classic) auf ihre Organisation zu beschränken, und Unternehmensbesitzerinnen können den Zugriff von personal access tokens (classic) auf das Unternehmen oder Organisationen im Besitz des Unternehmens beschränken.. Weitere Informationen finden Sie unter Festlegen einer Richtlinie für persönliche Zugriffstoken für deine Organisation.
Fine-grained personal access tokens
Fine-grained personal access tokens bieten verschiedene Sicherheitsvorteile gegenüber personal access tokens (classic), haben jedoch auch Einschränkungen, wegen der du sie unter Umständen nicht immer verwenden kannst. Diese Einschränkungen und unsere Pläne, sie zu beheben, findest du im folgenden Abschnitt.
Wenn du ein fine-grained personal access token für dein Szenario verwenden kannst, bringt die das folgende Vorteile:
- Jedes Token kann nur auf Ressourcen zugreifen, die einem einzelnen Benutzerkonto oder einer einzelnen Organisation gehören.
- Der Zugriff eines jeden Tokens kann weiter auf bestimmte Repositorys dieses Benutzerkontos oder dieser Organisation beschränkt werden.
- Jedes Token erhält bestimmte, differenzierte Berechtigungen, die mehr Kontrolle bieten als die Geltungsbereiche, die für personal access tokens (classic) festgelegt werden.
- Organisationsinhaber*innen können die Genehmigung für alle fine-grained personal access token erzwingen, die auf Ressourcen in der Organisation zugreifen können.
- Unternehmensinhaber*innen können die Genehmigung für alle fine-grained personal access token erzwingen, die auf Ressourcen in der Organisation zugreifen können, die dem Unternehmen gehören.
Einschränkungen von Fine-grained personal access tokens
Fine-grained personal access tokens unterstützen nicht jedes Feature von personal access tokens (classic). Diese Featurelücken sind nicht dauerhaft. Wir bei GitHub arbeiten daran, sie zu schließen. Weitere Informationen dazu, wann diese Szenarios unterstützt werden, findest du in unserer öffentlichen Roadmap.
Bei Folgendem handelt es sich um die größten Lücken in fine-grained personal access token:
- Verwenden von fine-grained personal access token, um ohne Mitgliedsstatus zu öffentlichen Repositorys beizutragen
- Verwenden von fine-grained personal access token, um mit dem Status „externe Mitarbeit“ oder „Repositorymitarbeit“ zu Repositorys beizutragen
- Verwenden von fine-grained personal access token, um gleichzeitig auf mehrere Organisationen zuzugreifen
- Verwenden von fine-grained personal access token, um innerhalb eines Unternehmens, zu dem das Benutzerkonto gehört, auf
internal-Ressourcen zuzugreifen - Verwenden von fine-grained personal access token, um APIs aufzurufen, die das Unternehmenskonto verwalten
- Verwenden von fine-grained personal access token, um auf Pakete zuzugreifen
- Verwenden von fine-grained personal access token, um die Überprüfungs-API aufzurufen
- Verwenden von fine-grained personal access token für den Zugriff auf Projekte im Besitz eines Benutzerkontos
Alle diese Lücken werden im Laufe der Zeit geschlossen, da GitHub weiterhin in sicherere Zugriffsmuster investiert.
Personal access tokens (classic)
Personal access tokens (classic) sind weniger sicher. Derzeit funktionieren einige Features jedoch nur mit personal access tokens (classic):
- Nur personal access tokens (classic) verfügen über Schreibzugriff für öffentliche Repositorys, die nicht dir gehören oder sich im Besitz einer Organisation befinden, der du nicht angehörst.
- Nur personal access tokens (classic) verfügen automatisch über Schreibzugriff für interne Repositorys, die sich im Besitz deines Unternehmens befinden. Fine-grained personal access token muss Zugriff auf interne Repositorys gewährt werden.
- Externe Projektmitarbeiter*innen können nur personal access tokens (classic) verwenden, um auf Organisationsrepositorys zuzugreifen, an denen sie mitwirken.
- Nur personal access tokens (classic) können auf Unternehmen zugreifen. (Fine-grained personal access token können auf Organisationen im Besitz von Unternehmen zugreifen.)
- Einige REST-API-Endpunkte sind nur mit einem personal access tokens (classic) verfügbar. Um zu überprüfen, ob ein Endpunkt auch fine-grained personal access token unterstützt, sieh in der Dokumentation für diesen Endpunkt nach, oder lies Endpunkte, die für differenzierte persönliche Zugriffstoken verfügbar sind.
Wenn du ein personal access token (classic) verwendest, solltest du bedenken, dass es den Zugriff auf alle Repositorys innerhalb der Organisation, auf die du Zugriff hast, sowie auf alle persönlichen Repositorys in deinem persönlichen Konto gewährt.
Als Sicherheitsmaßnahme entfernt GitHub automatisch ein personal access token, das seit einem Jahr nicht verwendet wurde. Um die Sicherheit weiter zu verstärken, empfiehlt es sich, ein personal access token mit einem Ablaufdatum zu versehen.
Schützen deiner personal access token
Personal access token sind wie Kennwörter und weisen dieselben inhärenten Sicherheitsrisiken auf. Bevor du ein neues personal access token erstellst, solltest du überlegen, ob es eine sicherere Methode für die Authentifizierung gibt:
- Um über die Befehlszeile auf GitHub zuzugreifen, kannst du die GitHub CLI oder Git Credential Manager verwenden, anstatt ein personal access token zu erstellen.
- Wenn du ein personal access token in einem GitHub Actions-Workflow verwendest, solltest du prüfen, ob du stattdessen das integrierte
GITHUB_TOKENverwenden kannst. Weitere Informationen finden Sie unter Verwenden von GITHUB_TOKEN für die Authentifizierung in Workflows.
Wenn diese Optionen nicht verfügbar sind und du ein personal access token erstellen musst, solltest du einen anderen CLI-Dienst nutzen, um dein Token sicher zu speichern.
Wenn du ein personal access token in einem Skript verwendest, kannst du dein Token als Geheimnis speichern und dein Skript über GitHub Actions ausführen. Weitere Informationen findest du unter Verwenden von Geheimnissen in GitHub-Aktionen. Du kannst dein Token ebenfalls als Codespaces-Geheimnis speichern un dein Skript in Codespaces ausführen. Weitere Informationen findest du unter Verwalten deiner kontospezifischen Geheimnisse für GitHub Codespaces.
Weitere Informationen zu den Best Practices findest du unter Schützen deiner API-Anmeldeinformationen.
Erstellen eines fine-grained personal access token
Hinweis
Es gibt einen Grenzwert von 50 fine-grained personal access tokens, die du erstellen kannst. Wenn du mehr Token benötigst oder Automatisierungen erstellst, solltest du für eine bessere Skalierbarkeit und Verwaltung eine GitHub App verwenden. Weitere Informationen finden Sie unter Entscheidung, wann eine GitHub-App erstellt werden soll.
-
Verifiziere deine E-Mail-Adresse, falls du das noch nicht getan hast. 1. Klicken Sie auf einer beliebigen Seite auf GitHub oben rechts auf Ihr Profilfoto und dann auf Einstellungen.
-
Klicke auf der linken Seitenleiste auf Entwicklereinstellungen.
-
Klicke auf der linken Randleiste unter Personal access tokens auf Fine-grained tokens.
-
Klicke auf Neues Token generieren.
-
Gib unter Tokenname einen Namen für das Token ein.
-
Wählen unter Ablauf ein Ablaufdatum für das Token aus. Eine unbegrenzte Lebensdauer ist zulässig, kann aber durch eine von Ihrer Organisation oder Ihrem Unternehmensbesitzer festgelegte Richtlinie für die maximale Lebensdauer blockiert werden. Weitere Informationen findest du unter Erzwingen einer Richtlinie für die maximale Lebensdauer für personal access tokens.
-
Füge optional unter Beschreibung eine Notiz hinzu, um den Zweck des Token zu beschreiben.
-
Wähle unter Ressourcenbesitzer einen Ressourcenbesitzerin aus. Das Token kann nur auf Ressourcen zugreifen, die dem oder der ausgewählten Ressourcenbesitzer*in gehören. Organisationen, bei denen du Mitglied bist, werden nicht angezeigt, wenn die Organisation die Nutzung von fine-grained personal access token gesperrt hat. Weitere Informationen findest du unter Festlegen einer Richtlinie für persönliche Zugriffstoken für deine Organisation. Möglicherweise ist das einmalige Anmelden (Single Sign-On, SSO) erforderlich, wenn die ausgewählte Organisation das vorschreibt und du noch nicht über eine aktive Sitzung verfügst.
-
Wenn der Ressourcenbesitzer eine Organisation ist, die eine Genehmigung für fine-grained personal access token vorschreibt, gib optional im Feld unter „Ressourcenbesitzer“ eine Begründung für die Anforderung ein.
-
Wähle unter Repositoryzugriff die gewünschten Repositorys aus, auf die das Token zugreifen soll. Du solltest nur den mindestens erforderlichen Repositoryzugriff für deine Zwecke auswählen. Token enthalten immer schreibgeschützten Zugriff auf alle öffentlichen Repositorys auf GitHub.
-
Wenn du Nur ausgewählte Repositorys im vorherigen Schritt ausgewählt hast, wähle im Dropdownmenü Ausgewählte Repositorys die Repositorys aus, auf die du zugreifen möchtest.
-
Wähle unter Berechtigungen aus, welche Berechtigungen dem Token erteilt werden sollen. Je nachdem, welchen Ressourcenbesitzerin und welchen Repositoryzugriff du angegeben hast, gibt es Repository-, Organisations- und Kontoberechtigungen. Du solltest nur die mindestens erforderlichen Berechtigungen für deine Zwecke auswählen.
Das REST-API-Referenzdokument für jeden Endpunkt gibt an, ob der Endpunkt zusammen mit fine-grained personal access token funktioniert und welche Berechtigungen erforderlich sind, damit das Token den Endpunkt verwenden kann. Einige Endpunkte erfordern möglicherweise mehrere Berechtigungen und einige möglicherweise eine von mehreren Berechtigungen. Eine Übersicht über die Endpunkte der REST-API, auf die ein fine-grained personal access token mit jeder Berechtigung zugreifen kann, findest du unter Erforderliche Berechtigungen für differenzierte persönliche Zugangstoken.
-
Klicke dann auf Token generieren.
Wenn du eine Organisation als Ressourcenbesitzer ausgewählt hast und die Organisation eine Genehmigung für fine-grained personal access token vorschreibt, wird dein Token bis zur Überprüfung durch einen Organisationsadministratorin mit pending gekennzeichnet. Bis zur Genehmigung kann dein Token nur öffentliche Ressourcen lesen. Wenn du eine Inhaberin der Organisation bist, wird deine Anforderung automatisch genehmigt. Weitere Informationen finden Sie unter Überprüfen und Widerrufen persönlicher Zugriffstoken in deiner Organisation.
Vorabauffüllen von fine-grained personal access token-Details mit URL-Parametern
Du kannst Vorlagen für ein fine-grained personal access token über Links freigeben. Wenn du Tokendetails auf diese Weise speicherst, lassen sich Workflows leichter automatisieren, und die Entwicklererfahrung wird verbessert, da die relevanten Felder bereits ausgefüllt sind, wenn Benutzende zur Tokenerstellung weitergeleitet werden.
Jedes unterstützte Feld kann mithilfe eines bestimmten Abfrageparameters festgelegt werden. Alle Parameter sind optional und werden vom Formular für die Tokengenerierung überprüft, um sicherzustellen, dass die Kombinationen von Berechtigungen und Ressourcenbesitzenden sinnvoll sind.
Die folgende URL-Beispielvorlage enthält Zeilenumbrüche, um die Lesbarkeit zu verbessern:
http://github.com/settings/personal-access-tokens/new ?name=Repo-reading+token &description=Just+contents:read &target_name=octodemo &expires_in=45 &contents=read
http://github.com/settings/personal-access-tokens/new
?name=Repo-reading+token
&description=Just+contents:read
&target_name=octodemo
&expires_in=45
&contents=read
Probiere die URL aus, um ein Token mit contents:read und metadata:read, mit dem angegebenen Namen und der angegebenen Beschreibung sowie einem Ablaufdatum von 45 Tagen in der Zukunft zu erstellen. Es wird eine Fehlermeldung mit dem Hinweis Cannot find the specified resource owner: octodemo angezeigt, da du kein Mitglied der Organisation octodemo bist.
Im Folgenden sind einige Beispiel-URLs aufgeführt, die die am häufigsten verwendeten Token generieren:
- Lesen von Repositoryinhalten
- Pushzugriff auf Repositorys
- Zugriff auf GitHub-Modelle
- Aktualisieren von Code und Öffnen eines Pull Requests
- Verwalten von Copilot-Lizenzen in einer Organisation
Unterstützte Abfrageparameter
Halte dich an die Abfrageparameterdetails in der folgenden Tabelle, um eine eigene Tokenvorlage zu erstellen:
| Parameter | Type | Beispielwert | Gültige Werte | Beschreibung |
|---|---|---|---|---|
name | Zeichenfolge | Deploy%20Bot | ≤ 40 Zeichen, URL-codiert | Füllt den Anzeigenamen des Tokens vorab auf. |
description | Zeichenfolge | Used+for+deployments | ≤ 1.024 Zeichen, URL-codiert | Füllt die Beschreibung des Tokens vorab auf. |
target_name | Zeichenfolge | octodemo | Datenfeld für die benutzende Person oder Organisation | Legt das Ressourcenziel des Tokens fest. Dies ist die Person oder Organisation, die im Besitz der Repositorys ist, auf die das Token zugreifen kann. Wenn nicht angegeben, wird standardmäßig das Konto der aktuellen benutzenden Person verwendet. |
expires_in | integer | 30 oder none | Ganze Zahl zwischen 1 und 366 oder none | Tage bis zum Ablauf oder none für „nicht ablaufend“. Wenn nicht angegeben, beträgt der Standardwert 30 Tage oder weniger, wenn für das Ziel eine Tokengültigkeitsdauer-Richtlinie festgelegt ist. |
<permission> | Zeichenfolge | contents=read | Berechtigungsstufen und Zugriffsebenen | Die Berechtigungen, über die das Token verfügen soll. Berechtigungen können auf read, write oder admin festgelegt werden, aber nicht jede Berechtigung unterstützt jede dieser Ebenen. |
Berechtigungen
Jede unterstützte Berechtigung wird mit ihrem Namen als Abfrageparameter festgelegt, wobei der Wert die gewünschte Zugriffsebene angibt. Gültige Zugriffsebenen sind read, write und admin. Einige Berechtigungen unterstützen nur read, einige nur write, und nur einige wenige umfassen die Zugriffsebene admin. Verwende so viele Berechtigungen wie erforderlich (im Format &contents=read&pull_requests=write&...).
Du musst nicht sowohl read als auch write für eine Berechtigung in deine URL einschließen: write umfasst immer read, und admin umfasst immer write.
Kontoberechtigungen
Kontoberechtigungen werden nur verwendet, wenn die aktuelle benutzende Person als „Resource owner“ festgelegt ist.
| Parametername | Anzeigename | Zugriffsebenen |
|---|---|---|
blocking | Block another user | read, write |
codespaces_user_secrets | Codespaces-Benutzergeheimnisse | read, write |
copilot_messages | Copilot Chat | read |
copilot_editor_context | Copilot Editor Context | read |
emails | E-Mail-Adressen | read, write |
user_events | Ereignisse | read |
followers | Follower | read, write |
gpg_keys | GPG-Schlüssel | read, write |
gists | Gists | write |
keys | Git-SSH-Schlüssel | read, write |
interaction_limits | Interaktionsgrenzwerte | read, write |
knowledge_bases | Wissensdatenbanken | read, write |
user_models | Modelle | read |
plan | Plan | read |
private_repository_invitations | Private repository invitations | read |
profile | Profil | write |
git_signing_ssh_public_keys | SSH-Signaturschlüssel | read, write |
starring | Versehen mit einem Stern | read, write |
watching | Watching (Überwachung) | read, write |
Repositoryberechtigungen
Repositoryberechtigungen funktionieren unabhängig davon, ob als „Resource Owner“ eine benutzende Person oder eine Organisation festgelegt ist.
| Parametername | Anzeigename | Zugriffsebenen |
|---|---|---|
actions | Aktionen | read, write |
administration | Verwaltung | read, write |
attestations | Nachweise | read, write |
security_events | Codescanwarnungen | read, write |
codespaces | Codespaces | read, write |
codespaces_lifecycle_admin | Lebenszyklusverwaltung von Codespaces | read, write |
codespaces_metadata | Codespacemetadaten | read |
codespaces_secrets | Codespacegeheimnisse | write |
statuses | Commitstatus | read, write |
contents | Contents | read, write |
repository_custom_properties | Benutzerdefinierte Eigenschaften | read, write |
vulnerability_alerts | Dependabot-Warnungen | read, write |
dependabot_secrets | Dependabot-Geheimnisse | read, write |
deployments | Bereitstellungen | read, write |
discussions | Diskussionen | read, write |
environments | Umgebungen | read, write |
issues | Probleme | read, write |
merge_queues | Merge queues | read, write |
metadata | Metadaten | read |
pages | Seiten | read, write |
pull_requests | Pull Requests | read, write |
repository_advisories | Sicherheitsempfehlungen für Repositorys | read, write |
secret_scanning_alerts | Geheimnisüberprüfungswarnungen | read, write |
secrets | Geheimnisse | read, write |
actions_variables | Variablen | read, write |
repository_hooks | webhooks | read, write |
workflows | Workflows | write |
Organisationsberechtigungen
Organisationsberechtigungen können nur verwendet werden, wenn eine Organisation als „Resource Owner“ festgelegt ist.
| Parametername | Anzeigename | Zugriffsebenen |
|---|---|---|
organization_api_insights | API Insights | read |
organization_administration | Verwaltung | read, write |
organization_user_blocking | Blockieren von Benutzern | read, write |
organization_campaigns | Kampagnen | read, write |
organization_custom_org_roles | Benutzerdefinierte Organisationsrollen | read, write |
organization_custom_properties | Custom repository properties | read, write, admin |
organization_custom_roles | Benutzerdefinierte Repositoryrollen | read, write |
organization_events | Ereignisse | read |
organization_copilot_seat_management | GitHub Copilot Business | read, write |
issue_types | Issue Types | read, write |
organization_knowledge_bases | Wissensdatenbanken | read, write |
members | Member | read, write |
organization_models | Modelle | read |
organization_network_configurations | Netzwerkkonfigurationen | read, write |
organization_announcement_banners | Banner mit Ankündigungen der Organisation | read, write |
organization_codespaces | Organisationscodespaces | read, write |
organization_codespaces_secrets | Geheimnisse für Organisationscodespaces | read, write |
organization_codespaces_settings | Einstellungen für Organisationscodespaces | read, write |
organization_dependabot_secrets | Dependabot-Geheimnisse für Organisationen | read, write |
organization_code_scanning_dismissal_requests | Code scanning dismissal requests | read, write |
organization_private_registries | Private Registrierungen | read, write |
organization_plan | Plan | read |
organization_projects | Projekte | read, write, admin |
organization_secrets | Geheimnisse | read, write |
organization_self_hosted_runners | Selbstgehosteten Runnern | read, write |
team_discussions | Diskussionen im Team | read, write |
organization_actions_variables | Variablen | read, write |
organization_hooks | webhooks | read, write |
Erstellen eines personal access token (classic)
Hinweis
Organisationsbesitzer können den Zugriff auf personal access token (classic) auf ihre Organisation beschränken. Wenn du versuchst, ein personal access token (classic) für den Zugriff auf Ressourcen in einer Organisation zu verwenden, die den Zugriff mit personal access token (classic) deaktiviert hat, wird bei deiner Anforderung die Fehlermeldung 403 angezeigt. Du musst stattdessen eine GitHub App, OAuth app oder ein fine-grained personal access token verwenden.
Warnung
Dein personal access token (classic) kann auf alle Repositorys zugreifen, auf die du Zugriff hast. GitHub empfiehlt, stattdessen nach Möglichkeit fine-grained personal access token zu verwenden. Diese können auf bestimmte Repositorys beschränkt werden. Fine-grained personal access token ermöglichen es dir auch, präzise Berechtigungen anstelle eines allgemeinen Spektrums anzugeben.
-
Verifiziere deine E-Mail-Adresse, falls du das noch nicht getan hast. 1. Klicken Sie auf einer beliebigen Seite auf GitHub oben rechts auf Ihr Profilfoto und dann auf Einstellungen.
-
Klicke auf der linken Seitenleiste auf Entwicklereinstellungen.
-
Klicke auf der linken Randleiste unter Personal access tokens auf Tokens (classic).
-
Wählen Sie Neues Token generieren aus und klicken Sie dann auf Neues Token generieren(klassisch).
-
Gib im Feld „Notiz“ einen aussagekräftigen Namen für das Token ein.
-
Wähle Ablauf und dann eine Standardoption aus, oder klicke auf Benutzerdefiniert, um ein Datum einzugeben.
-
Wähle die Berechtigungen aus, die du diesem Token erteilen möchtest. Um das Token für den Zugriff auf Repositorys über die Befehlszeile zu verwenden, wähle Repository aus. Ein Token ohne zugewiesene Bereiche kann nur auf öffentliche Informationen zugreifen. Weitere Informationen finden Sie unter Bereiche für OAuth-Apps.
-
Klicke dann auf Token generieren.
-
Optional kannst du auf klicken, um das neue Token in die Zwischenablage zu kopieren.
-
Um dein Token für den Zugriff auf Ressourcen im Besitz einer Organisation zu verwenden, die SAML Single Sign-On nutzt, autorisiere das Token. Weitere Informationen findest du unter Autorisieren eines persönlichen Zugriffstokens für die Verwendung mit Single Sign-On.
Löschen: personal access token
Sie sollten eine personal access token löschen, wenn sie nicht mehr benötigt wird. Wenn Sie eine personal access token löschen, die zum Erstellen eines Bereitstellungsschlüssels verwendet wurde, wird auch der Bereitstellungsschlüssel gelöscht.
- Klicken Sie auf einer beliebigen Seite auf GitHub oben rechts auf Ihr Profilfoto und dann auf Einstellungen.
- Klicke auf der linken Seitenleiste auf Entwicklereinstellungen.
- Klicke in der linken Seitenleiste unter Personal access tokens entweder auf Fine-grained tokens oder Tokens (classic), je nachdem, welche Art personal access token du löschen möchtest.
- Klicke rechts neben dem zu löschenden PAT (personal access token) auf Löschen.
Hinweis
Wenn du ein kompromittiertes personal access token findest, das zu einer anderen Person gehört, kannst du eine Sperranforderung über die REST-API senden. Weitere Informationen findest du unter Best Practices zum Verhindern von Datenlecks in deiner Organisation.
Verwenden eines personal access token in der Befehlszeile
Wenn du über ein personal access token verfügst, kannst du es statt deines Kennworts eingeben, wenn du Git-Vorgänge über HTTPS ausführst.
Um beispielsweise ein Repository über die Befehlszeile zu klonen, gibst du den folgenden git clone-Befehl ein. Dann wirst du aufgefordert, deinen Benutzernamen und dein Kennwort einzugeben. Wenn du zur Eingabe deines Kennworts aufgefordert wirst, gib anstelle eines Kennworts dein personal access token ein.
$ git clone http://github.com/USERNAME/REPO.git
Username: YOUR-USERNAME
Password: YOUR-PERSONAL-ACCESS-TOKEN
Obwohl du deinen Benutzernamen zusammen mit deinem personal access token eingeben musst, wird der Benutzername nicht verwendet, um dich zu authentifizieren. Stattdessen wird die personal access token verwendet, um dich zu authentifizieren. Wenn du keinen Benutzernamen eingibst, erhältst du eine Fehlermeldung, dass deine Anmeldeinformationen ungültig sind.
Personal access token können nur für Git-Vorgänge mit HTTPS verwendet werden. Wenn dein Repository eine SSH-Remote-URL verwendet, musst du das Remoterepository von SSH auf HTTPS umstellen.
Wenn du nicht nach einem Benutzernamen und einem Passwort gefragt wirst, wurden deine Anmeldeinformationen möglicherweise auf deinem Computer zwischengespeichert. Du kannst deine Anmeldeinformationen in der Keychain aktualisieren, um das alte Kennwort durch das Token zu ersetzen.
Statt dein personal access token manuell bei jedem Git-Vorgang mit HTTPS einzugeben, kannst du dein personal access token bei einem Git-Client zwischenspeichern. Git speichert deine Anmeldeinformationen vorübergehend im Arbeitsspeicher, bis ein Ablaufintervall abgelaufen ist. Du kannst das Token auch in einer Nur-Textdatei speichern, die Git vor jeder Anforderung lesen kann. Weitere Informationen finden Sie unter Zwischenspeichern von GitHub Anmeldeinformationen in Git.