GitHub- & GitLab-SSH-Schlüssel funktioniert nicht? Die Lösung Schritt für Schritt

Ein SSH-Schlüssel, der sich nicht bei GitHub oder GitLab authentifizieren will, ist eines der meistgegoogelten Entwicklerprobleme überhaupt, und in der Hälfte der Fälle ist der Schlüssel in Ordnung – nur die Diagnose ist falsch. Bevor du also irgendetwas neu erzeugst, führ einen Test aus und lern, seine Antwort zu lesen. Arbeite dann die Übeltäter in der Reihenfolge ab, wie oft sie wirklich die Ursache sind.

„You’ve successfully authenticated, but GitHub does not provide shell access“

Wenn du diese Zeile zurückbekommen hast, halt – dein Schlüssel funktioniert bereits. GitHub und GitLab geben dir keine Shell; sie sprechen nur git über SSH, authentifizieren dich also und legen sofort auf, und „does not provide shell access“ ist genau das, was sie dir sagen, kein Fehler. GitLabs Formulierung ist etwas anders (Welcome to GitLab, @you!), bedeutet aber dasselbe. Wenn dein Schlüssel funktioniert, git push aber trotzdem nach einem Passwort fragt, war der Schlüssel nie das Problem – spring zum HTTPS-Remote-Übeltäter weiter unten, die übliche echte Ursache.

Schritt 0: der Test, der dir sagt, ob überhaupt etwas kaputt ist

Frag den Git-Host direkt, ob er deinen Schlüssel erkennt:

ssh -T git@github.com        # GitHub
ssh -T git@gitlab.com        # GitLab

Lies die Antwort jetzt aufmerksam, denn die Erfolgsmeldung sieht aus wie ein Fehler:

Hi <username>! You've successfully authenticated, but GitHub does not
provide shell access.

Das ist Erfolg. „Does not provide shell access“ ist kein Fehlschlag – GitHub und GitLab geben dir keine Shell, sie sprechen nur git über SSH, authentifizieren dich also und legen dann auf. Leute sehen „does not provide“ und fangen an, ein funktionierendes Setup zu reparieren. Wenn du deinen Benutzernamen in dieser Zeile siehst, funktioniert dein Schlüssel; dein Problem liegt woanders (spring zum HTTPS-Remote-Übeltäter weiter unten – das ist die übliche echte Ursache).

Der echte Fehlschlag sieht stattdessen so aus:

git@github.com: Permission denied (publickey).

Den sind wir hier, um zu beheben. Beachte den Endpunkt: Permission denied (publickey) heißt, der Server hat keinen von dir angebotenen Schlüssel akzeptiert. Arbeite die Liste durch.

Übeltäter 1: der Schlüssel ist nicht in deinem Konto hinterlegt

Die häufigste echte Ursache. Ein Schlüssel auf deinem Laptop tut nichts, solange nicht seine öffentliche Hälfte beim Git-Host hinterlegt ist. Kopiere den öffentlichen Schlüssel:

cat ~/.ssh/id_ed25519.pub     # note the .pub — this is the safe half to share

Füge das ein unter GitHub → Settings → SSH and GPG keys → New SSH key oder GitLab → Preferences → SSH Keys.

Eine Regel, keine Ausnahmen: Füge die .pub-Datei ein, niemals die Datei ohne .pub. Der öffentliche Schlüssel ist eine Zeile, die mit ssh-ed25519 AAAA… (oder ssh-rsa AAAA…) beginnt. Wenn das, was du gleich einfügst, mit -----BEGIN OPENSSH PRIVATE KEY----- beginnt, halt – das ist dein privater Schlüssel, das Geheimnis, das deine Identität ist. Es in ein Webformular einzufügen, übergibt deine Zugangsdaten jedem, der diese Seite lesen kann. Teile die öffentliche Hälfte; hüte die private.

