GitHub, GitLab und Bitbucket ohne Passwort-Prompt im Terminal verbinden

Git-Repositories per SSH auschecken: SSH-Key für GitHub, GitLab & Bitbucket einrichten

SSH oder HTTPS: Welcher Weg passt?

Git unterstützt mehrere Transportwege. Für einen einzelnen Download kann HTTPS mit Git Credential Manager völlig ausreichend sein. Wenn Du jedoch regelmäßig pullst, pushst, Submodule verwendest oder mehrere Repositories betreust, ist SSH angenehm: Der private Schlüssel wird lokal geschützt und Du musst nicht bei jedem Git-Aufruf einen Token in einen Credential-Dialog eingeben.

Access Token ist kein SSH-Key

Viele Anleitungen und Fehlermeldungen mischen zwei getrennte Anmeldewege. Ein SSH-Key ist ein Dateipaar. Ein Access Token ist eine vom Anbieter erzeugte Geheimzeichenkette. Beide können Git-Zugriff geben – aber nicht auf demselben Transportweg und nicht über dieselbe Ablage.

Praktisch heißt das: Eine SSH-Remote-URL akzeptiert keinen Personal Access Token. Umgekehrt ersetzt der Public Key keinen Token in einer HTTPS-URL oder in einem REST-Aufruf. Wenn Git nach Benutzername und Passwort fragt, bist Du auf dem HTTPS-Weg – dort gehört ein Token ins Passwortfeld, nicht der Inhalt der .pub-Datei.

Was die drei Anbieter darunter verstehen

• GitHub: Personal Access Tokens gibt es als fine-grained Variante (github_pat_…) und als classic Token (ghp_…). Sie ersetzen das Kontopasswort bei Git über HTTPS und bei der API. SSH-Keys liegen unter Settings → SSH and GPG keys und sind ein getrenntes Verfahren.
• GitLab: Personal, Project und Group Access Tokens authentifizieren HTTPS und oft die API. Deploy Tokens sind für Repository und Registry gedacht, nicht für die API. Deploy Keys sind wieder SSH-Schlüssel, gebunden an ein Projekt statt an Dein Konto.
• Bitbucket Cloud: App Passwords werden abgelöst; Brownouts starteten im Juni 2026, das endgültige Ende ist für den 28. Juli 2026 angekündigt. Ersatz für HTTPS und API sind API tokens with scopes. Persönliche SSH-Keys bleiben davon unberührt.

Was ein SSH-Schlüsselpaar macht

Ein SSH-Key besteht aus zwei zusammengehörigen Dateien:

• id_ed25519 – der private Schlüssel. Er bleibt geheim und verlässt Dein Gerät nicht.
• id_ed25519.pub – der öffentliche Schlüssel. Dieser darf zum Git-Host hochgeladen werden.

Beim Verbindungsaufbau beweist Dein SSH-Client mit dem privaten Schlüssel, dass er zum hinterlegten Public Key passt. Der private Schlüssel wird dabei nicht an GitHub, GitLab oder Bitbucket übertragen. Eine Passphrase schützt ihn zusätzlich, falls die Datei kopiert wird; der Agent kann die entschlüsselte Identität für Deine Sitzung verwalten.

SSH unter Windows einrichten

Unter Windows kannst Du entweder die OpenSSH-Version von Windows in PowerShell oder die mit Git for Windows gelieferte OpenSSH-Version in Git Bash verwenden. Beide Wege sind legitim. Entscheidend ist, dass Du Key, Agent und Git möglichst in derselben Umgebung verwendest.

1. Installation und vorhandene Keys prüfen

git --version
ssh -V
Get-Command ssh
Get-ChildItem -Force "$env:USERPROFILE\.ssh" -ErrorAction SilentlyContinue

Ist der Ordner nicht vorhanden, ist das kein Fehler: Er wird häufig erst beim ersten Key angelegt. Prüfe vor der Neuerzeugung, ob schon id_ed25519, id_ed25519.pub oder ein bewusst benannter Key existiert.

2. Ed25519-Key erzeugen

Öffne PowerShell oder Git Bash und verwende einen Namen, der den Zweck beschreibt. Wenn der Ordner noch fehlt, lege ihn zuerst an:

New-Item -ItemType Directory -Force "$env:USERPROFILE\.ssh" | Out-Null
ssh-keygen -t ed25519 -C "name@example.com" -f "$env:USERPROFILE\.ssh\id_ed25519"

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -C "name@example.com" -f ~/.ssh/id_ed25519

Bestätige die Passphrase zweimal. Wenn id_ed25519 bereits existiert, überschreibe ihn nicht unüberlegt. Verwende dann einen eigenen Namen wie id_ed25519_work.

3. Dateirechte der privaten Key-Datei setzen

