Passer des options ssh à git clone

J'essaye de courir git clonesans ssh vérifiant la clé de l'hôte du référentiel. Je peux le faire à partir de ssh comme ça:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host

Existe-t-il un moyen de transmettre les mêmes options ssh à la commande git clone?

Modifier: il existe une restriction que je ne peux pas modifier ~/.ssh/configni aucun autre fichier sur cette machine.

Ajoutez-les à votre ~/.ssh/config:

Host host
    HostName host
    User user
    SshOption1 Value1
    SshOption2 Value2

L' Hostentrée correspond à ce que vous spécifierez sur la ligne de commande et le HostNameest le vrai nom d'hôte. Ils peuvent être identiques ou l' Hostentrée peut être un alias. L' Userentrée est utilisée si vous ne spécifiez pas user@sur la ligne de commande.

Si vous devez le configurer sur la ligne de commande, définissez la GIT_SSHvariable d'environnement pour qu'elle pointe vers un script contenant vos options.

Le git 2.3 récemment publié prend en charge une nouvelle variable "GIT_SSH_COMMAND" qui peut être utilisée pour définir une commande AVEC des paramètres.

GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone user@host

$GIT_SSH_COMMANDa priorité sur $GIT_SSH, et est interprété par le shell, ce qui permet d'inclure des arguments supplémentaires.

Une autre option permettant de spécifier différentes clés est git config core.sshCommand avec git 2.10 + (Q3 2016).

Ceci est une alternative à la variable d'environnement décrite dans la réponse de Boris )

Voir commit 3c8ede3 (26 juin 2016) par Nguyễn Thái Ngọc Duy ( pclouds) .
^{(Merged by Junio ​​C Hamano - gitster- in commit dc21164 , 19 juil.2016 )}

Une nouvelle variable de configuration core.sshCommand a été ajoutée pour spécifier la valeur à utiliser par GIT_SSH_COMMAND par référentiel.

Similaire à $GIT_ASKPASSou $GIT_PROXY_COMMAND, nous lisons également à partir du fichier de configuration, puis revenons à $GIT_SSH_COMMAND.

Ceci est utile pour sélectionner différentes clés privées ciblant le même hôte (par exemple github)

core.sshCommand:

Si cette variable est définie, git fetchet git pushutilisera la commande spécifiée au lieu de sshquand ils auront besoin de se connecter à un système distant.
La commande se présente sous la même forme que la GIT_SSH_COMMANDvariable d'environnement et est remplacée lorsque la variable d'environnement est définie.

Cela signifie que le git clonepeut être:

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

Si vous souhaitez appliquer cela à tous les dépôts , comme l' ajoute user1300959 dans les commentaires , vous utiliserez une configuration globale.

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

Voici un exemple délicat comment passer les arguments ssh en utilisant la variable GIT_SSH:

$ echo 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $*' > ssh
$ chmod +x ssh
$ GIT_TRACE=1 GIT_SSH="$PWD/ssh" git clone user@host

_{Remarque: les lignes ci-dessus sont des lignes de commande de terminal que vous devez coller dans votre terminal. Il créera un fichier ssh , le rendra exécutable et l'exécutera.}

Si vous souhaitez passer l'option de clé privée, veuillez vérifier Comment dire à git quelle clé privée utiliser? .

Configuration au niveau du référentiel sans impact sur les paramètres au niveau du système

En consolidant les réponses déjà disponibles, je choisis les étapes ci-dessous. Cela garantit que les modifications de configuration n'ont pas d'impact au niveau de la machine, mais uniquement pour le référentiel sur lequel travailler. Cela est nécessaire dans mon cas car mon script doit être exécuté sur un agent Bamboo partagé.

1.Clonez le référentiel en adoptant l' GIT_SSH_COMMANDapproche.

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

2.Une fois cloné, accédez au répertoire du référentiel.

cd repo-dir

3.Définissez la core.sshCommandconfiguration afin que tous les appels futurs puissent être simplement exécutés avec des commandes git comme d'habitude, mais en utilisant en interne les options git fournies.

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

Je pense que mettre à jour git vers une version> = 2.3 et utiliser GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone user@hostest l'option de pari, mais si ce n'est pas possible, @ josh-lee a donné une bonne option, mais s'il vous plaît, mettez à jour votre réponse en indentant le fichier de configuration ssh.

Host host
    HostName host
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Ce problème a été résolu en suivant les étapes de la machine Windows: -

• Créez un fichier de configuration dans le dossier C: \ Users \ username.ssh.

• ajoutez la ligne suivante à un fichier de configuration.

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

• puis réessayez.