(Noch kein Schlüssel? Erzeug einen – Ed25519 in fast allen Fällen (auf Englisch): ssh-keygen -t ed25519 -C "you@device".)

Übeltäter 2: der falsche Schlüssel wird angeboten

Dein Schlüssel ist hinterlegt, aber SSH bietet einen anderen an – häufig, wenn du mehrere Schlüssel dabei hast und der Agent sie in einer Reihenfolge probiert, die der Server ablehnt. Sieh genau, welcher Schlüssel gesendet wird:

ssh -vT git@github.com

Halte nach den Zeilen Offering public key: Ausschau. Wenn der hinterlegte Schlüssel nicht dabei ist oder ein falscher akzeptiert wird, lege den richtigen Schlüssel pro Host in ~/.ssh/config fest:

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

IdentitiesOnly yes ist die entscheidende Zeile – sie sagt SSH, nur die IdentityFile anzubieten, die du genannt hast, und aufzuhören, jeden Schlüssel aus deinem Agenten auf den Server abzufeuern (das kuriert auch Too many authentication failures). Mach dasselbe mit Host gitlab.com für GitLab. Mehr zum Aufbau der Datei im ssh_config-Leitfaden (auf Englisch).

Übeltäter 3: der Agent läuft nicht, oder der Schlüssel ist nicht geladen

Wenn dein Schlüssel eine Passphrase hat und der Agent sie nicht hält, überspringt SSH ihn womöglich stillschweigend. Prüfe, was der Agent hat:

ssh-add -l

The agent has no identities (oder Could not open a connection to your authentication agent) heißt, du musst ihn starten und den Schlüssel laden:

eval "$(ssh-agent -s)"        # start the agent in this shell
ssh-add ~/.ssh/id_ed25519     # load the key (prompts for the passphrase once)

ssh-add -l sollte jetzt den Fingerabdruck deines Schlüssels auflisten. (Was der Agent eigentlich ist und wie er Schlüssel hält, steht in Was ist der SSH-Agent (auf Englisch).)

Übeltäter 4: du bist auf einem HTTPS-Remote, nicht auf einem SSH-Remote

Das ist der Übeltäter hinter „mein Schlüssel funktioniert (ssh -T hat geklappt), aber git push fragt trotzdem nach einem Passwort“. Dein Repository ist auf HTTPS konfiguriert, das SSH-Schlüssel komplett ignoriert und einen Token will. Prüfe:

git remote -v

Wenn du https://github.com/you/repo.git siehst, ist das das Problem – HTTPS fasst deinen SSH-Schlüssel nie an. Stell das Remote auf SSH um:

git remote set-url origin git@github.com:you/repo.git      # GitHub
git remote set-url origin git@gitlab.com:you/repo.git      # GitLab

Führ git remote -v erneut aus, um zu bestätigen, dass es jetzt mit git@ beginnt. Diese eine Korrektur löst einen riesigen Anteil der „SSH-Schlüssel geht nicht“-Meldungen, bei denen der Schlüssel die ganze Zeit in Ordnung war.

Übeltäter 5: Berechtigungen auf ~/.ssh

SSH weigert sich, Schlüssel und Config zu nutzen, an denen andere herumpfuschen könnten. Wenn die ausführliche Ausgabe schlechte Modi erwähnt oder Schlüssel ohne klaren Grund ignoriert werden:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519          # private key
chmod 644 ~/.ssh/id_ed25519.pub      # public key
chmod 600 ~/.ssh/config

Unter Windows taucht das nach dem Kopieren von Schlüsseln von einem synchronisierten Laufwerk oder zwischen Maschinen auf; behebe es über die Sicherheitseigenschaften der Datei oder halte Schlüssel aus Cloud-synchronisierten Ordnern heraus.

Übeltäter 6: jedes Mal eine Passphrase-Abfrage