OpenSSH unter Windows ignoriert einen privaten Key, wenn andere Konten ihn lesen können. Das Gegenstück zu chmod 600 ist eine enge ACL nur für Dein Benutzerkonto:

$key = "$env:USERPROFILE\.ssh\id_ed25519"
icacls $key /inheritance:r
icacls $key /grant:r "$($env:USERNAME):(R)"
icacls $key

Danach sollte in der Ausgabe im Wesentlichen Dein Konto mit Leserecht stehen – nicht Everyone, nicht die komplette Benutzergruppe. Eine Meldung wie UNPROTECTED PRIVATE KEY FILE bedeutet fast immer: Die Datei ist zu offen, nicht dass der Key kryptografisch unbrauchbar wäre.

4. Windows-SSH-Agent nutzen

Mit der OpenSSH-Version von Windows kann der Agent als Windows-Dienst laufen. Die Dienst-Konfiguration erfolgt in einer als Administrator geöffneten PowerShell; den Key selbst lädst Du anschließend in einer normalen Sitzung:

Get-Service -Name ssh-agent | Set-Service -StartupType Manual
Start-Service ssh-agent
Get-Service -Name ssh-agent

ssh-add "$env:USERPROFILE\.ssh\id_ed25519"
ssh-add -l

Verwendest Du Git Bash mit der dort gebündelten OpenSSH-Version, starte stattdessen den Agent in Git Bash:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l

SSH unter Linux einrichten

Auf vielen Linux-Distributionen ist der OpenSSH-Client bereits vorhanden. Falls nicht, installiere das Paket Deiner Distribution. Danach prüfst Du Version und vorhandene Schlüssel:

git --version
ssh -V
ls -la ~/.ssh

Erzeuge einen Key mit einer sicheren Passphrase:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -C "name@example.com" -f ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Für eine laufende Shell-Sitzung startest Du den Agent und lädst den privaten Key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l

Desktop-Umgebungen können den Agent über einen Keyring starten. Trage den Startbefehl nicht gedankenlos mehrfach in .bashrc, .zshrc und .profile ein – mehrere Agenten machen die Fehlersuche eher schwerer.

SSH unter macOS einrichten

Unter macOS ist der OpenSSH-Client Teil des Systems. Der Ablauf entspricht Linux, der Agent kann die Passphrase aber zusätzlich in der Schlüsselbundverwaltung halten. So musst Du sie nicht nach jedem Neustart erneut eintippen.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -C "name@example.com" -f ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
ssh-add -l

Damit der Key nach dem Login automatisch geladen wird, ergänzt Du in ~/.ssh/config:

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

Eine allgemeine Host *-Regel gehört ans Ende der Datei. Spezifische Blöcke für GitHub, GitLab oder Bitbucket setzt Du davor, sonst gewinnt die erste zu breite Regel.

Public Key bei GitHub, GitLab und Bitbucket hinterlegen

Jetzt wird nur der öffentliche Teil kopiert. Der Inhalt beginnt typischerweise mit ssh-ed25519 und steht in genau einer Zeile. Kommentar und Zeilenende dürfen mitkopiert werden, zusätzliche Umbrüche oder abgeschnittene Zeichen nicht.

GitHub

Kopiere den Public Key und öffne anschließend in GitHub Settings → SSH and GPG keys → New SSH key. Verwende für Git-Zugriff den Typ Authentication, vergebe einen sprechenden Titel und füge die komplette Zeile ein.

# PowerShell
Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" | Set-Clipboard

# Git Bash
cat ~/.ssh/id_ed25519.pub | clip

# WSL
cat ~/.ssh/id_ed25519.pub | clip.exe

# macOS
pbcopy < ~/.ssh/id_ed25519.pub

GitHub weist darauf hin, dass DSA nicht mehr unterstützt wird und ältere RSA-Konstellationen Einschränkungen haben können. Ed25519 ist für aktuelle Clients der passende Standard.

GitLab

Öffne GitLab, wähle Dein Avatar-Menü und gehe zu Edit profile → Access → SSH keys → Add new key. Füge den Public Key ein, vergebe einen Titel und prüfe – sofern angeboten – Nutzungsart und Ablaufdatum.

# Linux mit xclip
xclip -sel clip < ~/.ssh/id_ed25519.pub

# Git Bash on Windows
cat ~/.ssh/id_ed25519.pub | clip

# WSL
cat ~/.ssh/id_ed25519.pub | clip.exe

# macOS
pbcopy < ~/.ssh/id_ed25519.pub

Ein Benutzer-Key gilt bei GitLab für alle Projekte und Gruppen, auf die Dein Konto zugreifen darf. Eine separate Datei pro Projekt ist normalerweise nicht nötig.

Bitbucket Cloud

Für den persönlichen Zugriff gehst Du zu Personal Bitbucket settings → Security → SSH keys → Add key. Label eintragen, den kompletten Inhalt der .pub-Datei in das Key-Feld kopieren und – falls gewünscht – einen Ablauf festlegen.

