git push scheitert auf dem Remote-Mac mit „Permission denied“ oder fordert wiederholt eine Passphrase an.
Schnellste Lösung: Stellen Sie zuerst fest, auf welchem Gerät der Git-Befehl tatsächlich läuft; prüfen Sie anschließend genau dort Schlüssel, Agent und Repository-Rechte. Kopieren Sie keinen privaten Schlüssel auf ein iPad, einen fremden Rechner oder einen gemeinsam genutzten Host, dessen Bereinigung Sie nicht kontrollieren.

Dieser Leitfaden richtet sich an unabhängige Entwickler, die unterwegs per Remote-Mac an Git-Projekten arbeiten und an einer GitHub-SSH-Anmeldung scheitern.
Er passt auch zu digitalen Nomaden, die zwischen iPad, leichtem Notebook und Remote-Mac wechseln.
Wenn Sie temporäre Umgebungen nutzen oder später einen Schlüssel widerrufen müssen, finden Sie hier eine nachvollziehbare Prüfreihenfolge.

GitHub-SSH-Authentifizierung: Terminal auf dem Remote-Mac oder auf dem Reisegerät?

Bei einer SSH-Fehlermeldung ist zuerst der tatsächliche Ausführungsort entscheidend. Ein Terminalfenster auf Ihrem iPad und ein Terminalfenster, das Sie innerhalb einer Remote-Mac-Sitzung öffnen, verwenden nicht automatisch dieselben Dateien, Benutzerkonten oder laufenden SSH-Agenten. Richten Sie den GitHub-Schlüssel daher auf dem Gerät ein, auf dem Git den Zugriff ausführt.

Eine Remote-Desktop-Verbindung und eine GitHub-Verbindung sind zwei getrennte Verbindungen. Ihr iPad kann den Bildschirm eines Mac anzeigen, während Git im Terminal dieses Mac ausgeführt wird. Umgekehrt kann eine Terminal-App auf dem iPad einen Befehl lokal starten, selbst wenn daneben eine Remote-Sitzung geöffnet ist. Apple beschreibt Remote Login als Zugriff auf einen Mac über SSH oder SFTP; das sagt noch nichts darüber aus, auf welchem Rechner ein zusätzlich geöffnetes Terminal läuft oder ob GitHub-Zugangsdaten dort vorhanden sind (Apple: Remote Login auf dem Mac).

Prüfen Sie direkt vor dem fehlgeschlagenen Git-Befehl:

hostname
whoami
pwd
git remote -v

Der Hostname und der Benutzername zeigen, in welcher Shell Sie arbeiten. git remote -v zeigt, welche Adresse das Repository für Abruf und Übertragung verwendet. Wenn dort eine SSH-Adresse zu sehen ist, vergleichen Sie sie mit dem Repository, auf das Sie zugreifen möchten. Geben Sie die Ausgabe nicht unbesehen in öffentliche Chats weiter: Repository-Adressen können interne Namen oder Organisationsdetails enthalten.

Wo sollte der private GitHub-Schlüssel liegen, wenn Git auf dem Remote-Mac läuft?
Auf dem vertrauenswürdigen Ausführungsgerät, also in diesem Fall auf dem Remote-Mac, sofern Sie dessen Konto, Zugriff und Bereinigung kontrollieren können. Der Schlüssel muss nicht zusätzlich auf dem iPad liegen, nur weil Sie den Mac von dort bedienen. GitHub erklärt, dass SSH für Git-Operationen verwendet wird und der öffentliche Schlüssel dem GitHub-Konto hinzugefügt werden muss; der private Schlüssel bleibt bei Ihnen (GitHub: SSH-Authentifizierung für Git).

Fehlerbild statt Vermutung: Schlüssel, Konto, Repository oder Verbindung?

Nicht jede fehlgeschlagene Anmeldung ist ein Netzwerkproblem. Trennen Sie vier Ebenen, bevor Sie Einstellungen ändern: Erreicht die SSH-Verbindung den Dienst? Wird ein angebotener Schlüssel erkannt? Ordnet GitHub ihn dem erwarteten Konto zu? Darf dieses Konto auf das konkrete Repository zugreifen? So vermeiden Sie, einen funktionierenden Schlüssel wegen eines fehlenden Organisationsrechts neu anzulegen.

