Git & SSH Troubleshooting

Dieser Troubleshooting Abschnitt hilft dabei, den Überblick über die Git- und SSH-Konfiguration zu behalten.

Um nachvollziehen zu können, welche Git-Konfiguration basierend auf includeIf in einem Projekt tatsächlich angewendet wird, kann im jeweiligen Projektverzeichnis (z.B. ~/Work/kunde-1/projekt-1) die aktive Git-Konfiguration ausgelesen werden:

git config user.email
git config user.name

In diesem Beispiel sollte folgende Ausgabe erscheinen:

dev-kunde-1@example.com
Dein Name

Der folgende Befehl zeigt zusätzlich die exakte Author-Identität, die Git für den nächsten Commit verwenden würde:

git var GIT_AUTHOR_IDENT

Das zeigt die geladenen Fingerprints:

ssh-add -l

Das zeigt etwas detaillierter die Public Keys der geladenen Identitäten:

ssh-add -L

Um zu vergleichen, dass ein spezifischer Key geladen wurde:

ssh-keygen -lf ~/.ssh/github_ed25519.pub
ssh-add -l

Durch die Verwendung von Include-Direktiven in dieser Guideline kann es schwierig sein nachzuvollziehen, wie die endgültig aufgelöste SSH-Konfiguration aussieht und für welchen Host-Alias sie tatsächlich greift.

Mit folgendem Befehl kann die vollständige, aufgelöste SSH-Konfiguration angezeigt werden:

ssh -G github-kunde-1

Interessant sind dabei vor allem diese Zeilen:

hostname github.com
user git
identityfile ~/.ssh/github_ed25519
identitiesonly yes
addkeystoagent no
usekeychain no

Noch gezielter - ob wirklich der Alias github-kunde-1 und dessen Config verwendet wird:

ssh -G github-kunde-1 | egrep 'hostname|user|identityfile|identitiesonly|addkeystoagent|usekeychain'

In der ~/.ssh/config ist für den *-Host IdentitiesOnly yes definiert. Das bedeutet, dass jede SSH-Verbindung explizit einen passenden SSH-Key benötigt.

Tests wie beispielsweise

ssh -T git@github.com

werden fehlschlagen, wenn z.B. github.com nicht als Host-Alias definiert wurde.

Stattdessen sollte der konfigurierte Alias verwendet werden, zum Beispiel:

ssh -T github-kunde-1

Damit die SSH-Konfiguration im dev-Container korrekt angewendet wird, muss das GIT-Remote den entsprechenden Alias verwenden.

Das Projekt wird auf dem Host System über den zuvor beschriebenen HostAlias Mechanismus geklont. Dieser HostAlias muss dabei sowohl auf dem Host-System als auch im dev-Container genutzt werden, bzw. identisch sein.

Um dies zu prüfen kann man sich auf dem Host-System und auch im dev-Container die Git Remotes anzeigen lassen:

git remote -v

was basierend auf der Guideline folgendes Ergebnis liefern sollte:

origin git@github-kunde-1:org/repo.git (fetch)
origin git@github-kunde-1:org/repo.git (push)