Frage an amazon-ec2, ssh, git, github, git-submodules – Probleme mit Git-Submodulen, wenn Submodule private Github-Repos sind

12

Ich habe ein privates Repo auf Github, das 3 Submodule beherbergt, von denen alle 3 auch privat sind.

Ich habe 4 SSH-Schlüssel auf meinem EC2-Server generiert und sie als Github-Bereitstellungsschlüssel auf alle 4 privaten Repositorys angewendet.

Ich kann das primäre Repository klonen, da es den SSH-Schlüssel erkennt. Wenn ich "git submodule update" starte, schlägt dies auf den privaten Repos mit folgendem Fehler fehl:

FEHLER: Repository nicht gefunden. fatal: Das entfernte Ende hat unerwartet aufgelegt

Wenn ich diese privaten Repos manuell auschecke, funktioniert das, aber nicht, wenn ich den Befehl git submodule verwende. Irgendeine Idee? Wird dies nicht vollständig unterstützt?

Deine Antwort

1   die antwort
11

e Benutzernamen. Sie leiten nur basierend auf dem von Ihnen angegebenen öffentlichen Schlüssel ab, welcher Benutzer Sie sind. Da Sie vier Deployment-Schlüssel generiert haben, kann jeder davon ausgehen, welcher von Ihrem Server verwendet wird, wenn er eine Verbindung zu github herstellt. Github akzeptiert jeden dieser Schlüssel und lehnt dann den Zugriff auf Repositorys ab, für die dieser Schlüssel nicht registriert ist.

Daher besteht die einfachste Lösung darin, nur einen einzigen Bereitstellungsschlüssel für alle Repositorys zu verwenden.

Wenn Sie dies jedoch nicht können, können Sie dies mithilfe von ssh-Host-Aliasen umgehen. Fügen Sie zu Ihrem Server hinzu~/.ssh/config Strophen wie die folgenden:

Host repo-foo
  HostName  ssh.github.com
  Port 443
  User git
  IdentityFile /path/to/my-ssh-key-file-for-foo
  IdentitiesOnly yes

Host repo-bar
  HostName ssh.github.com
  Port 443
  User git
  IdentityFile /path/to/my-ssh-key-file-for-bar
  IdentitiesOnly yes

Dann richten Sie Ihre Submodule aufrepo-bar:username/bar.git undrepo-foo:username/foo.git anstatt die[email protected]:... bilden.

Dies bewirkt effektiv, dass git und ssh jedes Repository als auf einem anderen Server befindlich behandeln und eine explizite Identitätsdatei übergeben, sodass keine Verwirrung darüber besteht, welcher Schlüssel verwendet werden soll.

@bdonlan: ja, ich weiß was du meinst; es ist ein bisschen klobig. Jedenfalls dachte ich, ich hätte deinen Namen erkannt! Sie und ich warengemeinsame Freunde Damals, als ich LJ benutzte. Ashe
Ja, das habe ich mir auch gedacht, aber die Bereitstellungsschlüssel sind eindeutig und ich kann sie nicht über mehrere Projekte hinweg platzieren. Ich werde sehen, was ich sonst noch tun kann, aber ich möchte hauptsächlich passwortlose Bereitstellungen. Miles Johnson
Das ist nicht seltsam; es ist ziemlich standard! Und die Standardlösung ist genau so, wie Sie es vorgeschlagen haben. Ashe
@Len, es ist seltsam, weil es bedeutet, dass ich etwas konfigurieren muss (~/.ssh/config), bevor ich meine Konfiguration herunterlade. Der Widerruf sollte eigentlich auf zwei Arten erfolgen: Verweigern Sie Host X den Zugriff auf Repo Y oder widerrufen Sie Schlüssel Z von Host X. Das Widerrufen von Schlüssel Z von Repo Y wird umständlich. Und bdonlan.livejournal.com wurde seit sechs Jahren nicht mehr aktualisiert :) bdonlan

Verwandte Fragen