Beobachtung Wahrscheinliche Ebene Nächster Prüfschritt
SSH-Verbindung bricht ab, bevor eine GitHub-Begrüßung erscheint Verbindung, Netzweg oder SSH-Konfiguration SSH-Test aus derselben Shell wiederholen und die offizielle SSH-Fehlerbehebung abgleichen
GitHub bestätigt eine Anmeldung, aber ein Repository lässt sich nicht lesen Repository-Adresse, Konto oder Zugriffsrecht Kontoidentität und Repository-Berechtigung getrennt prüfen
Permission denied (publickey) erscheint Schlüssel wird nicht angeboten oder nicht akzeptiert Schlüsseldatei, SSH-Konfiguration und ssh-agent auf dem ausführenden Gerät prüfen
Abruf funktioniert, aber Übertragung wird abgelehnt Schreibrecht oder Organisationsrichtlinie Schreibberechtigung und Richtlinien für das konkrete Repository kontrollieren

Die zuverlässige Gegenprobe ist der SSH-Test aus genau dem Terminal, in dem Git später laufen soll:

ssh -T git@github.com

GitHub dokumentiert diesen Test und die dabei erwartete Authentifizierungsbestätigung. Eine erfolgreiche Zuordnung bestätigt, welches Konto der Schlüssel repräsentiert; sie beweist nicht, dass dieses Konto jedes beliebige Repository lesen oder verändern darf (GitHub: SSH-Verbindung testen). Vergleichen Sie das bestätigte Konto mit dem Konto, das Zugriff auf das fragliche Projekt erhalten soll.

Wie unterscheiden Sie einen Schlüssel- oder Berechtigungsfehler von einem Netzwerkproblem?
Beginnen Sie mit ssh -T und beachten Sie die konkrete Ausgabe. Erreicht der Test GitHub und meldet eine erfolgreiche Authentifizierung, liegt ein anschließendes Problem beim Klonen oder Übertragen eher bei Repository-Adresse, Konto- oder Schreibrechten als bei der SSH-Schlüsselzuordnung. Scheitert schon der SSH-Aufbau, prüfen Sie zusätzlich die Netzverbindung und die SSH-Diagnose. GitHub trennt diese Fälle in seiner SSH-Fehlerbehebung und den Hinweisen zu Fehlern beim Klonen von Repositories.

Erster Prüfpunkt: vorhandene Schlüssel finden, bevor Sie neue erzeugen

Bevor Sie eine Datei erstellen, prüfen Sie, ob auf dem ausführenden Mac bereits ein passender Schlüssel vorhanden ist. Legen Sie sich nicht vorschnell einen neuen Schlüssel an und überschreiben Sie keine bestehende Datei. Ein vorhandener Schlüssel kann für ein anderes Konto, einen anderen Git-Dienst oder einen getrennten Arbeitskontext verwendet werden.

GitHub beschreibt, wie Sie vorhandene SSH-Schlüssel auf macOS überprüfen. Beginnen Sie mit den Dateien im SSH-Verzeichnis und identifizieren Sie öffentliche Schlüssel an der Dateiendung .pub; der private Schlüssel hat diese Endung nicht. Öffentliche Schlüssel dürfen in Ihrem GitHub-Konto hinterlegt werden. Den Inhalt eines privaten Schlüssels sollten Sie weder hier noch in einer Supportanfrage oder in einem geteilten Protokoll veröffentlichen (GitHub: vorhandene SSH-Schlüssel prüfen).

Prüfen Sie anschließend, ob die SSH-Konfiguration den erwarteten Schlüssel anspricht. Ein häufiger Stolperstein ist, dass eine Konfiguration auf einen anderen Dateinamen oder ein anderes Benutzerverzeichnis verweist. Sie können die angebotenen Identitäten mit folgendem Befehl anzeigen:

ssh-add -l

Eine leere oder unerwartete Liste beweist für sich genommen nicht, dass keine Schlüsseldatei existiert. Sie zeigt aber, dass der Agent in dieser Sitzung keine passende Identität meldet. Prüfen Sie daher sowohl die Dateien als auch den Agenten und die verwendete SSH-Konfiguration, bevor Sie Änderungen vornehmen.