Bitbucket unterscheidet außerdem zwischen persönlichen SSH-Keys und Repository Access Keys. Letztere sind für Automation beziehungsweise einzelne Repositories gedacht und gewähren nur Lesezugriff. Für Deinen normalen Laptop-Workflow ist der persönliche SSH-Key die passendere Wahl.

Repository per SSH klonen

Öffne im jeweiligen Repository den Dialog Code beziehungsweise Clone, wähle SSH und kopiere die angebotene URL. Die üblichen Formen sehen so aus:

cd ~/Projekte
git clone git@github.com:OWNER/REPOSITORY.git
cd REPOSITORY
git remote -v

Bei der ersten Verbindung prüft SSH den Host-Schlüssel. Bestätige ihn nur, wenn der angezeigte Fingerabdruck zum offiziell veröffentlichten Fingerprint des Anbieters passt. GitHub, GitLab und Bitbucket bieten dafür eigene Hinweise beziehungsweise Fingerprint-Seiten an.

Vorhandenes HTTPS-Repository auf SSH umstellen

Du musst nicht neu klonen, wenn das Repository schon lokal liegt. Ersetze nur die Remote-URL:

git remote -v
git remote set-url origin git@github.com:OWNER/REPOSITORY.git
git remote -v
git fetch

git remote set-url origin git@ssh.bitbucket.org:WORKSPACE/REPOSITORY.git
git remote -v
git fetch

Für GitLab ersetzt Du Host und Pfad durch die vom Repository kopierte SSH-URL. Git dokumentiert sowohl die ssh://-Form als auch die verbreitete SCP-ähnliche Form git@host:pfad.

Mehrere Keys und abweichende Ablageorte

Ein eigener Dateiname pro Anbieter oder Arbeitskontext hilft, wenn Du mehrere Konten, Firmeninstanzen oder getrennte Sicherheitsbereiche verwendest. Der SSH-Client kann anhand des Hosts die passende Identität wählen.

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

Host gitlab.com
  User git
  IdentityFile ~/.ssh/id_ed25519_gitlab
  IdentitiesOnly yes

Host bitbucket.org ssh.bitbucket.org
  HostName ssh.bitbucket.org
  User git
  IdentityFile ~/.ssh/id_ed25519_bitbucket
  IdentitiesOnly yes

Die Datei liegt unter Linux und macOS normalerweise in ~/.ssh/config; der Windows-OpenSSH-Client liest standardmäßig %USERPROFILE%\.ssh\config. Unter Windows darf der Pfad in der Datei auch mit ~/.ssh/... geschrieben werden. Der Bitbucket-Block fängt sowohl alte als auch neue Hostnamen ein und leitet sie auf ssh.bitbucket.org.

printf 'HOME=%s\n' "$HOME"
ssh -G github.com | grep -Ei 'identityfile|userknownhostsfile|globalknownhostsfile'

$env:USERPROFILE
$env:HOME
ssh -G github.com | Select-String 'identityfile|userknownhostsfile|globalknownhostsfile'

Weitere Schlüsselpaare anlegen, ohne vorhandene zu überschreiben

Ein neues Schlüsselpaar beschädigt die alten Keys nicht – gefährlich wird es nur, wenn Du dieselben Dateinamen verwendest oder eine bestehende config unkontrolliert überschreibst. Arbeite deshalb mit einem Namensschema, zum Beispiel id_ed25519_github_personal, id_ed25519_github_work und id_ed25519_gitlab.

# Git Bash / Linux / macOS
ssh-keygen -t ed25519 -C "privat@example.com" -f ~/.ssh/id_ed25519_github_personal
ssh-keygen -t ed25519 -C "arbeit@example.com" -f ~/.ssh/id_ed25519_github_work

# Fingerprints vergleichen
ssh-keygen -lf ~/.ssh/id_ed25519_github_personal.pub
ssh-keygen -lf ~/.ssh/id_ed25519_github_work.pub

Die beiden Paare liegen nebeneinander: Jeweils die Datei ohne Endung ist privat, die gleichnamige Datei mit .pub ist öffentlich. Bestehende Keys bleiben unangetastet. Beim Hinzufügen zeigt ssh-keygen normalerweise eine Warnung, falls der angegebene Dateiname bereits vorhanden ist – bestätige ein Überschreiben nur dann, wenn Du den alten Key bewusst ersetzen möchtest.

Den SSH-Agent sauber verwalten

Der Agent ist nur ein Zwischenspeicher für private Schlüssel in Deiner laufenden Umgebung. Er ist nicht dasselbe wie die Dateiablage und auch nicht dasselbe wie known_hosts. Prüfe vor Änderungen, welche Identitäten geladen sind:

ssh-add -l

