Xcode 27: Remote-SSH-Signierung fehlgeschlagen? Fehlerbehebung 2026

Ein fehlgeschlagenes Archive ist nicht automatisch ein Signierfehler. Entscheidend ist die erste aussagekräftige Fehlermeldung im Build-Protokoll: Scheitert die Kompilierung, schlägt CodeSign fehl oder wird ein erfolgreich erzeugtes Archive erst beim Export oder Upload abgelehnt? Diese Phasen verlangen unterschiedliche Prüfungen.

Beginnen Sie nicht mit dem Löschen oder Neuerstellen von Zertifikaten. Wenn dasselbe Projekt in einer grafischen Sitzung signiert, aber per SSH errSecInternalComponent zurückgibt, untersuchen Sie zunächst den tatsächlichen Ausführungskontext und die macOS-Schlüsselbundverfügbarkeit. Apple Developer Technical Support nennt SSH- und CI-Umgebungen als Kontexte, in denen dieser Fehler auftreten kann, und führt einen gesperrten Schlüsselbund als mögliche Ursache an. Der Fehler belegt jedoch allein keine einzelne Ursache. Apples Hinweise zu errSecInternalComponent in SSH- und CI-Szenarien

Sichern Sie vor Änderungen die erste relevante Fehlermeldung und den Kontext, in dem sie entstand. Für die Diagnose sind insbesondere diese Angaben hilfreich:

• Welche Phase schlägt zuerst fehl: Kompilierung, CodeSign, Archive-Export oder Upload?
• Welches Benutzerkonto führt den Build-Prozess tatsächlich aus?
• Welcher Schlüsselbund wird in diesem Kontext verwendet, und ist er entsperrt?
• Wird die erwartete Signieridentität mit zugehörigem privaten Schlüssel gefunden?
• Passen Team, Bundle ID, Entitlements und Provisioning Profile zum Ziel des Builds?

Diese Angaben sind keine Formalität. Ein SSH-Login kann unter einem erwarteten Konto stattfinden, während ein Dienst, ein Agent oder ein Skript den Build-Prozess unter einem anderen Benutzer startet. Ebenso kann ein grafischer Anmeldekontext eine andere verfügbare Schlüsselbundumgebung haben als eine nicht interaktive SSH-Sitzung. Apple beschreibt diese Unterschiede in der technischen Dokumentation zu Daemons, Agents und ihren Ausführungskontexten.

Schritt 1: Die erste fehlgeschlagene Phase festhalten

Suchen Sie im vollständigen Build-Protokoll nach der ersten CodeSign-Meldung und lesen Sie auch die unmittelbar vorhergehenden Zeilen. Eine spätere Meldung kann lediglich Folge eines früheren Problems sein. Notieren Sie außerdem, ob xcodebuild schon beim Kompilieren abbricht oder ob ein Archive erstellt wurde, bevor Export oder Upload fehlschlagen.

Vergleichen Sie nach Möglichkeit denselben Commit, dasselbe Scheme und dieselbe Build-Konfiguration zwischen grafischer Sitzung und SSH-Auftrag. Ändern Sie für diesen Vergleich nicht gleichzeitig Zertifikate, Profile und Build-Einstellungen: Sonst lässt sich nicht mehr erkennen, welche Abweichung entscheidend war.

Apple stellt mit der Dokumentation zur Diagnose von Xcode- und Code-Signing-Problemen eine Übersicht zu typischen Signierfehlern bereit. Nutzen Sie diese, um konkrete Meldungen einer passenden Ebene zuzuordnen, statt aus dem allgemeinen Fehlernamen eine Ursache abzuleiten.

Schritt 2: Benutzer und Home-Verzeichnis im Auftrag prüfen