Wenn kein geeigneter Schlüssel existiert, erstellen Sie einen neuen, eindeutig zuordenbaren Schlüssel und fügen Sie den öffentlichen Teil Ihrem GitHub-Konto hinzu. Folgen Sie dabei der offiziellen Anleitung zum Erzeugen eines SSH-Schlüssels und Hinzufügen zum ssh-agent sowie zur Registrierung eines neuen öffentlichen Schlüssels. Geben Sie niemals den privaten Schlüssel an GitHub weiter.

Wichtig: SSH-Agent-Weiterleitung ist keine pauschale Sicherheitslösung. Sie kann verhindern, dass ein privater Schlüssel direkt auf einem entfernten Host gespeichert wird, ändert aber die Vertrauensgrenzen der Sitzung. Verwenden Sie sie nur, wenn Sie den verbundenen Host, die Zugangsmethode und die geltenden Organisationsregeln geprüft haben.

Wiederholte Passphrase-Abfrage: Agent und Schlüsselbund getrennt prüfen

Eine Passphrase schützt den privaten SSH-Schlüssel. Sie ist nicht Ihr GitHub-Kontopasswort und auch nicht das Passwort, mit dem Sie sich am Remote-Mac anmelden. Diese drei Zugangsdaten haben verschiedene Aufgaben. Wenn Sie sie verwechseln, reagieren Sie womöglich mit einer Änderung am falschen Konto oder speichern ein Geheimnis an einer ungeeigneten Stelle.

Wird die Passphrase nach einer neuen Shell, einer getrennten Remote-Sitzung oder einem Neustart erneut verlangt, prüfen Sie zuerst, ob die aktuelle Sitzung den richtigen Agenten verwendet und ob dieser den Schlüssel geladen hat. Der Zustand einer Sitzung kann nach dem Trennen der Verbindung anders sein als zuvor. Versprechen Sie sich deshalb nicht, dass eine gespeicherte Passphrase nach jedem Sitzungsende automatisch verfügbar bleibt.

Unter macOS kann der Schlüsselbund in Verbindung mit ssh-agent die Passphrase-Verwaltung unterstützen. GitHub dokumentiert die dazugehörige Einrichtung für macOS in seiner Anleitung zur Schlüsselerzeugung und Agent-Konfiguration. Prüfen Sie die dort beschriebenen Einstellungen für Ihre Systemversion, anstatt Konfigurationszeilen aus einem fremden Rechner zu übernehmen. Testen Sie danach erneut mit ssh-add -l und ssh -T git@github.com. Wenn die Anmeldung funktioniert, aber nach einer erneuten Verbindung wieder scheitert, dokumentieren Sie, ob der Agent neu gestartet wurde oder die Sitzung gewechselt hat.

Warum verlangt GitHub nach einem Sitzungsabbruch erneut die Passphrase?
Oft ist der Schlüssel zwar vorhanden, aber in der neuen Sitzung nicht im Agenten geladen; möglich ist auch, dass die macOS-Schlüsselbundkonfiguration nicht wie erwartet greift. Ermitteln Sie zuerst, ob sich Benutzerkonto und Ausführungsgerät geändert haben. Laden Sie nicht blind denselben Schlüssel in mehrere Umgebungen, sondern prüfen Sie die offizielle Agent-Anleitung und wiederholen Sie den SSH-Test im tatsächlich verwendeten Terminal.

Zweiter Prüfpunkt: temporäre Arbeitsumgebung und Widerruf

Die passende Ablage hängt davon ab, wem das Gerät gehört und wer es nach Ihrer Sitzung kontrolliert. Auf einem eigenen, abgesicherten Remote-Mac können Sie einen dedizierten Arbeitsschlüssel verwalten, sofern Sie Zugriff und Bereinigung zuverlässig kontrollieren. Auf einem geliehenen Notebook, einem öffentlich zugänglichen Rechner oder einem gemeinsam genutzten Host ist das Risiko anders gelagert: Andere Nutzer oder Administratoren können Zugriff auf Dateien, Sitzungen oder Protokolle haben. Daraus folgt nicht automatisch, dass ein bestimmter Host unsicher ist; Sie müssen aber dessen Verwaltungs- und Zugriffsgrenzen kennen.

