webentwicklung-frage-antwort-db.com.de

Übergeben der ssh-Optionen an git clone

Ich versuche, git clone auszuführen, ohne dass ssh den Schlüssel des Repository-Hosts überprüft. Ich kann das von ssh so machen:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected]

Gibt es eine Möglichkeit, dieselben ssh-Optionen an den git clone-Befehl zu übergeben?

Bearbeiten: Es gibt eine Einschränkung, dass ich ~/.ssh/config oder andere Dateien auf diesem Computer nicht ändern kann.

gitssh
72
Daniel Velkov

Fügen Sie sie Ihrem ~/.ssh/config hinzu:

Host host
    HostName Host
    User user
    SshOption1 Value1
    SshOption2 Value2

Der Eintrag Host gibt an, was Sie in der Befehlszeile angeben, und HostName ist der wahre Hostname. Sie können gleich sein oder der Host-Eintrag kann ein Alias ​​sein. Der Eintrag User wird verwendet, wenn Sie in der Befehlszeile nicht [email protected] angeben.

Wenn Sie dies in der Befehlszeile konfigurieren müssen, legen Sie die Umgebungsvariable GIT_SSH so fest, dass sie auf ein Skript mit Ihren Optionen zeigt.

36
Josh Lee

Das kürzlich veröffentlichte git 2.3 unterstützt eine neue Variable "GIT_SSH_COMMAND", mit der ein Befehl MIT Parametern definiert werden kann.

GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone [email protected]

$GIT_SSH_COMMAND hat Vorrang vor $GIT_SSH und ist wird von der Shell interpretiert, wodurch zusätzliche Argumente verwendet werden können inbegriffen.

98
Boris

Hier ein kniffliges Beispiel, wie Sie die ssh-Argumente mit der Variablen GIT_SSH übergeben können:

$ echo 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $*' > ssh
$ chmod +x ssh
$ GIT_TRACE=1 GIT_SSH="$PWD/ssh" git clone [email protected]

Hinweis: Die obigen Zeilen enthalten Terminalbefehlszeilen, die Sie in Ihr Terminal einfügen sollten. Es erstellt eine Datei ssh, macht sie ausführbar und führt sie aus.

Wenn Sie die Option für den privaten Schlüssel übergeben möchten, aktivieren Sie das Kontrollkästchen Wie kann ich feststellen, welcher private Schlüssel verwendet werden soll? .

18
kenorb

Eine andere Option, um andere Schlüssel anzugeben, ist git config core.sshCommand mit git 2.10 + (Q3 2016).

Dies ist eine Alternative zu der Umgebungsvariablen, die in Boris s Antwort beschrieben ist.

Siehe Festschreiben 3c8ede3 (26 Jun 2016) von Nguyễn Thái Ngọc Duy (pclouds) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Festschreiben von dc21164 , 19. Juli 2016)

Eine neue Konfigurationsvariable core.sshCommand wurde zu .__ hinzugefügt. Geben Sie an, welchen Wert GIT_SSH_COMMAND pro Repository verwenden soll.

Ähnlich wie $GIT_ASKPASS oder $GIT_PROXY_COMMAND lesen wir auch aus Konfigurationsdatei zuerst auf $GIT_SSH_COMMAND zurückgreifen.

Dies ist nützlich, um andere private Schlüssel auszuwählen, die auf .__ zielen. gleicher Host (z. B. github)

core.sshCommand:

Wenn diese Variable festgelegt ist, verwenden git fetch und git Push den angegebenen Befehl anstelle von ssh, wenn sie eine Verbindung zu einem Remote-System herstellen müssen.
Der Befehl hat dieselbe Form wie die Umgebungsvariable GIT_SSH_COMMAND und wird überschrieben, wenn die Umgebungsvariable festgelegt wird.

Es bedeutet, dass der git clone sein kann:

cd /path/to/my/repo
git config core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' 
# later on
git clone Host:repo.git

Wenn Sie das für all repos anwenden möchten, da user1300959in den Kommentaren hinzufügt, würden Sie eine globale Konfiguration verwenden.

git config --global core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
18
VonC

Ich denke, dass Update git auf eine Version> = 2.3 und Verwendung von GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone [email protected] die Einsatzoption ist, aber wenn dies nicht möglich ist, hat @josh-lee eine gute Option gegeben.

Host host
    HostName Host
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
3
Jonathan Beber

Konfiguration auf Repository-Ebene ohne Auswirkung auf die Einstellungen auf Systemebene

Unter Konsolidierung der bereits verfügbaren Antworten wähle ich die folgenden Schritte. Dadurch wird sichergestellt, dass die Konfigurationsänderungen nicht auf der Maschinenebene, sondern nur für das Repository, an dem gearbeitet wird, wirksam werden. Dies ist in meinem Fall erforderlich, da mein Skript auf einem gemeinsam genutzten Bamboo-Agenten ausgeführt werden muss.

1.Klonen Sie das Repository nach der Methode GIT_SSH_COMMAND.

GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone ssh://url

2. Navigieren Sie nach dem Klonen in das Repository-Verzeichnis.

cd repo-dir

3.Stellen Sie die core.sshCommand -Konfiguration so ein, dass alle zukünftigen Aufrufe wie gewohnt nur mit git-Befehlen ausgeführt werden können, aber intern die bereitgestellten git-Optionen verbrauchen.

git config core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
1
Pavan Kumar

Dieses Problem wurde behoben, indem die folgenden Schritte in Windows ausgeführt wurden: -

  • Erstellen Sie die Konfigurationsdatei unter C:\Users\username.ssh.

  • fügen Sie einer Konfigurationsdatei die folgende Zeile hinzu.

    Host <Host>
hostname <HOSTNAME>
user <USER_NAME>
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes
port <PORT_NUMBER>
KexAlgorithms +diffie-hellman-group1-sha1

  • dann nochmal versuchen. 

0
Ajay