Führen Sie die Prüfung innerhalb genau des Skripts oder Auftrags aus, der später xcodebuild startet. Eine separate SSH-Sitzung kann andere Umgebungsvariablen und Rechte haben als ein geplanter Auftrag oder ein CI-Dienst. Ermitteln Sie mindestens den effektiven Benutzer und dessen Home-Verzeichnis, zum Beispiel mit den üblichen Shell-Abfragen id -un und printf '%s\n' "$HOME".

Vergleichen Sie die Ergebnisse mit dem Konto, unter dem die grafische Sitzung erfolgreich signiert. Prüfen Sie außerdem, ob ein Skript mit erhöhten Rechten, ein Dienstkonto oder ein Agent den Prozess übernimmt. Ein vorhandenes Zertifikat im Benutzerkonto des interaktiven Entwicklers hilft nicht, wenn der Build unter einem anderen Konto ausgeführt wird.

Apple weist bei Daemons und Agents auf abweichende Ausführungsbedingungen gegenüber einer interaktiven Sitzung hin. Daher beweist ein erfolgreicher Aufruf von xcodebuild nicht, dass derselbe Benutzer, dieselben Berechtigungen oder derselbe Schlüsselbund verfügbar sind. Die Apple-Techniknotiz zu Benutzer- und Prozesskontexten ist hierfür eine hilfreiche Einordnung.

Achtung: Speichern Sie Passwörter, App-spezifische Geheimnisse oder private Schlüssel nicht im Projektarchiv, im Repository oder in ausführlichen Build-Protokollen. Auch eine kurzfristige Diagnose sollte keine dauerhafte Offenlegung von Signiergeheimnissen erzeugen.

Schritt 3: Schlüsselbund im passenden Kontext untersuchen

Ein Schlüsselbund, der in einer grafischen Sitzung verfügbar ist, muss in einer SSH-Sitzung nicht automatisch für den Signierprozess geöffnet sein. Prüfen Sie, ob das erwartete Benutzerkonto Zugriff auf den passenden Schlüsselbund hat und ob dieser während des Build-Auftrags entsperrt ist. Eine SSH-Sitzung kann sich nicht darauf verlassen, dass ein grafischer Dialog zur Entsperrung erscheint und bestätigt wird.

Mit security list-keychains -d user lässt sich die Liste der für den Benutzer konfigurierten Schlüsselbunde ansehen; security default-keychain -d user zeigt den eingestellten Standardschlüsselbund. Führen Sie diese Prüfungen im selben Kontext wie den Build aus. Apple beschreibt, wie eine Signieridentität in einem Schlüsselbund gespeichert wird, in der Dokumentation zum Speichern einer Identität im Schlüsselbund.

Wenn ein Schlüsselbund während eines unbeaufsichtigten Auftrags geöffnet werden muss, klären Sie zunächst, wie der Auftrag das sicher leisten kann. Vermeiden Sie Passwörter in Kommandozeilen, die in Prozesslisten oder Protokollen sichtbar sein können, und geben Sie Geheimnisse nicht über gemeinsam zugängliche Skriptdateien weiter. Eine funktionierende Entsperrung in einer manuellen SSH-Shell beweist zudem nicht, dass ein späterer CI- oder Zeitplanauftrag dieselben Bedingungen hat.

Schritt 4: Signieridentität und Zugriff auf den privaten Schlüssel prüfen

Wenn der Schlüsselbund verfügbar ist, prüfen Sie als Nächstes, ob die erwartete Signieridentität darin tatsächlich vorhanden und vollständig ist. security find-identity -v -p codesigning kann anzeigen, welche gültigen Code-Signing-Identitäten im aktuellen Benutzerkontext gefunden werden. Vergleichen Sie die Ausgabe mit der Identität, die das Projekt oder der Build-Auftrag verwenden soll.