Wenn Sie nicht nachvollziehen können, wer den Schlüssel lesen kann oder wie er nach Ende der Arbeit entfernt wird, verwenden Sie dort keinen privaten Schlüssel. Prüfen Sie stattdessen, ob eine alternative Authentifizierung zulässig und für Ihr Konto sowie die Organisationsrichtlinien geeignet ist. Wenn keine sichere, genehmigte Alternative bereitsteht, verschieben Sie die Git-Operation, bis Sie eine kontrollierbare Umgebung haben.

Wie widerrufen Sie einen Schlüssel von einem temporären oder gemeinsam genutzten Mac?
Melden Sie sich bei dem GitHub-Konto an, dem der zugehörige öffentliche Schlüssel hinzugefügt wurde, identifizieren Sie den Eintrag anhand seines Namens und entfernen Sie ihn, wenn er nicht mehr gebraucht wird oder ein Verdacht auf Offenlegung besteht. GitHub beschreibt die Prüfung und das Löschen registrierter SSH-Schlüssel in der Anleitung zum Überprüfen Ihrer SSH-Schlüssel. Danach verwenden Sie für weitere Arbeit einen neuen, getrennt verwalteten Schlüssel. Entfernen Sie außerdem lokale Kopien und Agent-Einträge, soweit Sie die jeweilige Umgebung kontrollieren können.

Die Entfernung des öffentlichen Schlüssels aus dem Konto ist der entscheidende Widerrufsschritt für die GitHub-Zuordnung. Sie sollten trotzdem nicht annehmen, damit seien alle Kopien des privaten Schlüssels auf jedem Gerät gelöscht. Notieren Sie, wo Sie den Schlüssel eingesetzt haben, und prüfen Sie jedes dieser Geräte separat. Für Organisationskonten gelten gegebenenfalls zusätzliche interne Melde- oder Freigabewege.

Abnahme vor der Weiterreise: lesen, schreiben und Rückweg testen

Nach der Fehlerbehebung reicht es nicht, nur zu sehen, dass die SSH-Verbindung funktioniert. Testen Sie mit einem Repository, auf das Ihr Konto tatsächlich zugreifen darf. Ein erfolgreicher Authentifizierungstest und die Berechtigung für ein einzelnes Projekt beantworten unterschiedliche Fragen. Halten Sie außerdem fest, auf welchem Gerät der Befehl ausgeführt wurde, welcher Schlüssel verwendet wird und wie Sie diesen bei Verlust oder Verdacht auf Offenlegung widerrufen.

Gehen Sie diese Liste in der Arbeitsumgebung durch:

  • [ ] hostname und whoami notiert und bestätigt, dass das Terminal auf dem vorgesehenen Mac läuft.
  • [ ] Mit git remote -v geprüft, dass die Repository-Adresse zum gewünschten Projekt gehört.
  • [ ] Vorhandene Schlüssel geprüft, bevor Sie einen neuen Schlüssel erstellt haben.
  • [ ] Bestätigt, dass die SSH-Konfiguration und ssh-agent den beabsichtigten Schlüssel verwenden.
  • [ ] ssh -T git@github.com ausgeführt und das erkannte GitHub-Konto mit dem erwarteten Konto abgeglichen.
  • [ ] Einen Abruf aus einem Repository ausgeführt, für das Sie Leserechte besitzen.
  • [ ] Eine Schreiboperation nur dann geprüft, wenn Sie tatsächlich Schreibrechte haben und der Test dem Projektablauf entspricht.
  • [ ] Dokumentiert, wo der private Schlüssel liegt, wer auf diese Umgebung zugreifen kann und wie Sie den Schlüssel im GitHub-Konto widerrufen.
  • [ ] Nach dem Trennen und Wiederverbinden geprüft, ob der Agent-Zustand erhalten bleibt oder der Schlüssel erneut geladen werden muss.