Wenn jede git-Operation deine Schlüssel-Passphrase verlangt, speichert der Agent sie nicht zwischen. Lade sie einmal mit ssh-add (auf Englisch) (Übeltäter 3) und mach sie sitzungsübergreifend dauerhaft, indem du in ~/.ssh/config ergänzt:

Host github.com gitlab.com
    AddKeysToAgent yes

Unter macOS legt ssh-add --apple-use-keychain ~/.ssh/id_ed25519 die Passphrase im Schlüsselbund ab, sodass sie Neustarts übersteht.

Übeltäter 7: zwei Konten, ein Host

Dienstliches und privates GitHub-Konto können sich keinen Schlüssel teilen – ein gegebener öffentlicher Schlüssel gehört zu genau einem Konto. Gib jedem seinen eigenen Schlüssel und einen Host-Alias, der ihn auswählt:

Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/work_ed25519
    IdentitiesOnly yes

Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/personal_ed25519
    IdentitiesOnly yes

Dann klone oder setze das Remote mit dem Alias als Host: git@github-work:org/repo.git. SSH trifft auf github-work, wählt den Dienst-Schlüssel und schreibt die Verbindung im Hintergrund auf github.com um.

Übeltäter 8: Organisations-SSO nicht autorisiert (GitHub)

Du authentifizierst dich einwandfrei bei deinen eigenen Repos, bekommst aber Permission denied bei den Repos einer Organisation hinter SAML-SSO. Der Schlüssel existiert, ist aber für diese Organisation nicht autorisiert. Geh zu Settings → SSH and GPG keys, such den Schlüssel, klick auf Configure SSO und autorisiere ihn für die Organisation. GitLab hat einen parallelen Fall, in dem ein abgelaufener Schlüssel stillschweigend abgelehnt wird – prüfe das Ablaufdatum des Schlüssels unter SSH Keys, wenn ein zuvor funktionierender Schlüssel plötzlich streikt.

Wenn es immer noch Permission denied (publickey) ist

Wenn du die Liste durchgearbeitet hast und immer noch auf den Endpunkt stößt, hast du es auf ein echtes Problem der Schlüsselannahme eingegrenzt – die systematische Schleife für genau diesen Fehler (das Lesen von ssh -vvv, die Methodenliste des Servers, angebotene vs. akzeptierte Schlüssel) steht in Permission denied (publickey), eine schnelle systematische Lösung (auf Englisch), und die breitere Karte der SSH-Fehler in SSH-Fehler entschlüsselt. Aber speziell für Git-Hosts fängt die obige Reihenfolge fast alles ab: den öffentlichen Schlüssel hinterlegen, den richtigen anbieten, ihn in den Agenten laden und sicherstellen, dass du wirklich auf einem SSH-Remote bist.

Wo ein Client die Einrichtung ganz überflüssig macht

Das meiste an dieser Reiberei ist Buchhaltung – welcher Schlüssel zu welchem Host gehört, ob er geladen ist, ob das Remote überhaupt SSH ist. Termalin hält den Schlüssel bei dem Host, zu dem er gehört, entsperrt deine Schlüssel einmal über einen eingebauten Agenten, sodass Passphrasen nicht neu getippt werden (und eine abgebrochene Abfrage überspringt nie stillschweigend einen Schlüssel), und – weil es das Standard-ssh-agent-Protokoll spricht – können git und dein CLI über denselben Agenten signieren. Fingerabdrücke sind pro Schlüssel sichtbar, das Hinterlegen der richtigen öffentlichen Hälfte bei GitHub oder GitLab ist also Kopieren und Einfügen statt einer Suche durch fünf ~/.ssh-Ordner. Das Jonglieren mit Konten und Aliassen von oben wird zu einer Einstellung pro Host statt zu einem Rätsel in einer Config-Datei.

---

Termalin ist ein kostenloser, plattformübergreifender SSH-Client, der deine Schlüssel mit einem Einmal-entsperren-Agenten verwaltet, über den git signieren kann – lade es herunter oder lies, wie es Schlüssel sicher verwahrt.