Ein Zertifikat allein genügt nicht: Für die Signierung muss auch der dazu passende private Schlüssel erreichbar sein. Zusätzlich kann der Zugriff des Signierwerkzeugs auf diesen Schlüssel durch dessen Berechtigungen oder eine Zugriffskontrolle verhindert werden. Apples Erläuterung zu Zertifikatstypen und dem Schutz von Zertifikaten hilft bei der Einordnung, welche Rolle Zertifikat und zugehörige Identität spielen.

Bleibt codesign trotz verfügbarem Schlüsselbund erfolglos, untersuchen Sie die konkrete Meldung, die Schlüsselberechtigungen und mögliche doppelte oder unvollständige Identitäten. Ändern Sie nicht vorsorglich pauschal die Zugriffseinstellungen des Schlüsselbunds: Eine Berechtigung, die in einem Aufbau hilft, ist nicht automatisch für jede macOS-Version und jede Sicherheitsrichtlinie die passende Lösung.

Schritt 5: Erst bei passenden Hinweisen Zertifikat und Profil abgleichen

Zertifikat und Provisioning Profile sind eine andere Fehlerklasse als fehlender Schlüsselbundzugriff. Prüfen Sie diese Ebene, wenn die Identität vorhanden ist und die erste Fehlermeldung konkret auf eine nicht passende Signieridentität, Team-Zuordnung, Bundle ID, Entitlements oder Profilkonfiguration verweist.

Vergleichen Sie dabei die Team-Angabe des Projekts mit der erwarteten Identität und kontrollieren Sie, ob das Profil zur App und zum vorgesehenen Signierprozess passt. Apples Anleitung zum Bearbeiten, Herunterladen oder Erneuern von Provisioning Profiles beschreibt die Verwaltung der Profile. Für abweichende Entitlements stellt Apple eine Anleitung zum Prüfen und Diagnostizieren von Entitlements bereit.

Erneuern oder widerrufen Sie Zertifikate nicht ohne passende Hinweise. Wenn der Build nur wegen eines nicht interaktiven Schlüsselbundkontexts scheitert, kann ein neu ausgestelltes Zertifikat dieselbe Ursache unverändert lassen und zusätzliche Änderungen an Profilen oder Teamzuordnungen nach sich ziehen.

Nutzen Sie diese Entscheidungsbedingungen in der angegebenen Reihenfolge. Gehen Sie erst zur nächsten Ebene über, wenn die vorherige mit dem tatsächlichen Build-Auftrag geprüft wurde:

• Wenn derselbe Commit und dasselbe Scheme in der grafischen Sitzung signieren, im SSH-Auftrag aber nicht, dann vergleichen Sie zuerst Benutzer, Home-Verzeichnis, Schlüsselbund und nicht interaktiven Ausführungskontext. Andernfalls beginnen Sie bei der ersten fehlerhaften Build-Phase.
• Wenn die passende Identität im tatsächlichen SSH-Benutzerkontext fehlt, dann korrigieren Sie die Schlüsselbundzuordnung oder stellen Sie den vorgesehenen Zugriff für dieses Konto her. Andernfalls prüfen Sie, ob der private Schlüssel verfügbar und für den Signierprozess zugänglich ist.
• Wenn Schlüsselbund und privater Schlüssel verfügbar sind, die Fehlermeldung aber Team, Bundle ID, Entitlements oder Profil nennt, dann prüfen Sie gezielt Zertifikat und Provisioning Profile. Andernfalls ändern Sie diese Signierressourcen nicht auf Verdacht.
• Wenn der Fehler erst nach einem erfolgreichen Archive beim Export oder Upload auftritt, dann untersuchen Sie die betreffende Export- oder Übertragungsstufe. Andernfalls halten Sie die Diagnose auf der zuerst fehlschlagenden CodeSign- oder Build-Stufe.

Prüfliste vor jeder Änderung

Haken Sie die Punkte anhand des tatsächlichen SSH- oder CI-Auftrags ab, nicht anhand einer separaten Terminal-Sitzung. Fehlt ein Nachweis, bleibt die zugehörige Ebene offen; ändern Sie nicht vorsorglich bereits funktionierende Signierressourcen.