Diese Abnahme ist besonders wichtig, wenn Sie unterwegs zwischen lokalem Gerät und Remote-Mac wechseln. Ohne dokumentierten Ausführungsort kann dieselbe Fehlermeldung nach einem Gerätewechsel erneut auftreten, obwohl Sie die erste Umgebung korrekt eingerichtet haben. Speichern Sie in Ihrer Notiz keine privaten Schlüssel oder Passphrasen. Halten Sie nur die für die Wiederherstellung nötigen Informationen fest, etwa Gerätename, verwendetes Konto, Repository-Zugriff und Widerrufspfad.

Für die Arbeitsumgebung selbst sollten Sie außerdem den Zweck der Verbindung von der Kontrolle über GitHub trennen. Apple dokumentiert Remote Login als Funktion für SSH- oder SFTP-Zugriff auf einen Mac; ob ein konkreter Remote-Mac für Ihre fortlaufende Arbeit geeignet ist, hängt zusätzlich von Zugangsschutz, Benutzertrennung, Freigaben und den geltenden Datenschutz- und Organisationsregeln ab. Aus einer erfolgreichen Verbindung lässt sich keine Aussage über die Verwaltung eines bestimmten Anbieters ableiten.

Entscheidung unterwegs: lokaler Rechner oder Remote-Mac?

Wenn Git ausschließlich lokal auf Ihrem iPad oder Notebook läuft, gehört die Schlüsselprüfung zu genau diesem Gerät. Das kann für kurze, einfache Änderungen genügen; die macOS-Entwicklungsumgebung des Remote-Mac wird dadurch aber nicht automatisch für lokale Befehle genutzt. Läuft Git dagegen auf dem Remote-Mac, vermeiden Sie eine unnötige Kopie des privaten Schlüssels auf das Reisegerät. Dafür müssen Sie sicherstellen, dass der Remote-Mac selbst ein kontrollierbarer Speicher- und Ausführungsort ist.

Der lokale Weg kann bei Gerätewechseln zu auseinanderlaufenden Schlüsseln und Konfigurationen führen. Ein temporärer gemeinsam genutzter Host wirft zusätzliche Fragen zur Bereinigung und zu weiteren Zugriffen auf. Ein Remote-Mac kann eine beständige macOS-Arbeitsumgebung bereitstellen, ist aber nicht automatisch die richtige Wahl, wenn Sie dessen Kontentrennung, Schlüsselverwaltung oder Wiederherstellung nicht prüfen können. Bei einem längeren, gleichbleibenden Arbeitsbedarf oder bei Anforderungen an physische Schnittstellen kann ein eigener Mac die passendere Lösung sein.

Wenn Sie eine Remote-Mac-Umgebung erwägen, klären Sie vor dem Einsatz, wie Sie darauf zugreifen und welche Berechtigungs- und Verwaltungsgrenzen tatsächlich gelten. Informationen zu den verfügbaren Optionen finden Sie auf der VMSPIN-Übersicht und in der Übersicht zu den Mietoptionen. Prüfen Sie anschließend, ob Sie den GitHub-Schlüssel in der konkreten Umgebung sicher verwalten und bei Bedarf aus Ihrem Konto entfernen können. Wenn diese Bedingungen nicht transparent oder für Ihr Projekt nicht ausreichend sind, nutzen Sie die Umgebung nicht für sensible Zugangsdaten.

Für gelegentliche Reisen kann die bisherige Kombination aus leichtem Gerät und wechselnden lokalen Terminals zwar bequem erscheinen, sie bringt aber getrennte Schlüsselbestände, uneinheitliche Agent-Zustände und einen schwierigeren Widerruf nach Geräteverlust mit sich. Ein Remote-Mac kann diese Wechsel reduzieren, sofern Sie die tatsächliche Zugriffskontrolle und den Umgang mit Zugangsdaten vorab prüfen. Wenn Sie für Ihre Arbeit dauerhaft macOS benötigen, prüfen Sie die VMSPIN-Zugangs- und Berechtigungsinformationen zunächst anhand Ihres konkreten Projekts; mieten Sie erst, wenn Schlüsselablage, Nutzungsgrenzen und Rückweg für Sie nachvollziehbar sind.