# Einen einzelnen Key entfernen
ssh-add -d ~/.ssh/id_ed25519_github_work

# Nur im Notfall: alle geladenen Keys aus diesem Agent entfernen
ssh-add -D

ssh-add -D löscht keine Dateien und entfernt auch keinen Public Key beim Anbieter – es leert nur den Agent. Danach musst Du die benötigten privaten Keys erneut mit ssh-add laden. Für mehrere Identitäten ist IdentitiesOnly yes in der passenden Host-Regel besonders hilfreich, weil dann nicht versehentlich der zuerst angebotene falsche Key verwendet wird.

Mehrere Konten beim selben Host: Host-Aliase verwenden

Ein Hostname allein reicht nicht aus, um zwei Konten bei demselben Anbieter zu unterscheiden. Zwei getrennte Host github.com-Blöcke sind deshalb keine gute Lösung. Verwende Aliase: Host ist der Name, den Git in der Remote-URL sieht; HostName bleibt der echte Server.

# Persönliches Konto
Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github_personal
  IdentitiesOnly yes

# Arbeitskonto
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github_work
  IdentitiesOnly yes

Die Remote-URL muss dann den Alias enthalten:

git clone git@github-personal:OWNER/REPOSITORY.git
git remote set-url origin git@github-work:ORGANIZATION/REPOSITORY.git

Dasselbe Muster funktioniert für mehrere GitLab-Konten auf einer Instanz und für mehrere Bitbucket-Cloud-Konten. Für Bitbucket setzt Du HostName ssh.bitbucket.org. Nach dem Einrichten testest Du jeden Alias einzeln:

ssh -T git@github-personal
ssh -T git@github-work
ssh -G github-work | grep -Ei 'hostname|identityfile|identitiesonly|userknownhostsfile'

Bei Bitbucket ist dieses Vorgehen besonders wichtig: Wenn mehrere Keys im Agent liegen, kann sonst ein gültiger, aber für das gewünschte Konto falscher Key zuerst angeboten werden. Das Ergebnis sieht dann schnell wie ein fehlendes Repository oder eine falsche Berechtigung aus.

Was config und known_hosts jeweils machen

known_hosts: nicht mit den Benutzer-Keys verwechseln

known_hosts speichert die Identität des Servers, zum Beispiel von github.com, gitlab.com oder ssh.bitbucket.org. Die Datei entscheidet nicht, mit welchem Benutzerkonto Du Dich authentifizierst. Dafür sind private Key, Public Key, Agent und config zuständig.

Normalerweise teilen sich alle Deine Host-Aliase dieselbe known_hosts-Datei der aktiven SSH-Umgebung. Du brauchst also nicht für jedes Schlüsselpaar eine neue Datei. Unter Windows ist der Standardpfad des OpenSSH-Clients %USERPROFILE%\.ssh\known_hosts; Git Bash, WSL und macOS können jeweils eigene Home-Verzeichnisse und damit eigene Dateien verwenden.

# Eintrag suchen
ssh-keygen -F github.com -f ~/.ssh/known_hosts
ssh-keygen -F ssh.bitbucket.org -f ~/.ssh/known_hosts

# Effektive Datei für einen Alias anzeigen
ssh -G github-work | grep -Ei 'hostname|userknownhostsfile'

Eine Warnung wie REMOTE HOST IDENTIFICATION HAS CHANGED bedeutet nicht automatisch, dass Du nur den Eintrag löschen musst. Prüfe zuerst, ob der Fingerprint beim Anbieter oder beim zuständigen Administrator geändert wurde. Erst wenn die Änderung verifiziert ist, kann ein einzelner alter Eintrag gezielt mit ssh-keygen -R github.com beziehungsweise dem verwendeten Alias entfernt und anschließend neu gelernt werden. Die komplette Datei zu löschen oder die Host-Key-Prüfung abzuschalten, ist keine gute Reparaturstrategie.

Die sichere Änderungsroutine

1. Vor einer Änderung eine Kopie von config und known_hosts an einem geschützten Ort anlegen.
2. Neue Keypaare immer mit neuem Dateinamen erstellen; vorhandene Dateien nicht überschreiben.
3. Neue Host-Blöcke eindeutig kommentieren und spezifische Regeln vor allgemeine Host *-Regeln setzen.
4. Mit ssh -G alias kontrollieren, welcher Host, Key und welche known_hosts-Datei effektiv verwendet werden.
5. Jeden Alias mit ssh -T testen und erst danach die Git-Remote-URL ändern.

Typische Fehler systematisch lösen

Für die Fehlersuche ist -v hilfreich, weil SSH dann zeigt, welche Konfiguration und welche Schlüsseldateien verwendet werden. Die Ausgabe kann sensible Pfade und Hostnamen enthalten – teile sie nicht ungeprüft öffentlich.

Häufige Fragen