• [ ] Die erste fehlgeschlagene Phase ist aus dem vollständigen Protokoll bestimmt: Kompilierung, CodeSign, Archive-Export oder Upload.
• [ ] Grafische Sitzung und SSH-Auftrag verwenden denselben Commit, dasselbe Scheme und dieselbe Build-Konfiguration für den Vergleich.
• [ ] Der effektive Benutzer und das Home-Verzeichnis wurden innerhalb des Skripts ermittelt, das xcodebuild startet.
• [ ] Es ist geprüft, ob ein Dienst, Agent oder Aufruf mit erhöhten Rechten den Build unter einem anderen Konto ausführt.
• [ ] Der verwendete Schlüsselbund ist für dieses Konto identifiziert und während des Builds verfügbar.
• [ ] Die erwartete Signieridentität samt passendem privaten Schlüssel wird im Build-Kontext gefunden.
• [ ] Zugriff auf den privaten Schlüssel wurde geprüft, ohne eine pauschale Berechtigungsänderung vorzunehmen.
• [ ] Zertifikat und Provisioning Profile wurden nur dann geändert, wenn die konkrete Fehlermeldung auf Identität, Team, Bundle ID, Entitlements oder Profilzuordnung verweist.
• [ ] Ein erneuter Archive-Build wurde unter denselben Ausführungsbedingungen durchgeführt und sein Ergebnis getrennt von Export und Upload bewertet.

Wenn die ersten Punkte nicht erfüllt sind, ist der nächste Schritt die Klärung des Build-Kontexts, nicht das Erneuern des Zertifikats. Sind Benutzer, Schlüsselbund und Identität nachweislich korrekt, aber die Meldung nennt Profil- oder App-Zuordnungen, wechseln Sie gezielt zur Prüfung der Signiermaterialien.

Warum tritt errSecInternalComponent nur beim SSH-Build auf?

Der Fehler kann in einem nicht interaktiven Kontext entstehen, in dem Schlüsselbund und privater Schlüssel anders verfügbar sind als in der grafischen Sitzung. Apple DTS nennt SSH und CI als mögliche Umgebungen für diesen Fehler, nicht aber eine einzige allgemeingültige Ursache. Prüfen Sie deshalb zuerst den Benutzerkontext und die Schlüsselbundverfügbarkeit; ordnen Sie erst danach weitere Signiermeldungen ein.

Wie lässt sich das tatsächliche macOS-Konto eines Build-Auftrags feststellen?

Führen Sie die Abfragen für Benutzer und Home-Verzeichnis innerhalb des Auftrags aus, der xcodebuild startet. Vergleichen Sie sie mit dem SSH-Login und mit der grafischen Sitzung, in der das Signieren funktioniert. Falls ein Agent, Dienst oder Skript den Prozess übernimmt, prüfen Sie auch diesen Übergang. Ein erfolgreicher Login unter einem bestimmten Konto genügt nicht als Nachweis, dass der Build unter demselben Konto läuft.

Was folgt, wenn der Schlüsselbund entsperrt ist, codesign aber weiterhin scheitert?

Prüfen Sie zunächst, ob die erwartete Identität samt passendem privatem Schlüssel im tatsächlich verwendeten Benutzerkontext gefunden wird. Ein entsperrter Schlüsselbund garantiert weder eine vollständige Identität noch die Erlaubnis für codesign, den privaten Schlüssel zu verwenden. Suchen Sie in der ersten konkreten Fehlermeldung nach Hinweisen auf Berechtigungen, doppelte Identitäten oder Zertifikatsprobleme, bevor Sie Zugriffseinstellungen ändern.

Woran erkennt man ein Profilproblem statt eines Sitzungskonflikts?

Ein Sitzungskonflikt ist wahrscheinlicher, wenn derselbe Build in einer grafischen Sitzung gelingt und über SSH scheitert. Hinweise auf ein Profilproblem sind dagegen konkrete Meldungen zu Team, Bundle ID, Entitlements oder einer nicht passenden Provisioning-Profile-Zuordnung. Prüfen Sie in diesem Fall die Signieridentität und das Profil gezielt. Ändern Sie nicht gleichzeitig den Schlüsselbundkontext und die Profilkonfiguration.

Ein einzelner erfolgreicher Befehl zur Schlüsselbundprüfung ist noch keine Abnahme. Wiederholen Sie nach einer Änderung einen repräsentativen xcodebuild archive-Auftrag im Benutzer- und SSH-Kontext, der auch für den eigentlichen Build vorgesehen ist. Verwenden Sie dafür denselben Commit, dasselbe Scheme und dieselbe relevante Build-Konfiguration wie beim fehlgeschlagenen Lauf.

Prüfen Sie im Protokoll, ob das Archive vollständig erzeugt wurde und die Signierung ohne den ursprünglichen Fehler durchläuft. Kontrollieren Sie anschließend die Signatur des erzeugten Produkts und dessen Entitlements; Apple beschreibt das Vorgehen zum Untersuchen von Entitlements in einem Build-Artefakt. Wird das Archive später exportiert oder hochgeladen, führen Sie diese Schritte als getrennte Prüfungen durch: Ein erfolgreicher CodeSign-Schritt belegt nicht automatisch einen erfolgreichen Upload.

Halten Sie für die Wiederholung die verwendete Xcode- und macOS-Version, das Build-Konto, den Schlüsselbundort und die erste fehlschlagende Phase fest. So lässt sich ein späterer Fehler mit einem früheren Lauf vergleichen, ohne geheime Inhalte aus Zertifikaten oder Schlüsseln zu protokollieren. Prüfen Sie bei versionsspezifischen Änderungen zusätzlich die Xcode 27 Release Notes von Apple; leiten Sie daraus nur solche Änderungen ab, die dort tatsächlich dokumentiert sind.

Vor der Übergabe an ein Team sollte außerdem klar sein, welches Konto den Build ausführt und wo Signiergeheimnisse gespeichert sind. Bei einem extern verwalteten Mac gehören dazu auch die vertraglichen Bedingungen und Verantwortlichkeiten für die Nutzung; die Nutzungsbedingungen von NUKCLOUD sollten vor der Ablage von Build-Geheimnissen geprüft werden.

Wenn lokale Zertifikate und Projektzuordnung stimmen, aber der Fehler auf eine abweichende SSH-Sitzung oder fehlende Schlüsselbundverfügbarkeit zurückgeht, kann ein eigens nutzbarer Remote Mac die Build-Umgebung von einem wechselnden Arbeitsplatzrechner trennen. Ein lokaler Rechner als dauerhafter Build-Server bindet Hardware, Speicherplatz und Strom; ein allgemeiner Cloud-Host stellt nicht automatisch eine macOS-Umgebung mit Xcode und den benötigten Signierwerkzeugen bereit; ein improvisierter SSH-Auftrag kann an schwer nachvollziehbaren Benutzer- und Schlüsselbundkontexten scheitern.

Für einen vorübergehenden Signier- oder Abnahmelauf ist die Miete eines Remote Mac von NUKCLOUD daher eine mögliche Alternative zum Hardwarekauf. Sie passt jedoch nicht zu jedem Betrieb: Bei dauerhaft hoher Auslastung kann ein eigener Mac wirtschaftlicher sein, und wer lokale physische Schnittstellen benötigt, sollte diese Anforderungen vorab klären. Vor dem Wechsel sollten Ausführungskonto, Schlüsselbundzugriff und Umgang mit Signiergeheimnissen weiterhin bewusst festgelegt werden. Informationen zur Remote-Mac-Umgebung finden Sie auf der NUKCLOUD-Übersichtsseite.